prizmkit 1.1.95 → 1.1.96

package/bundled/VERSION.json

@@ -1,5 +1,5 @@
 {
-  "frameworkVersion": "1.1.95",
-  "bundledAt": "2026-07-02T18:33:03.686Z",
-  "bundledFrom": "7b384b4"
+  "frameworkVersion": "1.1.96",
+  "bundledAt": "2026-07-02T18:48:14.022Z",
+  "bundledFrom": "42b5a94"
 }

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.96",
   "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)
 

package/bundled/skills/prizmkit-deploy/references/ssh-execution-flow.md

@@ -4,7 +4,7 @@ Pipeline runs in strict order. Each group must complete before the next begins.
 
 ## Pre-flight — Change Summary
 
-Show what will be deployed using `git log --oneline <last-deployed-commit>..HEAD`. If first deployment, show last 5 commits. If no new commits, warn "没有新的代码变更。确定要重新部署吗？"
+Show what will be deployed using `git log --oneline <last-deployed-commit>..HEAD`. If first deployment, show last 5 commits. If no new commits, warn "No new code changes. Are you sure you want to redeploy?"
 
 ## Group 1 — Pre-flight & Prepare
 

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

@@ -15,11 +15,11 @@ Also check `/etc/hostname` for vendor patterns.
 ## Step 2 — Choose SSL strategy
 
 - **Cloud vendor detected** → ask user:
-  > "检测到服务器运行在 <云厂商>。用哪种 SSL 方案？"
-  > - **A. Let's Encrypt 免费证书（推荐）** — 一行命令永久自动续期，最省心
-  > - **B. <云厂商> 自有证书** — 需手动下载配置，1年有效期需手动续期
+  > "Detected the server is running on <cloud-vendor>. Which SSL approach?"
+  > - **A. Let's Encrypt free certificate (recommended)** — one command for permanent auto-renewal, hassle-free
+  > - **B. <cloud-vendor> native certificate** — manual download/config, 1-year validity requires manual renewal
   >
-  > 选 A 我直接帮你搞定；选 B 你需要在云控制台下载证书后告诉我路径。
+  > Choose A and I'll set it up for you; choose B and you'll need to download the certificate from the cloud console and tell me the path.
 - **No cloud vendor / unknown** → use certbot directly, no choice needed.
 
 ## Step 3 — Certbot install & certificate request

package/bundled/skills/prizmkit-prizm-docs/assets/prizm-docs-format.md

@@ -544,7 +544,7 @@ JSON:
   "hooks": {
     "UserPromptSubmit": [
       {
-        "matcher": "(?i)\\b(commit|push|finish|ship|merge|pull request|pr)\\b|提交|推送|收尾|完成任务|合并|发版|发布",
+        "matcher": "(?i)\\b(commit|push|finish|ship|merge|pull request|pr)\\b",
         "hooks": [
           {
             "type": "command",

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

@@ -1,6 +1,6 @@
 ---
 name: "prizmkit-test"
-description: "Full-stack test generation and orchestration. Detects architecture, discovers/runs existing tests, analyzes coverage gaps, generates missing unit/integration/E2E tests including business-specific boundary cases, validates every interface with a required boundary coverage matrix, and outputs a unified report. Use after completing development to verify quality before deploy. Trigger on: 'test', 'run tests', 'check quality', 'verify code', 'generate tests', 'test coverage', 'fill test gaps', 'boundary tests', 'edge cases', 'quality check', '测试', '验证', '跑测试', '补测试', '边界测试'. (project)"
+description: "Full-stack test generation and orchestration. Detects architecture, discovers/runs existing tests, analyzes coverage gaps, generates missing unit/integration/E2E tests including business-specific boundary cases, validates every interface with a required boundary coverage matrix, and outputs a unified report. Use after completing development to verify quality before deploy. Trigger on: 'test', 'run tests', 'check quality', 'verify code', 'generate tests', 'test coverage', 'fill test gaps', 'boundary tests', 'edge cases', 'quality check', 'add tests'. (project)"
 ---
 
 # PrizmKit Test
@@ -11,7 +11,7 @@ A comprehensive test generation and orchestration skill. Discovers existing test
 - After completing one or more features/refactors/bugfixes
 - As a quality gate before deploy
 - Project has a test framework installed but zero tests written (first-time test generation)
-- User says "test", "run tests", "verify", "check quality", "补测试"
+- User says "test", "run tests", "verify", "check quality", "add tests"
 
 ### When NOT to Use
 - Project has no test framework AND no code to test

package/bundled/skills/recovery-workflow/evals/evals.json

@@ -5,7 +5,7 @@
     {
       "id": 1,
       "name": "bugfix-mid-fix",
-      "prompt": "session 断了，帮我恢复一下",
+      "prompt": "My session broke, help me recover",
       "expected_output": "Should auto-detect bug-fix-workflow from fix/B-001-* branch. Should detect fix-plan.md + code changes → infer Phase 5 (Review). Should display recovery report with workflow type, phase, artifacts, code stats. After user confirms, should invoke /prizmkit-code-review on existing changes.",
       "setup_description": "Create fix/B-001-login-crash branch, .prizmkit/bugfix/B-001/fix-plan.md, modify 3 source files + 1 test file. No fix-report.md, no commits ahead of main.",
       "files": []
@@ -13,7 +13,7 @@
     {
       "id": 2,
       "name": "bugfix-plan-only",
-      "prompt": "继续之前的工作",
+      "prompt": "Continue the previous work",
       "expected_output": "Should auto-detect bug-fix-workflow from fix/B-002-* branch. Should detect fix-plan.md but no code changes → infer Phase 4 (Fix). Should read fix-plan.md and start implementing the fix.",
       "setup_description": "Create fix/B-002-null-pointer branch, .prizmkit/bugfix/B-002/fix-plan.md with diagnosis and fix approach. No code changes.",
       "files": []
@@ -37,7 +37,7 @@
     {
       "id": 5,
       "name": "no-workflow-detected",
-      "prompt": "恢复",
+      "prompt": "recover",
       "expected_output": "Should detect no workflow signatures in workspace. Should display guidance message suggesting /feature-workflow, /bug-fix-workflow, or /refactor-workflow. Should NOT attempt any recovery actions.",
       "setup_description": "Clean workspace on main branch. No .prizmkit/plans/feature-list.json, no bug-fix artifacts, no .prizmkit/plans/refactor-list.json, no fix/* or feat/* or refactor/* branches.",
       "files": []

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

@@ -239,9 +239,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-windows/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-windows/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-windows/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-windows/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-windows/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-windows/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-windows/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)
 

package/bundled/skills-windows/prizmkit-deploy/references/ssh-execution-flow.md

@@ -4,7 +4,7 @@ Pipeline runs in strict order. Each group must complete before the next begins.
 
 ## Pre-flight — Change Summary
 
-Show what will be deployed using `git log --oneline <last-deployed-commit>..HEAD`. If first deployment, show last 5 commits. If no new commits, warn "没有新的代码变更。确定要重新部署吗？"
+Show what will be deployed using `git log --oneline <last-deployed-commit>..HEAD`. If first deployment, show last 5 commits. If no new commits, warn "No new code changes. Are you sure you want to redeploy?"
 
 ## Group 1 — Pre-flight & Prepare
 

package/bundled/skills-windows/prizmkit-deploy/references/ssl-setup.md

@@ -15,11 +15,11 @@ Also check `/etc/hostname` for vendor patterns.
 ## Step 2 — Choose SSL strategy
 
 - **Cloud vendor detected** → ask user:
-  > "检测到服务器运行在 <云厂商>。用哪种 SSL 方案？"
-  > - **A. Let's Encrypt 免费证书（推荐）** — 一行命令永久自动续期，最省心
-  > - **B. <云厂商> 自有证书** — 需手动下载配置，1年有效期需手动续期
+  > "Detected the server is running on <cloud-vendor>. Which SSL approach?"
+  > - **A. Let's Encrypt free certificate (recommended)** — one command for permanent auto-renewal, hassle-free
+  > - **B. <cloud-vendor> native certificate** — manual download/config, 1-year validity requires manual renewal
   >
-  > 选 A 我直接帮你搞定；选 B 你需要在云控制台下载证书后告诉我路径。
+  > Choose A and I'll set it up for you; choose B and you'll need to download the certificate from the cloud console and tell me the path.
 - **No cloud vendor / unknown** → use certbot directly, no choice needed.
 
 ## Step 3 — Certbot install & certificate request

package/bundled/skills-windows/prizmkit-prizm-docs/assets/prizm-docs-format.md

@@ -544,7 +544,7 @@ JSON:
   "hooks": {
     "UserPromptSubmit": [
       {
-        "matcher": "(?i)\\b(commit|push|finish|ship|merge|pull request|pr)\\b|提交|推送|收尾|完成任务|合并|发版|发布",
+        "matcher": "(?i)\\b(commit|push|finish|ship|merge|pull request|pr)\\b",
         "hooks": [
           {
             "type": "command",

package/bundled/skills-windows/prizmkit-test/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: "prizmkit-test"
-description: "Full-stack test generation and orchestration. Detects architecture, discovers/runs existing tests, analyzes coverage gaps, generates missing unit/integration/E2E tests including business-specific boundary cases, validates every interface with a required boundary coverage matrix, and outputs a unified report. Use after completing development to verify quality before deploy. Trigger on: 'test', 'run tests', 'check quality', 'verify code', 'generate tests', 'test coverage', 'fill test gaps', 'boundary tests', 'edge cases', 'quality check', '测试', '验证', '跑测试', '补测试', '边界测试'. (project)"
+description: "Full-stack test generation and orchestration. Detects architecture, discovers/runs existing tests, analyzes coverage gaps, generates missing unit/integration/E2E tests including business-specific boundary cases, validates every interface with a required boundary coverage matrix, and outputs a unified report. Use after completing development to verify quality before deploy. Trigger on: 'test', 'run tests', 'check quality', 'verify code', 'generate tests', 'test coverage', 'fill test gaps', 'boundary tests', 'edge cases', 'quality check', 'add tests'. (project)"
 ---
 
 # PrizmKit Test
@@ -11,7 +11,7 @@ A comprehensive test generation and orchestration skill. Discovers existing test
 - After completing one or more features/refactors/bugfixes
 - As a quality gate before deploy
 - Project has a test framework installed but zero tests written (first-time test generation)
-- User says "test", "run tests", "verify", "check quality", "补测试"
+- User says "test", "run tests", "verify", "check quality", "add tests"
 
 ### When NOT to Use
 - Project has no test framework AND no code to test

package/bundled/skills-windows/recovery-workflow/evals/evals.json

@@ -5,7 +5,7 @@
     {
       "id": 1,
       "name": "bugfix-mid-fix",
-      "prompt": "session 断了，帮我恢复一下",
+      "prompt": "My session broke, help me recover",
       "expected_output": "Should auto-detect bug-fix-workflow from fix/B-001-* branch. Should detect fix-plan.md + code changes → infer Phase 5 (Review). Should display recovery report with workflow type, phase, artifacts, code stats. After user confirms, should invoke /prizmkit-code-review on existing changes.",
       "setup_description": "Create fix/B-001-login-crash branch, .prizmkit/bugfix/B-001/fix-plan.md, modify 3 source files + 1 test file. No fix-report.md, no commits ahead of main.",
       "files": []
@@ -13,7 +13,7 @@
     {
       "id": 2,
       "name": "bugfix-plan-only",
-      "prompt": "继续之前的工作",
+      "prompt": "Continue the previous work",
       "expected_output": "Should auto-detect bug-fix-workflow from fix/B-002-* branch. Should detect fix-plan.md but no code changes → infer Phase 4 (Fix). Should read fix-plan.md and start implementing the fix.",
       "setup_description": "Create fix/B-002-null-pointer branch, .prizmkit/bugfix/B-002/fix-plan.md with diagnosis and fix approach. No code changes.",
       "files": []
@@ -37,7 +37,7 @@
     {
       "id": 5,
       "name": "no-workflow-detected",
-      "prompt": "恢复",
+      "prompt": "recover",
       "expected_output": "Should detect no workflow signatures in workspace. Should display guidance message suggesting /feature-workflow, /bug-fix-workflow, or /refactor-workflow. Should NOT attempt any recovery actions.",
       "setup_description": "Clean workspace on main branch. No .prizmkit/plans/feature-list.json, no bug-fix artifacts, no .prizmkit/plans/refactor-list.json, no fix/* or feat/* or refactor/* branches.",
       "files": []

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "prizmkit",
-  "version": "1.1.95",
+  "version": "1.1.96",
   "description": "Create a new PrizmKit-powered project with clean initialization — no framework dev files, just what you need.",
   "type": "module",
   "bin": {