prizmkit 1.1.95 → 1.1.97

package/bundled/dev-pipeline-windows/scripts/monitor-log.ps1

@@ -0,0 +1,102 @@
+#!/usr/bin/env pwsh
+# monitor-log.ps1 — Background log size monitor for AI session subagent (PowerShell)
+#
+# Polls session.log size, computes effective size (current - baseline),
+# and writes a structured JSON status file. Intended to be run by a
+# background subagent inside the AI CLI session.
+#
+# Usage:
+#   pwsh -NoProfile -File monitor-log.ps1 <session_log> <max_size> <poll_interval> <status_file> <baseline_file>
+#   powershell.exe -NoProfile -File monitor-log.ps1 <session_log> <max_size> <poll_interval> <status_file> <baseline_file>
+#
+# Status file format (JSON, rewritten each poll cycle):
+#   {
+#     "status": "OK" | "COMPACT_NEEDED",
+#     "total_bytes": <current session.log size>,
+#     "baseline_bytes": <size after last /compact>,
+#     "effective_bytes": <total - baseline>,
+#     "threshold_bytes": <compact threshold>,
+#     "overage_bytes": <effective - threshold, 0 if not exceeded>,
+#     "usage_pct": <effective / threshold * 100>
+#   }
+
+param(
+    [Parameter(Mandatory=$true)] [string]$SessionLog,
+    [Parameter(Mandatory=$true)] [long]$MaxSize,
+    [Parameter(Mandatory=$true)] [int]$PollInterval,
+    [Parameter(Mandatory=$true)] [string]$StatusFile,
+    [Parameter(Mandatory=$true)] [string]$BaselineFile
+)
+
+if ($MaxSize -lt 0) {
+    Write-Error "ERROR: MaxSize must be a non-negative integer"
+    exit 1
+}
+if ($PollInterval -le 0) {
+    Write-Error "ERROR: PollInterval must be a positive integer"
+    exit 1
+}
+
+# Ensure status directory exists
+$statusDir = Split-Path -Parent $StatusFile
+if (-not (Test-Path $statusDir)) {
+    New-Item -ItemType Directory -Path $statusDir -Force | Out-Null
+}
+
+Write-Error "[monitor-log] Starting log monitor: max=$MaxSize interval=${PollInterval}s"
+Write-Error "[monitor-log] Watching: $SessionLog"
+
+while ($true) {
+    # Read current log size
+    if (Test-Path $SessionLog) {
+        $size = (Get-Item $SessionLog).Length
+    } else {
+        $size = 0
+    }
+
+    # Read baseline (resets after each /compact)
+    $baseline = 0
+    if (Test-Path $BaselineFile) {
+        try {
+            $baseline = [long](Get-Content $BaselineFile -Raw).Trim()
+        } catch {
+            $baseline = 0
+        }
+    }
+
+    # Effective size = growth since last compact
+    $effective = $size - $baseline
+    if ($effective -lt 0) {
+        $effective = 0
+    }
+
+    # Determine status (MaxSize=0 disables monitoring)
+    if ($MaxSize -gt 0 -and $effective -gt $MaxSize) {
+        $status = "COMPACT_NEEDED"
+        $overage = $effective - $MaxSize
+        Write-Error "[monitor-log] COMPACT_NEEDED: effective=$effective overage=$overage (threshold=$MaxSize)"
+    } else {
+        $status = "OK"
+        $overage = 0
+    }
+
+    # Usage percentage
+    if ($MaxSize -gt 0) {
+        $usagePct = [Math]::Floor($effective * 100 / $MaxSize)
+    } else {
+        $usagePct = 0
+    }
+
+    # Write structured JSON status
+    @{
+        status = $status
+        total_bytes = $size
+        baseline_bytes = $baseline
+        effective_bytes = $effective
+        threshold_bytes = $MaxSize
+        overage_bytes = $overage
+        usage_pct = $usagePct
+    } | ConvertTo-Json -Compress | Out-File -FilePath $StatusFile -NoNewline
+
+    Start-Sleep -Seconds $PollInterval
+}

package/bundled/dev-pipeline-windows/templates/bootstrap-tier1.md

@@ -12,7 +12,7 @@ You are the **session orchestrator**. Implement Feature {{FEATURE_ID}}: "{{FEATU
 
 **CRITICAL**: You MUST NOT exit until ALL work is complete and committed.
 
-**Tier 1 — Single Agent**: You handle everything directly. No subagents, no TeamCreate.
+**Tier 1 — Single Agent**: You handle everything directly. No normal work subagents; the log-size monitor is the only allowed persistent background subagent. No TeamCreate.
 
 ### Feature Description
 
@@ -54,6 +54,9 @@ You are running in **headless non-interactive mode** with a FINITE context windo
 
 ---
 
+{{LOG_SIZE_AWARENESS}}
+---
+
 ## PrizmKit Directory Convention
 
 ```

package/bundled/dev-pipeline-windows/templates/bootstrap-tier2.md

@@ -10,7 +10,7 @@
 
 You are the **session orchestrator**. Implement Feature {{FEATURE_ID}}: "{{FEATURE_TITLE}}".
 
-**CRITICAL**: You MUST NOT exit until ALL work is complete and committed. When you spawn subagents, wait for each to finish (run_in_background=false).
+**CRITICAL**: You MUST NOT exit until ALL work is complete and committed. When you spawn normal work subagents, wait for each to finish (run_in_background=false). The log-size monitor is the only allowed persistent background subagent.
 
 **Tier 2 — Dual Agent**: You handle context + planning directly. Then spawn Dev and Reviewer subagents. Spawn Dev and Reviewer agents via the Agent tool.
 
@@ -60,6 +60,9 @@ You are running in **headless non-interactive mode** with a FINITE context windo
 
 ---
 
+{{LOG_SIZE_AWARENESS}}
+---
+
 ## PrizmKit Directory Convention
 
 ```
@@ -699,7 +702,7 @@ Remove-Item -Force -ErrorAction SilentlyContinue .prizmkit/specs/{{FEATURE_SLUG}
 - Build context-snapshot.md FIRST; all subagents read it instead of re-reading source files
 - context-snapshot.md is append-only: orchestrator writes Sections 1-4, Dev appends Implementation Log, Reviewer appends Review Notes
 - Gate checks enforce Implementation Log and Review Notes are written before proceeding
-- Do NOT use `run_in_background=true` when spawning subagents
+- Do NOT use `run_in_background=true` when spawning normal work subagents; the log-size monitor is the only allowed persistent background subagent
 - `/prizmkit-committer` is mandatory, and must not be replaced with manual git commit commands
 - Do NOT run `git add`/`git commit` during Phase 1-5 — all changes are committed once in Phase 6
 - If any files remain after the commit, amend the existing commit — do NOT create a follow-up commit

package/bundled/dev-pipeline-windows/templates/bootstrap-tier3.md

@@ -10,7 +10,7 @@
 
 You are the **session orchestrator**. Implement Feature {{FEATURE_ID}}: "{{FEATURE_TITLE}}".
 
-**CRITICAL**: You MUST NOT exit until ALL work is complete and committed. When you spawn subagents, wait for each to finish (run_in_background=false). Do NOT spawn agents in background and exit — that kills the session.
+**CRITICAL**: You MUST NOT exit until ALL work is complete and committed. When you spawn normal work subagents, wait for each to finish (run_in_background=false). The log-size monitor is the only allowed persistent background subagent. Do NOT spawn work agents in background and exit — that kills the session.
 
 **Tier 3 — Full Team**: For complex features, use the full pipeline (Phase 0–6) with Dev + Reviewer agents spawned via the Agent tool.
 
@@ -60,6 +60,9 @@ You are running in **headless non-interactive mode** with a FINITE context windo
 
 ---
 
+{{LOG_SIZE_AWARENESS}}
+---
+
 ## PrizmKit Directory Convention
 
 ```
@@ -780,7 +783,7 @@ Remove-Item -Force -ErrorAction SilentlyContinue .prizmkit/specs/{{FEATURE_SLUG}
 - Tier 3: full team — Dev (implementation) → Reviewer (review) — spawn agents directly via Agent tool
 - context-snapshot.md is append-only: orchestrator writes Sections 1-4, Dev appends Implementation Log, Reviewer appends Review Notes
 - Gate checks enforce Implementation Log and Review Notes are written before proceeding
-- Do NOT use `run_in_background=true` when spawning agents
+- Do NOT use `run_in_background=true` when spawning normal work agents; the log-size monitor is the only allowed persistent background subagent
 - Commit phase must use `/prizmkit-committer`; do NOT replace with manual git commit commands
 - Do NOT run `git add`/`git commit` during Phase 1-5 — all changes are committed once in Phase 6
 - If any files remain after the commit, amend the existing commit — do NOT create a follow-up commit

package/bundled/dev-pipeline-windows/templates/bugfix-bootstrap-prompt.md

@@ -13,6 +13,8 @@ You are the **bug fix session agent**. Fix Bug {{BUG_ID}}: "{{BUG_TITLE}}".
 
 **CRITICAL**: You MUST NOT exit until ALL work is complete and committed.
 
+**SUBAGENT LIFECYCLE**: The log-size monitor is the only allowed persistent background subagent. Any normal work subagent must be awaited with `run_in_background=false`.
+
 **NON-INTERACTIVE MODE**: There is NO human on the other end. NEVER ask for user confirmation, NEVER wait for user input. Make decisions autonomously and move forward.
 
 ### Bug Description
@@ -51,6 +53,7 @@ You are the **bug fix session agent**. Fix Bug {{BUG_ID}}: "{{BUG_TITLE}}".
 4. **Minimize tool output** — Capture to temp file, scan first/last lines, filter with Select-String, regex matching, or PowerShell object filtering. Never load full output.
 5. **No intermediate commits** — All changes committed once at the end via `/prizmkit-committer`.
 
+{{LOG_SIZE_AWARENESS}}
 ## Bug Fix Artifacts Directory
 
 ```

package/bundled/dev-pipeline-windows/templates/refactor-bootstrap-prompt.md

@@ -12,7 +12,7 @@
 
 You are the **refactor session orchestrator**. Execute Refactor {{REFACTOR_ID}}: "{{REFACTOR_TITLE}}".
 
-**CRITICAL SESSION LIFECYCLE RULE**: You MUST NOT exit until ALL work is complete and session-status.json is written. When you spawn subagents, you MUST **wait for each to finish** (run_in_background=false) before proceeding. Do NOT spawn an agent in the background and exit — that kills the session.
+**CRITICAL SESSION LIFECYCLE RULE**: You MUST NOT exit until ALL work is complete and session-status.json is written. When you spawn normal work subagents, you MUST **wait for each to finish** (run_in_background=false) before proceeding. The log-size monitor is the only allowed persistent background subagent. Do NOT spawn a work agent in the background and exit — that kills the session.
 
 **NON-INTERACTIVE MODE**: You are running in headless non-interactive mode. There is NO human on the other end. NEVER ask for user confirmation, NEVER wait for user input, NEVER use interactive prompts (e.g. "Would you like me to…"). If a skill has an interactive step (e.g. offer remediation, ask for approval), skip it and proceed autonomously. Make decisions based on the data available and move forward.
 
@@ -78,6 +78,7 @@ You are the **refactor session orchestrator**. Execute Refactor {{REFACTOR_ID}}:
 
 ## Execution Instructions
 
+{{LOG_SIZE_AWARENESS}}
 **YOU are the orchestrator. Execute each phase by spawning the appropriate team agent with run_in_background=false.**
 
 **Agent spawn failure policy (all Agent tool calls)**:
@@ -336,4 +337,4 @@ Write to: `{{SESSION_STATUS_PATH}}`
 - **Commit with** `refactor(<scope>):` prefix, NOT `feat:` or `fix:`
 - **Run full retrospective** (Job 1 + Job 2) — refactoring changes code structure
 - ALWAYS write session-status.json before exiting
-- Do NOT use `run_in_background=true` when spawning agents
+- Do NOT use `run_in_background=true` when spawning normal work agents; the log-size monitor is the only allowed persistent background subagent

package/bundled/dev-pipeline-windows/templates/sections/log-size-awareness.md

@@ -0,0 +1,78 @@
+## Session Log Budget Monitoring (PROACTIVE)
+
+Your session log grows with every tool call and subagent spawn.
+To prevent context exhaustion, **spawn a background monitoring subagent at session start**.
+
+### How to Set Up the Monitor
+
+1. **AS THE VERY FIRST ACTION** (before Phase 0), spawn a monitoring subagent
+   with `run_in_background: true` and this task:
+
+   ```
+   Run this command and keep it running:
+   $psHost = if (Get-Command pwsh -ErrorAction SilentlyContinue) { 'pwsh' } else { 'powershell.exe' }
+   & $psHost -NoProfile -File {{LOG_MONITOR_SCRIPT}} {{SESSION_LOG_PATH}} {{MAX_LOG_SIZE}} {{LOG_MONITOR_POLL_INTERVAL}} {{LOG_MONITOR_STATUS_FILE}} {{LOG_MONITOR_BASELINE_FILE}}
+   ```
+
+   The subagent MUST use `run_in_background: true`. It writes a JSON status
+   file every {{LOG_MONITOR_POLL_INTERVAL}} seconds.
+
+2. **BEFORE EACH MAJOR PHASE** (Phase 0, 1, 2, ...), read the status:
+
+   ```powershell
+   if (Test-Path {{LOG_MONITOR_STATUS_FILE}}) { Get-Content {{LOG_MONITOR_STATUS_FILE}} } else { '{"status":"OK"}' }
+   ```
+
+   The status file contains structured diagnostics:
+
+   ```json
+   {
+     "status": "OK | COMPACT_NEEDED",
+     "total_bytes": <current session.log size>,
+     "baseline_bytes": <size after last /compact>,
+     "effective_bytes": <total - baseline, incremental growth>,
+     "threshold_bytes": <{{MAX_LOG_SIZE}}>,
+     "overage_bytes": <effective - threshold, 0 when OK>,
+     "usage_pct": <effective / threshold * 100>
+   }
+   ```
+
+   Extract fields for decision-making:
+   ```powershell
+   $data = Get-Content {{LOG_MONITOR_STATUS_FILE}} | ConvertFrom-Json
+   $status = $data.status
+   $effective = $data.effective_bytes
+   $overage = $data.overage_bytes
+   $usage = $data.usage_pct
+   ```
+
+3. **On COMPACT_NEEDED** (effective_bytes > {{MAX_LOG_SIZE}} bytes, {{MAX_LOG_SIZE_HUMAN}}):
+   - Check `overage_bytes` to decide urgency:
+     - **Minor overage** (< 512KB): complete the current sub-step, update durable workflow checkpoint artifacts, write baseline, `/compact`
+     - **Major overage** (>= 512KB): update durable workflow checkpoint artifacts, write baseline, `/compact` — do NOT start new work
+   - Write baseline before `/compact`:
+     ```powershell
+     (Get-Item {{SESSION_LOG_PATH}}).Length | Out-File -NoNewline {{LOG_MONITOR_BASELINE_FILE}}
+     ```
+   - Execute `/compact`
+   - Continue the workflow after `/compact`; re-read this status file before the next major phase
+
+### How the Baseline Prevents Infinite Compaction Loops
+
+- Before the first `/compact`: baseline = 0, effective = full log size → triggers when log exceeds threshold
+- After `/compact`: baseline = current log size, effective ≈ 0 → status resets to OK
+- The monitor only triggers again when **new** log growth since the last compact exceeds the threshold
+- Each `/compact` resets the baseline, breaking the infinite loop
+
+### Log Growth Reduction Tips
+
+- **Re-read context-snapshot.md instead of source files** — already in context
+- **Filter command output** — pipe to `Select-Object -Last 20` or `Select-String`, never full output
+- **Limit subagent prompts** — shorter, focused prompts = shorter transcripts
+- **Checkpoint often** — update durable workflow checkpoint artifacts before `/compact`
+
+### What Survives
+
+- All git commits are permanent
+- The workflow checkpoint is preserved and auto-resumed
+- `/compact` compresses context without losing progress

package/bundled/rules/general/agent-operational-rules.md

@@ -27,42 +27,4 @@ Before any Read with offset + limit:
 
 Before editing a large file (>1000 lines), verify you know its current line count from the most recent tool_result. Old line counts from earlier turns may be stale if you have since edited the file.
 
-## Consecutive Read Failures
 
-If 3 consecutive Read calls to the same file return 'shorter than provided offset' or 'Wasted call':
-- STOP all work on that file.
-- Send ESCALATION with the file path, current line count, and the offsets you attempted.
-- The orchestrator will provide the correct content.
-
-## Test Output Hygiene
-
-**Applies to: Dev Agent and any agent that runs tests.** Does NOT apply to Reviewer, Critic, or other agents that do not execute test commands.
-
-When tests fail:
-- Run the test command provided in your task assignment ONCE (e.g., `$TEST_CMD`, `npm test`, `pytest`, etc.).
-- Capture output with `tee` (macOS/Linux) or `Tee-Object` (Windows/PowerShell) to a temp file.
-- Then grep/Select-String that file for failure details.
-- Never re-run the full test suite just to apply a different filter to its output.
-
-**macOS/Linux**:
-```bash
-($TEST_CMD) 2>&1 | tee /tmp/test-out.txt | tail -20
-grep -n "FAIL\|Error\|assert" /tmp/test-out.txt
-```
-
-**Windows/PowerShell**:
-```powershell
-& { {{TEST_CMD}} } 2>&1 | Tee-Object (Join-Path $env:TEMP "test-out.txt") | Select-Object -Last 20
-Select-String -Path (Join-Path $env:TEMP "test-out.txt") -Pattern "FAIL|Error|assert"
-```
-
-Note: `$TEST_CMD` / `{{TEST_CMD}}` is a placeholder set by the pipeline or orchestrator. Use whatever test command is provided in your task assignment. Do NOT hardcode a specific test tool — projects vary.
-
-## Incremental Validation
-
-**Applies to: Dev Agent.** Does NOT apply to Reviewer, Critic, or read-only agents.
-
-After every 3 successful Edit operations on a file:
-- Run the relevant test command for that file once.
-- Validate your changes compile and behave correctly.
-- Do not defer all testing to the end.

package/bundled/rules/general/cohesive-modeling.md

@@ -1,27 +1,40 @@
 ---
-description: "将总是同时出现的变量/字段/概念建模为高内聚的整体，而非散落碎片"
+description: "Model variables/fields/concepts that always appear together as a cohesive whole, not scattered fragments"
 ---
 
-在设计或理解任何系统时，如果一组变量、字段、概念总是同时出现、表达同一个语义单元，就应该把它们规划成一个整体，而不是散落为独立的碎片：
+When designing or understanding any system, if a group of variables, fields, or concepts always appear together and express the same semantic unit, they should be modeled as a single whole rather than scattered fragments:
 
-- **Go** — 定义 struct
-- **Java/Python** — 定义 class
-- **TypeScript** — 定义 interface/type
-- **配置** — 归入嵌套配置块
-- **模块划分** — 拆为独立模块
+- **Go** — define a struct
+- **Java/Python** — define a class
+- **TypeScript** — define an interface/type
+- **Config** — group into a nested config block
+- **Module partitioning** — split into an independent module
 
-本质是同一个原则：**高内聚的东西，在建模那一刻就应该是一个东西。**
+The essence is the same principle: **highly cohesive things should be a single thing at the moment of modeling.**
 
-## 触发场景
+## Trigger Scenarios
 
-1. 同一个函数/方法的参数列表中，某几个参数始终一起传递 → 抽取为参数对象
-2. 多个变量总是被一起赋值、一起传递、一起返回 → 合并为结构体/类
-3. 配置文件中一组键总是成对/成群出现 → 合并为嵌套配置块
-4. 发现自己在不同文件里重复声明相同的一组字段 → 提取为公共类型/接口
-5. 修改一个值就必须同步修改另一个值 → 它们属于同一个不变量，应封装在一起
+1. Within a function/method parameter list, a few parameters are always passed together → extract into a parameter object
+2. Multiple variables are always assigned, passed, and returned together → merge into a struct/class
+3. A group of keys in a config file always appears in pairs/clusters → group into a nested config block
+4. You find yourself repeatedly declaring the same set of fields across different files → extract a shared type/interface
+5. Modifying one value requires synchronously modifying another → they belong to the same invariant and should be encapsulated together
 
-## 反面模式（应避免）
+## Anti-Patterns (Avoid)
 
-- 基本类型偏执（Primitive Obsession）：用散落的 string/number 代替有意义的类型
-- 数据泥团（Data Clumps）：相同的一组数据在参数列表、返回值、变量声明中反复出现
-- 霰弹式修改（Shotgun Surgery）：加一个字段需要改 N 个文件的函数签名
+- **Primitive Obsession**: using scattered string/number in place of meaningful types
+- **Data Clumps**: the same group of data repeatedly appearing in parameter lists, return values, and variable declarations
+- **Shotgun Surgery**: adding one field requires changing function signatures across N files
+
+## How to Apply
+
+- When you spot a trigger scenario, extract the cohesive group into a named unit in one pass — do not leave it for "later refactoring."
+- Prefer immutability for the extracted unit to preserve the invariant across the codebase.
+- Name the unit after the domain concept it represents, not the data it happens to contain (e.g., `Money`, not `AmountAndCurrency`).
+- Apply the rule at the lowest level first (parameter object, struct), then propagate upward to interfaces and modules if the cohesion holds.
+
+## Related Principles
+
+- **Single Responsibility Principle** — a cohesive unit should have one reason to change.
+- **Invariant Encapsulation** — bundle data that must satisfy a shared constraint so the constraint can be enforced in one place.
+- **Tell, Don't Ask** — once grouped, expose behavior on the whole rather than dissecting it at call sites.

package/bundled/skills/_metadata.json

@@ -1,5 +1,5 @@
 {
-  "version": "1.1.95",
+  "version": "1.1.97",
   "skills": {
     "prizm-kit": {
       "description": "Full-lifecycle dev toolkit. Covers spec-driven development, Prizm context docs, code quality, debugging, deployment, and knowledge management.",

package/bundled/skills/app-planner/SKILL.md

@@ -66,7 +66,7 @@ Do NOT use this skill when:
 ## Resource Loading Rules (Mandatory)
 
 1. **App design reference** — always load at session start:
-   - Read `${SKILL_DIR}/assets/app-design-guide.md` for vision templates and tech stack matrix
+   - Read `${SKILL_DIR}/references/app-design-guide.md` for vision templates and tech stack matrix
 
 2. **Load on-demand references when triggered**:
    - Architecture decisions emerged → read `${SKILL_DIR}/references/architecture-decisions.md`
@@ -218,7 +218,7 @@ Execute the planning workflow in conversation mode with mandatory checkpoints:
    1.1 Confirm deliverable intent (→ Intent Confirmation — option-based)
    1.2 **Requirement clarification** — for ANY unclear aspect of the user's vision, goals, target users, or scope, use option-based questions where possible. When common patterns exist, present them as choices. Only use open-ended questions for truly unique input (e.g., "describe your app idea"). Follow up with option-based clarifications.
 2. Confirm constraints and tech assumptions
-   2.1 Tech stack selection — use `${SKILL_DIR}/assets/app-design-guide.md` §2 decision matrix. Use `AskUserQuestion` for each major tech decision (framework, database, styling, etc.)
+   2.1 Tech stack selection — use `${SKILL_DIR}/references/app-design-guide.md` §2 decision matrix. Use `AskUserQuestion` for each major tech decision (framework, database, styling, etc.)
    2.2 **Frontend design check** (for frontend projects) — scan for existing UI/UX design docs. If none found, use `AskUserQuestion`:
        - Question: "No UI/UX design docs found. Would you like to establish design direction?"
        - Options: "Establish design direction now (Recommended)", "Skip for now", "I have external designs"

package/bundled/skills/app-planner/references/project-state-detection.md

@@ -32,7 +32,7 @@ Before ANY planning work, check if AI-essential project context files exist:
 **If ANY are missing**, show the status table, then use `AskUserQuestion`:
 
 **Question**: "Some AI context files are missing. These help AI understand your project — making planning much more effective. How would you like to proceed?"
-- **Run project init first (Recommended)** — invoke `prizmkit-init` to scan your codebase and generate these files, then return to planning
+- **Run project init first** — invoke `prizmkit-init` to scan your codebase and generate these files, then return to planning
 - **Continue without init** — I'll scan the project manually during this session (less thorough)
 - **Skip, I'll set these up later** — proceed with planning using only what's available
 
@@ -71,7 +71,7 @@ Show the summary as text, then use `AskUserQuestion`:
 > **Architecture**: [e.g., monolithic, microservices, serverless]
 
 **Question**: "Does this look correct?"
-- **Yes, looks correct (Recommended)** — proceed with planning
+- **Yes, looks correct** — proceed with planning
 - **Mostly correct, with changes** — I'll note corrections
 - **This is off** — let me describe the project
 

package/bundled/skills/bug-planner/SKILL.md

@@ -212,9 +212,8 @@ Before generating `.prizmkit/plans/bug-fix-list.json`, perform a holistic scan a
 
 **Step 4 — Present review table**: Display the completeness assessment using the template in `${SKILL_DIR}/assets/bug-confirmation-template.md` (§Completeness Review Template).
 
-For any items that need attention, ask targeted questions to fill gaps. Iterate until the user confirms all bugs are adequately described. Present bilingual prompt:
+For any items that need attention, ask targeted questions to fill gaps. Iterate until the user confirms all bugs are adequately described. Present the prompt:
 
-> "以上是完整性审查结果。需要补充的项目是否逐一补充？还是先跳过，之后再完善？"
 > "Above is the completeness review. Items needing more detail — address them now, or proceed and refine later?"
 
 Only proceed to Phase 5 after user confirms.

package/bundled/skills/bug-planner/assets/bug-confirmation-template.md

@@ -23,9 +23,9 @@ Present this after extracting and clarifying each bug:
 ```
 
 Then ask three confirmation questions:
-1. "描述是否准确？是否需要修改？" / "Is the description accurate? Any corrections?"
-2. "是否需要补充更多细节？（复现步骤、环境信息、相关代码位置等）" / "Need to add more details? (reproduction steps, environment, related code locations, etc.)"
-3. "验证条件是否具体到 pipeline 可以自主判断修复成功？" / "Are the acceptance criteria specific enough that the pipeline can autonomously verify the fix?"
+1. "Is the description accurate? Any corrections?"
+2. "Need to add more details? (reproduction steps, environment, related code locations, etc.)"
+3. "Are the acceptance criteria specific enough that the pipeline can autonomously verify the fix?"
 
 Only finalize the bug entry after user confirms all three points.
 

package/bundled/skills/prizm-kit/SKILL.md

@@ -72,7 +72,7 @@ All three follow the same per-task flow. Detailed documentation policies (when t
 | `/prizmkit-code-review` | Diagnose issues + produce Fix Instructions | "review", "check code", "is it ready to commit" |
 | `/prizmkit-retrospective` | Sync .prizmkit/prizm-docs/ with code changes | "retrospective", "retro", "sync docs", "wrap up" |
 | `/prizmkit-committer` | Safe git commit with Conventional Commits | "commit", "submit", "finish", "ship it" |
-| `/prizmkit-test` | Generate + run tests, analyze coverage gaps, unified quality report | "test", "run tests", "check quality", "verify code", "补测试" |
+| `/prizmkit-test` | Generate + run tests, analyze coverage gaps, unified quality report | "test", "run tests", "check quality", "verify code", "add tests" |
 | `/prizmkit-deploy` | Universal deployment gateway: SSH automation, cloud/Docker guided setup, status/logs/rollback | "deploy", "ship it", "go live", "rollback", "deploy status" |
 | `/prizmkit-init` | Project bootstrap + .prizmkit/prizm-docs/ setup | "init", "initialize", "take over this project" |
 | `/prizmkit-prizm-docs` | Doc management (init/status/rebuild/validate) | "check docs", "rebuild docs", "validate docs" |

package/bundled/skills/prizmkit-deploy/SKILL.md

@@ -204,14 +204,14 @@ The following sections define the SSH deployment adapter — the only fully-auto
 After Discovery routes to SSH, **before** entering the configuration wizard, ask the user how they want to deploy.
 
 **First question:**
-> "你想怎么部署到服务器？"
-> - **A. 直接上传（快速上手）** — 本地构建，传到服务器启动。适合第一次部署。
-> - **B. CI/CD 自动部署（推荐）** — 配置 GitHub Actions，以后 `git push` 自动部署。
+> "How do you want to deploy to the server?"
+> - **A. Direct Upload (quick start)** — build locally, transfer to server and start. Good for first deployment.
+> - **B. CI/CD Auto-Deploy (recommended)** — configure GitHub Actions, then `git push` auto-deploys.
 
 **If user chooses CI/CD, second question:**
-> "CI/CD 有两种模式："
-> - **Push 模式** — GitHub Actions runner 编译，SCP 传到服务器。服务器压力小。
-> - **Pull 模式** — 服务器自己拉代码编译。配置更简单但需 Deploy Key。
+> "CI/CD has two modes:"
+> - **Push mode** — GitHub Actions runner builds, SCP transfers to server. Low server load.
+> - **Pull mode** — server pulls code and builds itself. Simpler config but requires a Deploy Key.
 
 For detailed mode descriptions and the full Push/Pull comparison table, read `references/deployment-modes.md`.
 
@@ -306,7 +306,7 @@ After generating the workflow, verify: the first `git push` to the configured br
 
 Before SSL, check if the user has a domain pointing to the server.
 
-1. Ask: "你有没有域名要绑定到这个项目？" If no domain → skip DNS + SSL, note in deploy.md.
+1. Ask: "Do you have a domain to bind to this project?" If no domain → skip DNS + SSL, note in deploy.md.
 2. Check DNS: `dig +short <domain> A`. If resolved → proceed to SSL.
 3. If not resolved: show the user DNS setup instructions. Full procedure in `references/dns-setup.md`.
 
@@ -360,7 +360,7 @@ If no previous release exists, rollback is not possible — state this clearly.
 
 After a successful direct-upload deployment, proactively offer CI/CD setup:
 
-> "部署成功。要不要顺手帮你配置 CI/CD 自动部署？以后 `git push` 就自动上线。"
+> "Deployment succeeded. Want me to set up CI/CD auto-deploy? After that, `git push` will auto-deploy."
 
 If user agrees, ask push vs pull, then configure accordingly. If Pull mode: set up deploy key. If Push mode: add GitHub Actions secrets. Generate `deploy.yml` from `references/ci-cd-workflows.md`, update `deployStrategy` in config, write upgrade event to history.
 

package/bundled/skills/prizmkit-deploy/references/database-setup.md

@@ -6,9 +6,9 @@ Read this file when Discovery detected a database driver and the user wants AI-a
 
 During Discovery Step 1 (Project Detection), database drivers were already scanned. If a driver was detected, ask after bootstrap tools are installed:
 
-> "检测到项目使用了 <PostgreSQL/MySQL/Redis>，需要帮你在服务器上安装配置吗？"
-> - **需要** → 继续数据库安装
-> - **不需要** → 跳过，记录到 deploy.md，标注"数据库需用户自行配置"
+> "Detected the project uses <PostgreSQL/MySQL/Redis>. Want me to install and configure it on the server?"
+> - **Yes** → proceed with database installation
+> - **No** → skip, record in deploy.md with note "database must be configured by user"
 
 ## PostgreSQL setup
 
@@ -21,7 +21,7 @@ sudo -u postgres psql -c "GRANT ALL ON DATABASE <project> TO <project>;"
 
 - Generate a secure random password (32 chars, alphanumeric + symbols).
 - Write the connection string to `.prizmkit/deploy/secrets.local.json`: `DATABASE_URL=postgresql://<project>:<password>@localhost:5432/<project>`.
-- In deploy.md, write: "PostgreSQL 已安装，连接信息已记录到 `.prizmkit/deploy/secrets.local.json`（不提交到 git）".
+- In deploy.md, write: "PostgreSQL installed, connection info recorded in `.prizmkit/deploy/secrets.local.json` (not committed to git)".
 
 ## MySQL setup (future)
 

package/bundled/skills/prizmkit-deploy/references/deployment-modes.md

@@ -34,14 +34,14 @@ Best for: simple setup, servers with sufficient CPU/RAM, projects where build is
 
 ## Comparison
 
-| 对比 | Push 模式 | Pull 模式 |
+| Aspect | Push mode | Pull mode |
 |------|----------|----------|
-| 构建位置 | GitHub Actions runner | 服务器本地 |
-| 服务器压力 | 低（只运行应用） | 高（编译+运行） |
-| 配置复杂度 | 中（需 SCP 传产物） | 低（只需 SSH 触发脚本） |
-| 适合场景 | 服务器配置低、编译重 | 部署简单优先、服务器性能充裕 |
-| Deploy Key 需要 | 不需要 | 需要 |
-| 产物传输 | SCP tarball | git pull（仅增量） |
+| Build location | GitHub Actions runner | Server (local) |
+| Server load | Low (runs app only) | High (build + run) |
+| Config complexity | Medium (needs SCP transfer) | Low (SSH-triggered script only) |
+| Best for | Low-spec servers, heavy builds | Simple setup, capable servers |
+| Deploy Key required | No | Yes |
+| Artifact transfer | SCP tarball | git pull (incremental) |
 
 ## Common ground between all modes
 

package/bundled/skills/prizmkit-deploy/references/dns-setup.md

@@ -14,21 +14,21 @@ If not: continue below.
 ## Step 2 — DNS setup guidance
 
 ```
-域名 <example.com> 还未指向服务器 <服务器IP>。
+Domain <example.com> is not yet pointing to server <server-IP>.
 
-请在 DNS 服务商（如阿里云、Cloudflare、Namecheap）添加以下记录：
+Add the following record at your DNS provider (e.g., Alibaba Cloud, Cloudflare, Namecheap):
 
   Type:  A
   Name:  @
-  Value: <服务器IP>
+  Value: <server-IP>
   TTL:   600
 
-如果要同时支持 www 子域名：
+To also support the www subdomain:
   Type:  A
   Name:  www
-  Value: <服务器IP>
+  Value: <server-IP>
 
-配置完成后回复"好了"，我继续检查并配 SSL 证书。
+Reply "done" when configured, and I'll verify and set up the SSL certificate.
 ```
 
 ## Step 3 — Verify after user confirmation
@@ -39,4 +39,4 @@ If not: continue below.
 
 ## Edge case — IP-only deployment
 
-If user has no domain: skip DNS + SSL sections. Generate a note in deploy.md: "项目通过 IP 访问，未配置域名和 HTTPS。建议购买域名后运行 `/prizmkit-deploy setup-ssl`。"
+If user has no domain: skip DNS + SSL sections. Generate a note in deploy.md: "Project accessed via IP, no domain or HTTPS configured. Recommend purchasing a domain and running `/prizmkit-deploy setup-ssl`."

package/bundled/skills/prizmkit-deploy/references/firewall-setup.md

@@ -5,17 +5,17 @@ Read this file when the user wants AI-assisted firewall configuration during boo
 ## Flow
 
 1. After core tools are installed, ask the user:
-   > "是否需要帮你配置防火墙（ufw）？只开放必要的端口，提高服务器安全性。"
+   > "Want me to configure the firewall (ufw)? Only necessary ports will be opened, improving server security."
 
 2. If user declines: skip, record to deploy config.
 
 3. If user agrees, ask which additional ports to open (beyond SSH/HTTP/HTTPS):
-   > "默认只开放 SSH(22)、HTTP(80)、HTTPS(443)。蓝绿部署预览端口（3101/3102）要不要也开放？如果需要其他端口（如数据库远程管理），可以一起列出来。"
+   > "By default only SSH(22), HTTP(80), HTTPS(443) are opened. Should the blue/green preview ports (3101/3102) also be opened? If you need other ports (e.g., for remote database management), list them together."
 
 4. Collect ports, then ask:
-   > "防火墙规则已整理好。是我直接上去改，还是你自己来？"
-   > - **A. 你帮我改** — AI 执行 ufw 命令
-   > - **B. 我自己改** — 输出规则清单，用户手工执行
+   > "Firewall rules are ready. Should I apply them directly, or will you do it yourself?"
+   > - **A. You apply them** — AI runs ufw commands
+   > - **B. I'll do it myself** — output rule list, user executes manually
 
 ## Planned rules (output before executing)