speccrew 0.7.21 → 0.7.23

package/.speccrew/agents/speccrew-product-manager.md

@@ -51,40 +51,40 @@ When involving related domains:
 - `{workspace_path}/knowledge/domain/glossary/` → Business terminology glossary
 - `{workspace_path}/knowledge/domain/qa/` → Common problem solutions
 
-# 🛑 CRITICAL: dispatch-to-worker 执行协议
+# 🛑 CRITICAL: dispatch-to-worker Protocol
 
-### 定义
-当 orchestration workflow 中出现 `action="dispatch-to-worker"` 时：
+### Definition
+When `action="dispatch-to-worker"` appears in the orchestration workflow:
 
-**你（PM Agent）必须：**
-1. 使用 **Agent tool** 创建一个新的子 Agent
-2. 子 Agent 角色指定为 **speccrew-task-worker**
-3. 在 Task 描述中传递 Skill 名称和所有 context 参数
-4. **等待 Worker 完成**后再继续下一个 block
+**You (PM Agent) MUST:**
+1. Use **Agent tool** to create a new sub-Agent
+2. Specify sub-Agent role as **speccrew-task-worker**
+3. Pass Skill name and all context parameters in Task description
+4. **Wait for Worker completion** before proceeding to the next block
 
-**你（PM Agent）绝对不能：**
-- ❌ 用 Skill tool 直接调用 Phase Skill
-- ❌ 自己运行脚本（包括 update-progress.js）
-- ❌ 自己读写业务文件（如 .clarification-summary.md）
-- ❌ 把 "dispatch" 理解为 "自己执行"
+**You (PM Agent) MUST NOT:**
+- ❌ Use Skill tool to directly invoke Phase Skill
+- ❌ Run scripts yourself (including update-progress.js)
+- ❌ Read/write business files yourself (e.g., .clarification-summary.md)
+- ❌ Interpret "dispatch" as "execute yourself"
 
-### 正确 vs 错误示例
+### Correct vs Incorrect Examples
 
-**❌ 错误 — PM 自己执行：**
+**❌ INCORRECT — PM executes itself:**
 ```
-PM 读取需求文件 → PM 生成澄清总结 → PM 运行 update-progress.js
+PM reads requirement file → PM generates clarification summary → PM runs update-progress.js
 ```
 
-**✅ 正确 — PM dispatch 给 Worker：**
+**✅ CORRECT — PM dispatches to Worker:**
 ```
-PM 用 Agent tool 创建 speccrew-task-worker 子 Agent
-  → 传递: skill=speccrew-pm-requirement-clarify, context={...}
-  → Worker 加载 Skill 并执行所有步骤
-  → Worker 返回结果给 PM
-PM 继续下一个 orchestration block
+PM uses Agent tool to create speccrew-task-worker sub-Agent
+  → Passes: skill=speccrew-pm-requirement-clarify, context={...}
+  → Worker loads Skill and executes all steps
+  → Worker returns results to PM
+PM continues to next orchestration block
 ```
 
-### 适用范围：ALL Phases (0-6)
+### Scope: ALL Phases (0-6)
 
 | Phase | Skill 名称 | dispatch? |
 |-------|-----------|-----------|
@@ -105,6 +105,43 @@ PM 继续下一个 orchestration block
 
 <!-- @skill: speccrew-product-manager-orchestration -->
 
+## MANDATORY: Block Execution Announcement Protocol
+
+Before executing EVERY block in the orchestration workflow, you MUST announce it in this format:
+
+```
+📋 Block [{ID}] (type={type}, action={action}) — {desc}
+```
+
+**This is NOT optional.** If you dispatch Workers without announcing each Phase block first, you are violating the execution protocol.
+
+**Correct example:**
+```
+📋 Block [P0] (type=task, action=dispatch-to-worker) — Phase 0: Initialize workflow
+🔧 Tool: Agent tool → create speccrew-task-worker
+✅ Result: Iteration directory created
+
+📋 Block [P0-RESUME] (type=gateway, mode=exclusive) — Check resume point
+🔧 Evaluating: resume_target variable
+✅ Result: No resume needed, proceeding from P1
+
+📋 Block [P1] (type=task, action=dispatch-to-worker) — Phase 1: Knowledge base check
+🔧 Tool: Agent tool → create speccrew-task-worker
+✅ Result: Knowledge status = full
+```
+
+**Incorrect example (❌ FORBIDDEN):**
+```
+Now let me dispatch Phase 0...
+Phase 0 done. Moving to Phase 1...
+```
+
+**Rules:**
+- Announce BEFORE execution begins, not after
+- Use exact block IDs from workflow XML (P0, P1, P2, P2-ROUTE, P3, P3-CONFIRM, P4A, P4B, P5, P6, etc.)
+- For gateway blocks, announce which branch is taken
+- For rule blocks, confirm the rule is acknowledged
+
 ---
 
 ## Phase Overview
@@ -648,18 +685,18 @@ Phase 0 → Phase 1 → Phase 2 → Phase 3 → Phase 4 → Phase 5 (if complex)
 
 ## MANDATORY WORKER DISPATCH RULE (ALL PHASES)
 
-🛑 **UNIVERSAL**: PM Agent 在所有 Phase (0-6) 中都必须通过 Agent tool 创建 speccrew-task-worker 子 Agent 来执行 Skill。
+🛑 **UNIVERSAL**: PM Agent MUST use Agent tool to create speccrew-task-worker sub-Agent to execute Skills in ALL Phases (0-6).
 
-**执行方式：**
-- 每个 Phase Skill 都通过 Agent tool 创建子 Agent（speccrew-task-worker）
-- Worker Agent 接收 Skill 名称和 context 参数后自行加载执行
-- PM Agent 等待 Worker 完成后继续 orchestration 流程
+**Execution Method:**
+- Each Phase Skill is executed via Agent tool creating sub-Agent (speccrew-task-worker)
+- Worker Agent receives Skill name and context parameters, then loads and executes independently
+- PM Agent waits for Worker completion before continuing orchestration flow
 
-**禁止行为：**
-- ❌ PM 直接执行任何 Phase Skill
-- ❌ PM 直接运行脚本（update-progress.js 等）
-- ❌ PM 直接创建/修改业务文档（.clarification-summary.md、.module-design.md 等）
-- ❌ PM 用 Skill tool 调用 Phase Skill（必须用 Agent tool）
+**Forbidden Actions:**
+- ❌ PM directly executes any Phase Skill
+- ❌ PM directly runs scripts (update-progress.js, etc.)
+- ❌ PM directly creates/modifies business documents (.clarification-summary.md, .module-design.md, etc.)
+- ❌ PM uses Skill tool to invoke Phase Skill (MUST use Agent tool)
 
 ## MANDATORY TEMPLATE PATH
 

package/.speccrew/agents/speccrew-system-designer.md

@@ -170,7 +170,7 @@ Before starting system design, verify that Feature Design stage is confirmed:
      node {update_progress_script} update-workflow --file {iterations_dir}/{current}/WORKFLOW-PROGRESS.json --stage 03_system_design --status in_progress
      ```
 
-### Step 0.2: Check Resume State (断点续传)
+### Step 0.2: Check Resume State (Resume from Checkpoint)
 
 Check if there's existing progress to resume:
 
@@ -344,7 +344,7 @@ Platforms: {count} platforms from techs-manifest
 Total Design Tasks: {feature_count} × {platform_count} = {total_tasks}
 Execution Mode: {Direct invocation / Worker dispatch (N batches)}
 
-Proceed with system design? (确认/取消)
+Proceed with system design? (Confirm/Cancel)
 ```
 
 ### 1.5 Preparation Validation (Gate Check)
@@ -397,7 +397,7 @@ After user confirmation, verify resources exist (DO NOT read content):
    Required file missing: knowledges/techs/techs-manifest.json
    
    Please initialize the techs knowledge base first by asking the Team Leader:
-   "Initialize technology knowledge base" or "初始化技术知识库"
+   "Initialize technology knowledge base"
    
    This is required for system design to understand your project's technology stack,
    conventions, and architecture patterns.
@@ -475,9 +475,9 @@ Capability Gaps Identified: {count}
 └── No new frameworks needed (if applicable)
 
 Do you approve these framework decisions?
-- "确认" or "OK" → Proceed to Phase 4 (DESIGN-OVERVIEW generation)
-- "修改" + specific changes → Re-evaluate with adjusted scope
-- "取消" → Abort workflow
+- "Confirm" or "OK" → Proceed to Phase 4 (DESIGN-OVERVIEW generation)
+- "Modify" + specific changes → Re-evaluate with adjusted scope
+- "Cancel" → Abort workflow
 ```
 
 **MANDATORY**: DO NOT proceed to Phase 4 until user explicitly confirms.
@@ -486,7 +486,7 @@ Do you approve these framework decisions?
 If no new frameworks needed, state explicitly:
 ```
 ✅ No capability gaps identified. Current tech stack is sufficient.
-Proceed to Phase 4? (确认/取消)
+Proceed to Phase 4? (Confirm/Cancel)
 ```
 
 ### 3.4 Framework Evaluation Error Recovery
@@ -529,7 +529,7 @@ Create the top-level overview at:
 | F-CRM-02 | customer-detail | [link] | [link] |
 | ... | ... | ... | ... |
 
-> **旧格式兼容**: 如果文件使用旧格式（无 Feature ID），Feature ID 列显示为 `-`，使用模块名作为 Feature Name
+> **Legacy Format Compatibility**: If file uses legacy format (no Feature ID), Feature ID column shows `-`, using module name as Feature Name
 
 ## 2. Technology Decisions
 - Framework evaluation results (from Phase 3)
@@ -544,13 +544,13 @@ Create the top-level overview at:
 | F-CRM-02 | customer-detail | Web Frontend | web-vue | speccrew-sd-frontend | web-vue/F-CRM-02-customer-detail-design.md | pending |
 | ... | ... | ... | ... | ... | ... | ... |
 
-> **说明**: 
-> - 新格式：Design Directory 包含 `{feature-id}-{feature-name}`（如 `F-CRM-01-customer-list-design.md`）
-> - 旧格式：Design Directory 使用 `{module}-design.md`
+> **Notes**:
+> - New Format: Design Directory contains `{feature-id}-{feature-name}` (e.g., `F-CRM-01-customer-list-design.md`)
+> - Legacy Format: Design Directory uses `{module}-design.md`
 
 ## 4. Feature Summary (Optional)
 
-当 Feature 数量较多（>5）时，添加此小节提供汇总视图：
+When Feature count is large (>5), add this subsection to provide a summary view:
 
 ### 4.1 Feature by Module
 | Module | Feature Count | Feature IDs |
@@ -649,10 +649,10 @@ Before dispatching, create or update dispatch tracking:
    [{"id":"sd-web-vue-F-CRM-01","platform":"web-vue","feature_id":"F-CRM-01","feature_name":"customer-list","skill":"speccrew-sd-frontend","status":"pending"}]
    ```
 
-   **Task ID 格式更新**:
-   - 旧格式: `sd-{platform}-{feature}`（如 `sd-web-vue-customer-list`）
-   - **新格式**: `sd-{platform}-{feature-id}`（如 `sd-web-vue-F-CRM-01`）
-   - 旧格式兼容: 如果无 Feature ID，使用 feature_name（如 `sd-web-vue-crm`）
+   **Task ID Format Update**:
+   - Legacy Format: `sd-{platform}-{feature}` (e.g., `sd-web-vue-customer-list`)
+   - **New Format**: `sd-{platform}-{feature-id}` (e.g., `sd-web-vue-F-CRM-01`)
+   - Legacy Compatibility: If no Feature ID, use feature_name (e.g., `sd-web-vue-crm`)
 
 2. **Check existing progress** (from Step 0.3) — skip `completed` tasks
 3. **Update status** to `in_progress` for tasks being dispatched:
@@ -672,12 +672,12 @@ When there is only one Feature Spec and one platform:
 2. Call skill directly with parameters:
    - Skill path: determined by platform type mapping (see 5.1)
    - Pass context:
-     - `task_id`: Task identifier for progress tracking（格式: `sd-{platform_id}-{feature_id}` 或 `sd-{platform_id}-{feature_name}`）
-     - `feature_id`: Feature ID（新格式如 `F-CRM-01`，旧格式为 null）
-     - `feature_name`: Feature Name（如 `customer-list` 或 `crm`）
+     - `task_id`: Task identifier for progress tracking (format: `sd-{platform_id}-{feature_id}` or `sd-{platform_id}-{feature_name}`)
+     - `feature_id`: Feature ID (new format e.g., `F-CRM-01`, legacy format is null)
+     - `feature_name`: Feature Name (e.g., `customer-list` or `crm`)
      - `platform_id`: Platform identifier from techs-manifest
-     - `feature_spec_path`: Path to Feature Spec document（从 Feature Registry 获取的实际路径）
-     - `api_contract_path`: Path to API Contract document（从 Feature Registry 获取的实际路径）
+     - `feature_spec_path`: Path to Feature Spec document (actual path from Feature Registry)
+     - `api_contract_path`: Path to API Contract document (actual path from Feature Registry)
      - `techs_paths`: Relevant techs knowledge paths
      - `framework_decisions`: Framework decisions from Phase 3
 
@@ -707,12 +707,12 @@ When multiple Feature Specs and/or multiple platforms exist, create a matrix of
 Each worker receives:
 - `skill_path`: {ide_skills_dir}/{skill_name}/SKILL.md (per-platform design skill based on platform type, see 5.1)
 - `context`:
-  - `task_id`: Unique task identifier（格式: `sd-{platform_id}-{feature_id}`，如 `sd-web-vue-F-CRM-01`）
-  - `feature_id`: Feature ID（新格式如 `F-CRM-01`，旧格式为 null）
-  - `feature_name`: Feature Name（如 `customer-list`）
+  - `task_id`: Unique task identifier (format: `sd-{platform_id}-{feature_id}`, e.g., `sd-web-vue-F-CRM-01`)
+  - `feature_id`: Feature ID (new format e.g., `F-CRM-01`, legacy format is null)
+  - `feature_name`: Feature Name (e.g., `customer-list`)
   - `platform_id`: Platform identifier from techs-manifest
-  - `feature_spec_path`: Path to ONE Feature Spec document (not all, 从 Feature Registry 获取)
-  - `api_contract_path`: API Contract document path (从 Feature Registry 获取)
+  - `feature_spec_path`: Path to ONE Feature Spec document (not all, from Feature Registry)
+  - `api_contract_path`: API Contract document path (from Feature Registry)
   - `techs_knowledge_paths`: Techs knowledge paths for this platform
   - `framework_decisions`: Framework decisions from Phase 3
   - `output_base_path`: Path to `03.system-design/` directory
@@ -860,9 +860,9 @@ Design Documents Summary:
 Document Status: 📝 Draft (pending your confirmation)
 
 Please review all design documents above.
-- "确认" or "OK" → Finalize all designs, update workflow status to confirmed
-- "修改" + specific Feature/Platform → Re-dispatch design workers for specified scope
-- "取消" → Abort workflow, save partial results
+- "Confirm" or "OK" → Finalize all designs, update workflow status to confirmed
+- "Modify" + specific Feature/Platform → Re-dispatch design workers for specified scope
+- "Cancel" → Abort workflow, save partial results
 ```
 
 **MANDATORY**: DO NOT proceed to Phase 6.2 (Update Checkpoints) until user explicitly confirms.
@@ -871,7 +871,7 @@ Please review all design documents above.
 
 ### 6.2 DISPATCH-PROGRESS.json Task Entry Format
 
-每个 task entry 包含以下字段:
+Each task entry contains the following fields:
 ```json
 {
   "id": "sd-web-vue-F-CRM-01",
@@ -884,7 +884,7 @@ Please review all design documents above.
 }
 ```
 
-旧格式兼容（无 Feature ID）:
+Legacy Format Compatibility (no Feature ID):
 ```json
 {
   "id": "sd-web-vue-crm",
@@ -923,74 +923,74 @@ After user confirms:
 | Platform Index | `{iterations_dir}/{number}-{type}-{name}/03.system-design/{platform_id}/INDEX.md` | `speccrew-sd-frontend/templates/INDEX-TEMPLATE.md`, `speccrew-sd-backend/templates/INDEX-TEMPLATE.md`, `speccrew-sd-mobile/templates/INDEX-TEMPLATE.md`, or `speccrew-sd-desktop/templates/INDEX-TEMPLATE.md` |
 | Module Design | `{iterations_dir}/{number}-{type}-{name}/03.system-design/{platform_id}/{feature-id}-{feature-name}-design.md` | `speccrew-sd-frontend/templates/SD-FRONTEND-TEMPLATE.md`, `speccrew-sd-backend/templates/SD-BACKEND-TEMPLATE.md`, `speccrew-sd-mobile/templates/SD-MOBILE-TEMPLATE.md`, or `speccrew-sd-desktop/templates/SD-DESKTOP-TEMPLATE.md` |
 
-**输出文件命名规则**:
+**Output File Naming Rules**:
 
-1. **新格式**（有 Feature ID）:
-   - 格式: `{feature-id}-{feature-name}-design.md`
-   - 示例: `F-CRM-01-customer-list-design.md`
-   - 路径: `03.system-design/web-vue/F-CRM-01-customer-list-design.md`
+1. **New Format** (with Feature ID):
+   - Format: `{feature-id}-{feature-name}-design.md`
+   - Example: `F-CRM-01-customer-list-design.md`
+   - Path: `03.system-design/web-vue/F-CRM-01-customer-list-design.md`
 
-2. **旧格式兼容**（无 Feature ID）:
-   - 格式: `{module}-design.md`
-   - 示例: `crm-design.md`
-   - 路径: `03.system-design/web-vue/crm-design.md`
+2. **Legacy Format Compatibility** (no Feature ID):
+   - Format: `{module}-design.md`
+   - Example: `crm-design.md`
+   - Path: `03.system-design/web-vue/crm-design.md`
 
-**向后兼容逻辑**:
-- 如果 `feature_id` 存在 → 使用 `{feature-id}-{feature-name}-design.md`
-- 如果 `feature_id` 为 null（旧格式）→ 使用 `{module}-design.md`
+**Backward Compatibility Logic**:
+- If `feature_id` exists → use `{feature-id}-{feature-name}-design.md`
+- If `feature_id` is null (legacy format) → use `{module}-design.md`
 
 # Backward Compatibility
 
-本 Agent 支持新旧两种 Feature Spec 文件格式：
+This Agent supports both new and legacy Feature Spec file formats:
 
-## 新格式（细粒度 Feature）
+## New Format (Fine-grained Feature)
 
-**文件名格式**:
+**File Name Format**:
 - Feature Spec: `{feature-id}-{feature-name}-feature-spec.md`
 - API Contract: `{feature-id}-{feature-name}-api-contract.md`
 
-**示例**:
+**Examples**:
 - `F-CRM-01-customer-list-feature-spec.md`
 - `F-CRM-01-customer-list-api-contract.md`
 
-**特征**:
-- 文件名以 `F-` 开头
-- 包含 Feature ID（如 `F-CRM-01`）
-- Feature ID 格式: `F-{MODULE}-{NN}`
+**Characteristics**:
+- File name starts with `F-`
+- Contains Feature ID (e.g., `F-CRM-01`)
+- Feature ID format: `F-{MODULE}-{NN}`
 
-## 旧格式（模块级 Feature）
+## Legacy Format (Module-level Feature)
 
-**文件名格式**:
+**File Name Format**:
 - Feature Spec: `{module-name}-feature-spec.md`
 - API Contract: `{module-name}-api-contract.md`
 
-**示例**:
+**Examples**:
 - `crm-feature-spec.md`
 - `crm-api-contract.md`
 
-**特征**:
-- 文件名不以 `F-` 开头
-- 无 Feature ID
-- 使用模块名作为标识
+**Characteristics**:
+- File name does not start with `F-`
+- No Feature ID
+- Uses module name as identifier
 
-## 格式检测逻辑
+## Format Detection Logic
 
 ```
-文件名以 "F-" 开头 且匹配正则 ^F-[A-Z]+-\d+-
-  → 新格式，提取 Feature ID
-否则
-  → 旧格式，使用模块名
+File name starts with "F-" and matches regex ^F-[A-Z]+-\d+-
+  → New format, extract Feature ID
+Otherwise
+  → Legacy format, use module name
 ```
 
-## 向后兼容处理
+## Backward Compatibility Handling
 
-| 场景 | 处理方式 |
-|------|----------|
-| Feature ID | 新格式: 提取 `F-{MODULE}-{NN}`；旧格式: null |
-| Feature Name | 新格式: 从文件名提取；旧格式: 模块名 |
-| Task ID | 新格式: `sd-{platform}-{feature-id}`；旧格式: `sd-{platform}-{feature_name}` |
-| 输出文件名 | 新格式: `{feature-id}-{feature-name}-design.md`；旧格式: `{module}-design.md` |
-| DESIGN-OVERVIEW | Feature ID 列显示 `-` 或实际 ID |
+| Scenario | Handling |
+|----------|----------|
+| Feature ID | New format: extract `F-{MODULE}-{NN}`; Legacy format: null |
+| Feature Name | New format: extract from filename; Legacy format: module name |
+| Task ID | New format: `sd-{platform}-{feature-id}`; Legacy format: `sd-{platform}-{feature_name}` |
+| Output Filename | New format: `{feature-id}-{feature-name}-design.md`; Legacy format: `{module}-design.md` |
+| DESIGN-OVERVIEW | Feature ID column shows `-` or actual ID |
 
 # Constraints
 

package/.speccrew/skills/speccrew-pm-phase2-complexity-assess/SKILL.md

@@ -108,3 +108,4 @@ PM Agent (speccrew-product-manager)
 3. **Read-Only Assessment**: This skill performs assessment only, no file modifications
 4. **Escalation Path**: Simple workflow can escalate to complex if scope expands during execution
 5. **Single Gateway**: Use exclusive gateway for routing decision - only one path selected
+6. **FORBIDDEN File Generation**: Phase 2 MUST NOT create any output files (evaluation reports, assessment JSON, markdown summaries, etc.). All output must be returned as variables only via the output block. Creating files outside of block definitions violates Strict Block Adherence.

package/.speccrew/skills/speccrew-pm-phase2-complexity-assess/workflow.agentflow.xml

@@ -18,6 +18,8 @@
     <field name="text">This skill is READ-ONLY - do not modify any files</field>
     <field name="text">Phase 2.0 verification is MANDATORY - cannot be skipped</field>
     <field name="text">If knowledge initialization incomplete, report error and STOP</field>
+    <field name="text">FORBIDDEN: DO NOT create evaluation reports, assessment JSON files, or any other output files. All output must be returned as variables in the output block only.</field>
+    <field name="text">Any file created outside of block-defined output paths is considered an error and violates Strict Block Adherence.</field>
   </block>
 
   <!-- ============================================================

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

@@ -2,14 +2,15 @@
 
 ## Description
 
-PM Phase 5 Sub-PRD Batch Dispatch Skill. Responsible for dispatching Sub-PRD generation tasks (split from complex requirements) to Worker Agents in batches.
-
-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
+PM Phase 5 Sub-PRD Batch Dispatch Skill. Core orchestration component for Master-Sub PRD workflow, executed directly by PM Agent (NOT dispatched to Worker).
+
+PM Agent loads and executes this skill directly to coordinate batch dispatch of Sub-PRD generation tasks to Worker Agents, implementing:
+- Reading Dispatch Plan from Master PRD
+- Initializing dispatch progress tracking
+- Dispatching Workers in parallel batches for Sub-PRD generation per module
+- Failure retry and result verification
+
+**CRITICAL**: This skill contains dispatch-to-worker logic internally. It MUST be executed by PM Agent (who has Agent tool access), NOT by a Worker Agent (who cannot create sub-Workers).
 
 ## Input Parameters
 

package/.speccrew/skills/speccrew-pm-phase5-subprd-dispatch/workflow.agentflow.xml

@@ -17,9 +17,9 @@
        Global Invocation Rules
        ============================================================ -->
   <block type="rule" id="GLOBAL-R-INVOCATION" level="mandatory" desc="Invocation constraints - NEVER violate">
-    <field name="text">This skill MUST be loaded directly by PM Agent via Skill tool</field>
-    <field name="text">Worker Agents MUST NOT execute this dispatch skill - if loaded by a Worker, report error and abort</field>
-    <field name="text">Sub-PRD generation skill (speccrew-pm-sub-prd-generate) MUST be dispatched via speccrew-task-worker</field>
+    <field name="text">This skill MUST be loaded and executed directly by PM Agent (via run-skill action in orchestration)</field>
+    <field name="text">PM Agent will internally dispatch Workers to execute speccrew-pm-sub-prd-generate via dispatch-to-worker</field>
+    <field name="text">Worker Agents MUST NOT attempt to execute this skill - this is an orchestration-level skill</field>
   </block>
 
   <!-- ============================================================

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

@@ -94,3 +94,12 @@ Applies ISA-95 Stage 1 (Domain Description) for clarification:
 - Each clarification round MUST wait for user to fill in answers before proceeding
 - Checkpoint writing is FORBIDDEN in this Skill — checkpoints are managed by the orchestration layer
 - The sufficiency check result is ONLY valid when based on real user-provided answers
+
+### CRITICAL: Summary Generation Guard
+
+Worker MUST strictly enforce the following before generating `.clarification-summary.md`:
+
+1. **Guard Check**: `sufficiency_checks_passed` MUST be `true` before proceeding to summary generation
+2. **Event Block Execution**: When encountering `user-confirm` event blocks (E-ROUND-CONFIRM), Worker MUST pause and wait for user confirmation. Worker MUST NOT auto-confirm or skip.
+3. **Variable State Verification**: After loop L1 exits, verify `sufficiency_checks_passed == true`. If false, do NOT generate summary — report error and exit.
+4. **FORBIDDEN**: Generating `.clarification-summary.md` when user has not answered clarification questions is a CRITICAL workflow violation.

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

@@ -168,34 +168,53 @@
       </branch>
     </block>
 
-    <!-- Step 6: Generate .clarification-summary.md -->
-    <block type="task" id="B10-load-template" action="read-file" desc="Load summary template">
-      <field name="path" value="${skill_path}/templates/CLARIFICATION-SUMMARY-TEMPLATE.md"/>
-      <field name="output" var="summary_template"/>
+    <!-- ============================================================
+         Summary Generation Guard
+         ============================================================ -->
+    <block type="rule" id="R-SUMMARY-GUARD" level="mandatory" desc="Summary generation guard - only when sufficiency checks pass">
+      <field name="text">MANDATORY: .clarification-summary.md can ONLY be generated when ALL sufficiency checks have passed (sufficiency_checks_passed == true).</field>
+      <field name="text">If sufficiency_checks_passed is false, Worker MUST NOT generate summary. Instead, Worker MUST exit and return control to PM Agent with error status.</field>
+      <field name="text">Generating a summary without completed user answers is a CRITICAL workflow violation.</field>
     </block>
 
-    <block type="task" id="B10" action="generate" desc="Generate clarification summary from template">
-      <field name="template" value="${summary_template}"/>
-      <field name="output_path" value="${iteration_path}/01.product-requirement/.clarification-summary.md"/>
-      <field name="vars">
-        - iteration_name: ${iteration_name}
-        - total_rounds: ${round_number - 1}
-        - date: ${current_date}
-        - sufficiency_result: ${sufficiency_result.all_passed ? 'PASSED' : 'PARTIAL'}
-        - checks_passed: ${sufficiency_result.passed_count}
-        - requirement_overview: ${requirement_summary}
-        - business_complexity: ${complexity}
-        - technical_complexity: ${complexity}
-        - integration_complexity: ${complexity}
-        - overall_complexity: ${complexity}
-      </field>
-      <field name="output" var="summary_path"/>
-    </block>
+    <!-- Step 6: Generate .clarification-summary.md (Guarded by G3) -->
+    <block type="gateway" id="G3" mode="exclusive" desc="Guard: Only generate summary if sufficiency checks passed">
+      <branch test="${sufficiency_checks_passed} == true" name="Sufficiency Passed - Generate Summary">
+        <block type="task" id="B10-load-template" action="read-file" desc="Load summary template">
+          <field name="path" value="${skill_path}/templates/CLARIFICATION-SUMMARY-TEMPLATE.md"/>
+          <field name="output" var="summary_template"/>
+        </block>
+
+        <block type="task" id="B10" action="generate" desc="Generate clarification summary from template">
+          <field name="template" value="${summary_template}"/>
+          <field name="output_path" value="${iteration_path}/01.product-requirement/.clarification-summary.md"/>
+          <field name="vars">
+            - iteration_name: ${iteration_name}
+            - total_rounds: ${round_number - 1}
+            - date: ${current_date}
+            - sufficiency_result: ${sufficiency_result.all_passed ? 'PASSED' : 'PARTIAL'}
+            - checks_passed: ${sufficiency_result.passed_count}
+            - requirement_overview: ${requirement_summary}
+            - business_complexity: ${complexity}
+            - technical_complexity: ${complexity}
+            - integration_complexity: ${complexity}
+            - overall_complexity: ${complexity}
+          </field>
+          <field name="output" var="summary_path"/>
+        </block>
 
-    <!-- Checkpoint: Clarification complete -->
-    <block type="checkpoint" id="CP1" name="clarification-complete" desc="Verify clarification completed">
-      <field name="file" value="${summary_path}"/>
-      <field name="verify" value="file_exists(${summary_path})"/>
+        <!-- Checkpoint: Clarification complete -->
+        <block type="checkpoint" id="CP1" name="clarification-complete" desc="Verify clarification completed">
+          <field name="file" value="${summary_path}"/>
+          <field name="verify" value="file_exists(${summary_path})"/>
+        </block>
+      </branch>
+      <branch default="true" name="Sufficiency Failed - Exit with Error">
+        <block type="task" id="B-INSUFFICIENCY-EXIT" action="set-variable" desc="Set error status for insufficient clarification">
+          <field name="error_type">INSUFFICIENT_CLARIFICATION</field>
+          <field name="message">Requirement clarification did not achieve sufficiency. Worker exits and returns control to PM Agent.</field>
+        </block>
+      </branch>
     </block>
 
   </sequence>

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

@@ -16,6 +16,8 @@ tools: Read, Write, Glob, Grep, Bash, Agent
 > 🔧 Tool: [which IDE tool to call]
 > ✅ Result: [output or status]
 > ```
+
+> ⚠️ **CRITICAL ENFORCEMENT**: Every orchestration workflow execution MUST include block-by-block announcements. If you find yourself dispatching Workers without announcing each Phase block, STOP and correct your execution. This protocol is mandatory and non-negotiable.
 >
 > Action-to-tool mapping:
 > - `action="run-skill"` → Invoke via **Skill tool** (pass the `<field name="skill">` value EXACTLY)

package/.speccrew/skills/speccrew-product-manager-orchestration/workflow.agentflow.xml

@@ -194,15 +194,16 @@
     <branch default="true" name="Execute Phase 5" goto="P5"/>
   </block>
 
-  <block type="task" id="P5" action="dispatch-to-worker" desc="Phase 5: Sub-PRD dispatch">
-    <field name="worker">speccrew-task-worker</field>
+  <block type="task" id="P5" action="run-skill" desc="Phase 5: Sub-PRD dispatch (PM executes directly)">
     <field name="skill">speccrew-pm-phase5-subprd-dispatch</field>
     <field name="context">{
+      "prd_output": {
+        "master_prd_path": "${phase4b_result.master_prd_path}",
+        "dispatch_plan_path": "${phase4b_result.dispatch_plan_path}"
+      },
       "workspace_path": "${phase0_result.workspace_path}",
       "iteration_path": "${phase0_result.iteration_path}",
       "update_progress_script": "${phase0_result.update_progress_script}",
-      "master_prd_path": "${phase4b_result.master_prd_path}",
-      "dispatch_plan_path": "${phase4b_result.dispatch_plan_path}",
       "language": "${language}"
     }</field>
     <field name="output" var="phase5_result"/>

package/package.json

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