speccrew 0.7.19 → 0.7.21

package/.speccrew/skills/speccrew-pm-phase5-subprd-dispatch/SKILL.md

@@ -2,93 +2,93 @@
 
 ## Description
 
-PM Phase 5 Sub-PRD 批量派遣 Skill。负责将复杂需求拆分后的 Sub-PRD 生成任务批量派遣给 Worker Agents 执行。
+PM Phase 5 Sub-PRD Batch Dispatch Skill. Responsible for dispatching Sub-PRD generation tasks (split from complex requirements) to Worker Agents in batches.
 
-本 Skill 是 Master-Sub PRD 工作流的核心编排组件，实现：
-- 从 Master PRD 读取 Dispatch Plan（Sub-PRD 分组信息）
-- 初始化派遣进度追踪文件 DISPATCH-PROGRESS.json
-- 批量并行派遣 Workers 生成各模块 Sub-PRD
-- 失败重试机制（最多 1 次）
-- 结果收集与完整性验证
+This Skill is the core orchestration component of the Master-Sub PRD workflow, implementing:
+- Reading Dispatch Plan from Master PRD (Sub-PRD grouping information)
+- Initializing dispatch progress tracking file DISPATCH-PROGRESS.json
+- Batch parallel dispatch of Workers to generate Sub-PRDs for each module
+- Failure retry mechanism (max 1 retry)
+- Result collection and completeness verification
 
 ## Input Parameters
 
 | Parameter | Type | Required | Description |
 |-----------|------|----------|-------------|
-| `prd_output` | object | true | Phase 4 PRD 生成输出，包含 master_prd_path、dispatch_plan_path 等 |
-| `iteration_path` | string | true | 当前迭代目录绝对路径 |
-| `language` | string | false | 用户语言（默认 zh） |
-| `workspace_path` | string | true | speccrew-workspace 根目录绝对路径 |
-| `update_progress_script` | string | true | update-progress.js 脚本绝对路径 |
-| `max_concurrent_workers` | number | false | 最大并行 Worker 数（默认 5） |
+| `prd_output` | object | true | Phase 4 PRD generation output, containing master_prd_path, dispatch_plan_path, etc. |
+| `iteration_path` | string | true | Absolute path to current iteration directory |
+| `language` | string | false | User language (default: zh) |
+| `workspace_path` | string | true | Absolute path to speccrew-workspace root directory |
+| `update_progress_script` | string | true | Absolute path to update-progress.js script |
+| `max_concurrent_workers` | number | false | Maximum concurrent Workers (default: 5) |
 
 ## Outputs
 
 | Output | Type | Description |
 |--------|------|-------------|
-| `dispatch_result` | string | 派遣结果状态：success / partial / failed |
-| `total_subprds` | number | Sub-PRD 总数 |
-| `success_count` | number | 成功生成的 Sub-PRD 数量 |
-| `failure_count` | number | 失败的 Sub-PRD 数量 |
-| `sub_prd_files` | array | 生成的 Sub-PRD 文件路径列表 |
-| `feature_list_path` | string | Feature List 文件路径 |
+| `dispatch_result` | string | Dispatch result status: success / partial / failed |
+| `total_subprds` | number | Total Sub-PRD count |
+| `success_count` | number | Successfully generated Sub-PRD count |
+| `failure_count` | number | Failed Sub-PRD count |
+| `sub_prd_files` | array | List of generated Sub-PRD file paths |
+| `feature_list_path` | string | Feature List file path |
 
 <!-- @agentflow: workflow.agentflow.xml -->
 
 ## Checklist
 
-### Step 5.1: 读取 Dispatch Plan
-- [ ] 读取 Master PRD 中的 dispatch-plan（Sub-PRD 分组信息）
-- [ ] 解析 sub_prd_groups 数组
-- [ ] 验证每组包含必需字段：module_id, module_name, module_key, module_scope, module_entities
-
-### Step 5.2: 初始化进度追踪
-- [ ] 创建临时任务定义文件 .tasks-temp.json
-- [ ] 使用 update-progress.js 脚本初始化 DISPATCH-PROGRESS.json
-- [ ] 验证初始化成功（Total: N | Pending: N | Completed: 0）
-
-### Step 5.3: 批量派遣 Workers
-- [ ] 按 5 个一批分组进行并行派遣
-- [ ] 每个 Worker 携带完整 context 参数
-- [ ] 每批完成后更新 DISPATCH-PROGRESS.json
-- [ ] 继续下一批直到所有模块处理完成
-
-### Step 5.4: 失败重试
-- [ ] 检查是否有 failed 状态的任务
-- [ ] 有失败 -> 重试一次（单次重试机制）
-- [ ] 重试后仍有失败 -> 记录并继续
-
-### Step 5.5: 结果收集与验证
-- [ ] 读取最终 DISPATCH-PROGRESS.json
-- [ ] 验证所有 Sub-PRD 文件存在且大小 > 3KB
-- [ ] 生成汇总报告
-- [ ] 更新 checkpoint
-- [ ] 验证 feature list 完整性
-
-### Step 5.6: 用户确认
-- [ ] 等待用户确认 Sub-PRD 生成结果
+### Step 5.1: Read Dispatch Plan
+- [ ] Read dispatch-plan from Master PRD (Sub-PRD grouping information)
+- [ ] Parse sub_prd_groups array
+- [ ] Verify each group contains required fields: module_id, module_name, module_key, module_scope, module_entities
+
+### Step 5.2: Initialize Progress Tracking
+- [ ] Create temporary task definition file .tasks-temp.json
+- [ ] Initialize DISPATCH-PROGRESS.json using update-progress.js script
+- [ ] Verify initialization success (Total: N | Pending: N | Completed: 0)
+
+### Step 5.3: Batch Dispatch Workers
+- [ ] Group in batches of 5 for parallel dispatch
+- [ ] Each Worker carries complete context parameters
+- [ ] Update DISPATCH-PROGRESS.json after each batch completes
+- [ ] Continue to next batch until all modules are processed
+
+### Step 5.4: Failure Retry
+- [ ] Check for tasks with failed status
+- [ ] If failures exist -> retry once (single retry mechanism)
+- [ ] If still failing after retry -> log and continue
+
+### Step 5.5: Result Collection and Verification
+- [ ] Read final DISPATCH-PROGRESS.json
+- [ ] Verify all Sub-PRD files exist and size > 3KB
+- [ ] Generate summary report
+- [ ] Update checkpoint
+- [ ] Verify feature list completeness
+
+### Step 5.6: User Confirmation
+- [ ] Wait for user confirmation of Sub-PRD generation results
 
 ## Key Rules
 
-### MANDATORY - Worker 派遣规则
-- **ONE Worker per Module** - 每个 Sub-PRD 模块派遣一个独立 Worker
-- **禁止 PM 自行生成** - PM Agent 不得直接生成 Sub-PRD 内容
-- **必须通过 dispatch-to-worker** - 所有 Worker 必须通过 `dispatch-to-worker` action 执行
-- **禁止直接调用 Skill** - 不得直接调用 `speccrew-pm-sub-prd-generate` skill
-
-### MANDATORY - 批处理规则
-- **Batch Size = 5** - 每批最多 5 个并行 Worker
-- **并行派遣** - 同一批次的 Worker 必须同时派遣
-- **顺序等待** - 等待当前批次完成后再派遣下一批
-- **进度更新** - 每个 Worker 完成后立即更新 DISPATCH-PROGRESS.json
-
-### MANDATORY - 进度追踪规则
-- **脚本初始化** - DISPATCH-PROGRESS.json 必须通过 update-progress.js 创建
-- **禁止手动创建** - 不得通过 create_file 或 PowerShell 直接创建进度文件
-- **幂等更新** - 使用 `update-task` 命令更新单个任务状态
-
-### FORBIDDEN - 禁止行为
-- 禁止 PM Agent 直接生成 Sub-PRD 文件
-- 禁止派遣一个 Worker 处理多个模块
-- 禁止跳过 Worker 派遣作为失败后的回退方案
-- 禁止在用户确认前标记 checkpoint 为 passed
+### MANDATORY - Worker Dispatch Rules
+- **ONE Worker per Module** - Dispatch one independent Worker per Sub-PRD module
+- **PM Must Not Generate Directly** - PM Agent must NOT directly generate Sub-PRD content
+- **Must Use dispatch-to-worker** - All Workers must be executed via `dispatch-to-worker` action
+- **Direct Skill Invocation Forbidden** - Must NOT directly invoke `speccrew-pm-sub-prd-generate` skill
+
+### MANDATORY - Batch Processing Rules
+- **Batch Size = 5** - Maximum 5 parallel Workers per batch
+- **Parallel Dispatch** - Workers in the same batch must be dispatched simultaneously
+- **Sequential Wait** - Wait for current batch to complete before dispatching next batch
+- **Progress Update** - Immediately update DISPATCH-PROGRESS.json after each Worker completes
+
+### MANDATORY - Progress Tracking Rules
+- **Script Initialization** - DISPATCH-PROGRESS.json must be created via update-progress.js
+- **Manual Creation Forbidden** - Must NOT create progress files directly via create_file or PowerShell
+- **Idempotent Update** - Use `update-task` command to update individual task status
+
+### FORBIDDEN - Prohibited Actions
+- PM Agent directly generating Sub-PRD files is forbidden
+- Dispatching one Worker to handle multiple modules is forbidden
+- Skipping Worker dispatch as a fallback after failure is forbidden
+- Marking checkpoint as passed before user confirmation is forbidden

package/.speccrew/skills/speccrew-pm-phase6-verify-confirm/SKILL.md

@@ -35,7 +35,7 @@ Applies three-stage gated verification:
 
 ## PM Stage Content Boundary
 
-> **DO NOT:** Update checkpoints before user confirmation, skip user review gate, auto-proceed without explicit "确认" or "OK", modify PRD document status before confirmation.
+> **DO NOT:** Update checkpoints before user confirmation, skip user review gate, auto-proceed without explicit "confirm" or "OK", modify PRD document status before confirmation.
 
 ## Templates Used
 
@@ -75,7 +75,7 @@ Applies three-stage gated verification:
 
 **Must do:**
 - Execute all verification steps in order: 6.1 → 6.2 → 6.3
-- Wait for explicit user confirmation ("确认" or "OK") before Phase 6.3
+- Wait for explicit user confirmation ("confirm" or "OK") before Phase 6.3
 - Use `update-progress.js` for all JSON file updates
 - Present complete verification summary to user
 - Report all deliverables with file paths and sizes

package/.speccrew/skills/speccrew-pm-requirement-clarify/templates/CLARIFICATION-QUESTIONS-TEMPLATE.md

@@ -1,49 +1,49 @@
-# 需求澄清问卷 - Round {round_number}
+# Requirement Clarification Questionnaire - Round {round_number}
 
 > **Iteration**: {iteration_name}
 > **Date**: {date}
 > **Complexity**: {complexity_level}
 
-## 澄清背景
+## Clarification Context
 
-基于用户需求："{requirement_summary}"，以下问题需要进一步确认。
+Based on the user requirement: "{requirement_summary}", the following items need further clarification.
 
-## 待确认事项
+## Items to Confirm
 
-### 🎯 业务范围与边界
+### 🎯 Business Scope & Boundaries
 
-| # | 问题 | 优先级 | 用户回答 |
+| # | Question | Priority | User Answer |
 |---|------|--------|---------|
-| 1 | {question} | {priority} | _待回答_ |
+| 1 | {question} | {priority} | _To be answered_ |
 
-### 👥 用户角色与权限
+### 👥 User Roles & Permissions
 
-| # | 问题 | 优先级 | 用户回答 |
+| # | Question | Priority | User Answer |
 |---|------|--------|---------|
-| 1 | {question} | {priority} | _待回答_ |
+| 1 | {question} | {priority} | _To be answered_ |
 
-### 🔄 业务规则与流程
+### 🔄 Business Rules & Processes
 
-| # | 问题 | 优先级 | 用户回答 |
+| # | Question | Priority | User Answer |
 |---|------|--------|---------|
-| 1 | {question} | {priority} | _待回答_ |
+| 1 | {question} | {priority} | _To be answered_ |
 
-### 🔗 集成与依赖
+### 🔗 Integration & Dependencies
 
-| # | 问题 | 优先级 | 用户回答 |
+| # | Question | Priority | User Answer |
 |---|------|--------|---------|
-| 1 | {question} | {priority} | _待回答_ |
+| 1 | {question} | {priority} | _To be answered_ |
 
-### ⚡ 性能与约束
+### ⚡ Performance & Constraints
 
-| # | 问题 | 优先级 | 用户回答 |
+| # | Question | Priority | User Answer |
 |---|------|--------|---------|
-| 1 | {question} | {priority} | _待回答_ |
+| 1 | {question} | {priority} | _To be answered_ |
 
 ---
 
-## 填写说明
+## Instructions
 
-1. 请在"用户回答"列直接填写您的回答
-2. 如果某个问题不适用，请填写"N/A"并简要说明原因
-3. 如需补充信息，可在回答后追加说明
+1. Please fill in your answers directly in the "User Answer" column
+2. If a question is not applicable, enter "N/A" with a brief explanation
+3. If additional information is needed, you may append notes after your answer

package/.speccrew/skills/speccrew-pm-requirement-clarify/templates/CLARIFICATION-SUMMARY-TEMPLATE.md

@@ -1,52 +1,52 @@
-# 需求澄清总结
+# Requirement Clarification Summary
 
 > **Iteration**: {iteration_name}
 > **Total Rounds**: {total_rounds}
 > **Date**: {date}
 > **Final Sufficiency**: {sufficiency_result} ({checks_passed}/4)
 
-## 1. 需求概述
+## 1. Requirement Overview
 
 {requirement_overview}
 
-## 2. 复杂度评估
+## 2. Complexity Assessment
 
-| 维度 | 评估 | 理由 |
+| Dimension | Assessment | Rationale |
 |------|------|------|
-| 业务复杂度 | {business_complexity} | {reason} |
-| 技术复杂度 | {technical_complexity} | {reason} |
-| 集成复杂度 | {integration_complexity} | {reason} |
-| **综合判定** | **{overall_complexity}** | |
+| Business Complexity | {business_complexity} | {reason} |
+| Technical Complexity | {technical_complexity} | {reason} |
+| Integration Complexity | {integration_complexity} | {reason} |
+| **Overall Assessment** | **{overall_complexity}** | |
 
-## 3. 关键决策记录
+## 3. Key Decision Log
 
-| # | 决策项 | 决策结果 | 确认轮次 |
+| # | Decision Item | Decision Result | Confirmed Round |
 |---|--------|---------|---------|
 | 1 | {decision_item} | {decision_result} | Round {N} |
 
-## 4. 澄清 Q&A 汇总
+## 4. Clarification Q&A Summary
 
 ### Round {N}
 
-| # | 问题 | 回答 | 分类 |
+| # | Question | Answer | Category |
 |---|------|------|------|
 | 1 | {question} | {answer} | {category} |
 
-## 5. 充分性检查结果
+## 5. Sufficiency Check Results
 
-| # | 检查项 | 状态 | 说明 |
+| # | Check Item | Status | Detail |
 |---|--------|------|------|
-| 1 | 范围边界清晰 | {status} | {detail} |
-| 2 | 关键业务规则已文档化 | {status} | {detail} |
-| 3 | 优先级/分期决策已确定 | {status} | {detail} |
-| 4 | 集成边界已识别 | {status} | {detail} |
+| 1 | Scope boundaries are clear | {status} | {detail} |
+| 2 | Key business rules documented | {status} | {detail} |
+| 3 | Priority/phasing decisions made | {status} | {detail} |
+| 4 | Integration boundaries identified | {status} | {detail} |
 
-## 6. 遗留问题与风险
+## 6. Open Issues & Risks
 
-| # | 问题/风险 | 影响 | 建议处理方式 |
+| # | Issue/Risk | Impact | Suggested Resolution |
 |---|----------|------|------------|
 | 1 | {issue} | {impact} | {suggestion} |
 
-## 7. 下一步建议
+## 7. Next Steps
 
 {next_steps}

package/.speccrew/skills/speccrew-pm-requirement-model/SKILL.md

@@ -76,3 +76,13 @@ Applies ISA-95 Stages 1-3 as structured analysis framework:
 - Include technical implementation details
 - Create circular module dependencies
 - Manually write JSON files
+
+### Diagram Format Rule (MANDATORY)
+- All diagrams MUST use Mermaid syntax (graph TB, graph TD, graph LR, etc.)
+- ASCII art diagrams are FORBIDDEN
+- Reference `mermaid-rule.md` for compatibility
+
+### Template
+- Module design document MUST follow `templates/MODULE-DESIGN-TEMPLATE.md` structure
+- All 10 sections are required
+- Fill template with analyzed data from ISA-95 stages

package/.speccrew/skills/speccrew-pm-requirement-model/templates/MODULE-DESIGN-TEMPLATE.md

@@ -0,0 +1,175 @@
+# Module Design Document (.module-design.md)
+
+> **Iteration**: iteration_name
+> **Generated**: date
+> **System**: system_name
+> **Tech Stack**: tech_stack
+> **Document Type**: ISA-95 Business Modeling & Module Decomposition
+
+---
+
+## 1. Business Domain Analysis (ISA-95 Stage 1: Domain Description)
+
+### 1.1 Domain Boundary Definition
+
+<!-- Describe system positioning -->
+
+#### System Scope (IN-SCOPE)
+| Domain | Description |
+|--------|-------------|
+| domain | description |
+
+#### Out of Scope (OUT-OF-SCOPE)
+| Domain | Description | Planned Phase |
+|--------|-------------|---------------|
+| domain | description | phase |
+
+### 1.2 Actor Definition
+| Actor ID | Actor Name | Responsibilities | Data Scope | Typical Scenario |
+|----------|------------|------------------|------------|------------------|
+| role_id | role_name | responsibility | data_scope | scenario |
+
+### 1.3 Core Business Glossary
+| Term | Definition | Business Rule | Related Module |
+|------|------------|---------------|----------------|
+| term | definition | rule | module |
+
+### 1.4 Domain Model Diagram
+
+```mermaid
+graph TB
+    M01[M01 System Foundation] --> M02[M02 Module Name]
+    M01 --> M04[M04 Module Name]
+    M02 --> M03[M03 Module Name]
+    %% Draw based on actual module dependencies
+```
+
+---
+
+## 2. Function Decomposition (ISA-95 Stage 2: Functions in Domain)
+
+### 2.1 WBS Work Breakdown Structure
+
+#### module_id - module_name (count function points)
+| Function ID | Function Name | Description | Priority | Dependencies |
+|-------------|---------------|-------------|----------|--------------|
+| func_id | func_name | description | priority | dependency |
+
+### 2.2 Function Priority Distribution
+| Priority | Function Points | Percentage | Module Distribution |
+|----------|-----------------|------------|--------------------|
+| **P0 (Core)** | count | percent | modules |
+| **P1 (Important)** | count | percent | modules |
+| **P2 (Optional)** | count | percent | modules |
+
+---
+
+## 3. Module Priority & Phasing (ISA-95 Stage 3: Functions of Interest)
+
+### 3.1 MoSCoW Priority Analysis
+| Priority | Definition | Module | Description |
+|----------|------------|--------|-------------|
+
+### 3.2 Implementation Phases
+
+#### Phase 1 (MVP - Minimum Viable Product)
+**Core Chain**: core_chain
+| Module | Function Points | Deliverables |
+|--------|-----------------|--------------|
+
+**MVP Acceptance Criteria**:
+- ✅ criteria
+
+#### Phase 2 (Full Version - Stage 1)
+<!-- Same structure as above -->
+
+#### Phase 3 (Stage 2 Planning)
+<!-- Same structure as above -->
+
+---
+
+## 4. Module Dependencies
+
+### 4.1 Dependency Matrix
+| Module | Dependent Module | Dependency Type | Description |
+|--------|------------------|-----------------|-------------|
+
+### 4.2 Dependency Graph
+
+```mermaid
+graph TD
+    M01[M01 System Foundation] --> M02[M02 Module Name]
+    M01 --> M04[M04 Module Name]
+    M02 --> M03[M03 Module Name]
+    %% Draw directed acyclic graph based on dependency matrix
+```
+
+### 4.3 Circular Dependency Check
+<!-- Must confirm no circular dependencies -->
+
+---
+
+## 5. Module Implementation Sequence
+
+### 5.1 Implementation Phase Ordering
+
+```mermaid
+graph LR
+    P0[Phase 0: Infrastructure] --> P1[Phase 1: Core Entities]
+    P1 --> P2[Phase 2: Core Workflows]
+    P2 --> P3[Phase 3: Value-Added Features]
+    P3 --> P4[Phase 4: Data Analytics]
+    %% Adjust based on actual phases
+```
+
+### 5.2 Parallel Development Recommendations
+| Phase | Parallel Modules | Description |
+|-------|------------------|-------------|
+
+---
+
+## 6. Module Boundary Definition
+
+### 6.1 Module Responsibility Boundaries
+| Module | Core Responsibilities | Excluded Responsibilities | Boundary Notes |
+|--------|----------------------|--------------------------|----------------|
+
+### 6.2 Data Ownership
+| Data Entity | Owner Module | Read-Only Modules | Description |
+|-------------|--------------|-------------------|-------------|
+
+---
+
+## 7. Tech Stack Capability Reuse Analysis
+
+### 7.1 Reusable Capabilities
+| Required Function | Existing Capability | Reuse Level | Development Effort | Notes |
+|-------------------|---------------------|-------------|--------------------|-------|
+
+### 7.2 New Development Capabilities
+| Capability | Module | Development Priority | Estimated Effort | Notes |
+|------------|--------|---------------------|------------------|-------|
+
+---
+
+## 8. Risks & Mitigation Measures
+
+### 8.1 Technical Risks
+| Risk Item | Affected Modules | Impact Level | Probability | Mitigation Measures |
+|-----------|------------------|--------------|-------------|---------------------|
+
+### 8.2 Business Risks
+| Risk Item | Affected Modules | Impact Level | Probability | Mitigation Measures |
+|-----------|------------------|--------------|-------------|---------------------|
+
+---
+
+## 9. Module Summary
+| Module ID | Module Name | Function Points | Priority | Implementation Phase | Dependencies | Core Responsibilities |
+|-----------|-------------|-----------------|----------|---------------------|--------------|-----------------------|
+
+---
+
+## 10. Sign-off
+| Role | Name | Date | Signature |
+|------|------|------|-----------|

package/.speccrew/skills/speccrew-pm-requirement-model/workflow.agentflow.xml

@@ -27,6 +27,12 @@
     <field name="text">Manually write JSON files</field>
   </block>
 
+  <block type="rule" id="R-MERMAID" level="mandatory" desc="All diagrams must use Mermaid syntax">
+    <field name="text">MANDATORY: All diagrams (domain model, dependency graph, implementation phases) MUST use Mermaid syntax.</field>
+    <field name="text">ASCII art diagrams are FORBIDDEN. Use graph TB, graph TD, graph LR as appropriate.</field>
+    <field name="text">Reference workspace-template/docs/rules/mermaid-rule.md for compatibility guidelines.</field>
+  </block>
+
   <!-- ============================================================
        Main Processing Sequence
        ============================================================ -->
@@ -161,8 +167,15 @@
       </branch>
     </block>
 
+    <!-- Read module design template -->
+    <block type="task" id="B10-TPL" action="read-file" desc="Read module design template">
+      <field name="path">${skill_path}/templates/MODULE-DESIGN-TEMPLATE.md</field>
+      <field name="output" var="template_content"/>
+    </block>
+
     <!-- Step 4: Generate .module-design.md -->
     <block type="task" id="B11" action="generate" desc="Generate module design document">
+      <field name="template" value="${template_content}"/>
       <field name="output_path" value="${iteration_path}/01.product-requirement/.module-design.md"/>
       <field name="sections">
         - ISA-95 Analysis Summary (if complex)

package/.speccrew/skills/speccrew-product-manager-orchestration/SKILL.md

@@ -1,7 +1,7 @@
 ---
 name: speccrew-product-manager-orchestration
 version: 2.0.0
-description: Product Manager 核心编排技能（纯路由层 v2.0），负责工作流恢复路由和各 Phase Skill 的 dispatch-to-worker 调度。所有业务逻辑由独立的 Phase Skill 执行。
+description: Product Manager core orchestration skill (pure routing layer v2.0), responsible for workflow resume routing and dispatch-to-worker scheduling for each Phase Skill. All business logic is executed by independent Phase Skills.
 tools: Read, Write, Glob, Grep, Bash, Agent
 ---
 
@@ -34,32 +34,32 @@ tools: Read, Write, Glob, Grep, Bash, Agent
 
 # Product Manager Orchestration (v2.0)
 
-纯路由层编排技能，负责：
+Pure routing layer orchestration skill, responsible for:
 
-1. **Workflow Initialization** - Phase 0 初始化并返回恢复目标
-2. **Resume Routing** - 根据 `resume_target` 跳转到正确的 Phase
-3. **Phase Dispatch** - 每个 Phase 只有一个 `dispatch-to-worker` 调用
-4. **User Confirmation Gates** - Phase 3 和 Phase 4a 的强制性用户确认门禁
+1. **Workflow Initialization** - Phase 0 initialization and returning resume target
+2. **Resume Routing** - Jump to the correct Phase based on `resume_target`
+3. **Phase Dispatch** - Each Phase has only one `dispatch-to-worker` call
+4. **User Confirmation Gates** - Mandatory user confirmation gates for Phase 3 and Phase 4a
 
 ## Architecture: Pure Routing Layer
 
-本 Skill 是**纯路由层**，所有业务逻辑由独立的 Phase Skill 执行：
+This Skill is a **pure routing layer**, all business logic is executed by independent Phase Skills:
 
 | Phase | Block ID | Skill | Purpose |
 |-------|----------|-------|---------|
-| Phase 0 | P0 | `speccrew-pm-phase0-init` | 工作流初始化、迭代目录创建/定位、恢复状态检测 |
-| Phase 1 | P1 | `speccrew-pm-phase1-knowledge-check` | 知识库状态检测、模块匹配、知识初始化 |
-| Phase 2 | P2 | `speccrew-pm-phase2-complexity-assess` | 复杂度评估、简单/复杂路径决策 |
-| Phase 3 | P3 | `speccrew-pm-requirement-clarify` | 需求澄清、问答收集 |
-| Phase 4 Simple | P4-SIMPLE | `speccrew-pm-requirement-simple` | 简单需求：单 PRD 生成 |
-| Phase 4a | P4A | `speccrew-pm-requirement-model` | 复杂需求：ISA-95 建模 |
-| Phase 4b | P4B | `speccrew-pm-requirement-analysis` | 复杂需求：Master PRD 生成 |
-| Phase 5 | P5 | `speccrew-pm-phase5-subprd-dispatch` | Sub-PRD Worker 分发 |
-| Phase 6 | P6 | `speccrew-pm-phase6-verify-confirm` | 验证清单、用户审核、最终确认 |
+| Phase 0 | P0 | `speccrew-pm-phase0-init` | Workflow initialization, iteration directory creation/locating, resume state detection |
+| Phase 1 | P1 | `speccrew-pm-phase1-knowledge-check` | Knowledge base status detection, module matching, knowledge initialization |
+| Phase 2 | P2 | `speccrew-pm-phase2-complexity-assess` | Complexity assessment, simple/complex path decision |
+| Phase 3 | P3 | `speccrew-pm-requirement-clarify` | Requirement clarification, Q&A collection |
+| Phase 4 Simple | P4-SIMPLE | `speccrew-pm-requirement-simple` | Simple requirements: single PRD generation |
+| Phase 4a | P4A | `speccrew-pm-requirement-model` | Complex requirements: ISA-95 modeling |
+| Phase 4b | P4B | `speccrew-pm-requirement-analysis` | Complex requirements: Master PRD generation |
+| Phase 5 | P5 | `speccrew-pm-phase5-subprd-dispatch` | Sub-PRD Worker dispatch |
+| Phase 6 | P6 | `speccrew-pm-phase6-verify-confirm` | Verification checklist, user review, final confirmation |
 
 ## User Confirmation Gates (MANDATORY)
 
-Phase 3 和 Phase 4a 之后有**强制性用户确认门禁**：
+There are **mandatory user confirmation gates** after Phase 3 and Phase 4a:
 
 ### R-CONFIRM Rule Block
 
@@ -81,24 +81,24 @@ Phase 3 和 Phase 4a 之后有**强制性用户确认门禁**：
 ```
 
 **Key Points:**
-- `action="user-confirm"` — 必须等待用户明确确认
-- `skippable="false"` — 不可跳过
-- checkpoint 写入**必须**在用户确认后执行
+- `action="user-confirm"` — Must wait for explicit user confirmation
+- `skippable="false"` — Cannot be skipped
+- Checkpoint write **MUST** be executed after user confirmation
 
 ## Resume Router
 
-Phase 0 输出 `resume_target` 控制恢复跳转：
+Phase 0 outputs `resume_target` to control resume routing:
 
 | resume_target | Target Block | Description |
 |---------------|--------------|-------------|
-| `PHASE_1_KNOWLEDGE_CHECK` | P1 | 从知识库检查开始 |
-| `PHASE_3_USER_CONFIRMATION` | P3-CONFIRM | 恢复到 Phase 3 确认门禁 |
-| `PHASE_4_PRD_SIMPLE` | P4-SIMPLE | 简单路径 PRD 生成 |
-| `PHASE_4A_MODEL` | P4A | 复杂路径建模 |
-| `PHASE_4A_CONFIRMATION` | P4A-CONFIRM | 恢复到 Phase 4a 确认门禁 |
-| `PHASE_4B_PRD_GENERATION` | P4B | Master PRD 生成 |
-| `PHASE_5_SUBPRD_DISPATCH` | P5 | Sub-PRD 分发 |
-| `PHASE_6_VERIFICATION` | P6 | 验证确认 |
+| `PHASE_1_KNOWLEDGE_CHECK` | P1 | Start from knowledge base check |
+| `PHASE_3_USER_CONFIRMATION` | P3-CONFIRM | Resume to Phase 3 confirmation gate |
+| `PHASE_4_PRD_SIMPLE` | P4-SIMPLE | Simple path PRD generation |
+| `PHASE_4A_MODEL` | P4A | Complex path modeling |
+| `PHASE_4A_CONFIRMATION` | P4A-CONFIRM | Resume to Phase 4a confirmation gate |
+| `PHASE_4B_PRD_GENERATION` | P4B | Master PRD generation |
+| `PHASE_5_SUBPRD_DISPATCH` | P5 | Sub-PRD dispatch |
+| `PHASE_6_VERIFICATION` | P6 | Verification and confirmation |
 
 ## Invocation Method
 
@@ -114,18 +114,18 @@ Phase 0 输出 `resume_target` 控制恢复跳转：
 
 | Parameter | Type | Required | Description |
 |-----------|------|----------|-------------|
-| `user_requirement` | string | Yes | 用户需求描述或需求文档路径 |
-| `workspace_root` | string | Yes | speccrew-workspace 根目录路径 |
-| `source_path` | string | No | 项目源代码根目录（从 .speccrewrc 读取） |
-| `language` | string | No | 用户语言（默认自动检测） |
+| `user_requirement` | string | Yes | User requirement description or requirement document path |
+| `workspace_root` | string | Yes | speccrew-workspace root directory path |
+| `source_path` | string | No | Project source code root directory (read from .speccrewrc) |
+| `language` | string | No | User language (default auto-detect) |
 
 ## Output
 
-- `status` - 执行状态 (success / partial / failed)
-- `prd_files` - 生成的 PRD 文件列表
-- `feature_list` - 功能清单文件路径
-- `workflow_stage` - 当前工作流阶段状态
-- `next_agent` - 下一步建议的 Agent
+- `status` - Execution status (success / partial / failed)
+- `prd_files` - List of generated PRD files
+- `feature_list` - Feature list file path
+- `workflow_stage` - Current workflow stage status
+- `next_agent` - Recommended next Agent
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "speccrew",
-  "version": "0.7.19",
+  "version": "0.7.21",
   "description": "Spec-Driven Development toolkit for AI-powered IDEs",
   "author": "charlesmu99",
   "repository": {