speccrew 0.7.22 → 0.7.24

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/agents/speccrew-task-worker.md

@@ -30,10 +30,18 @@ This agent MUST execute tasks continuously without unnecessary interruptions.
 
 ### When to Pause (ONLY these cases)
 
-1. CHECKPOINT gates defined in workflow (user confirmation required by design)
-2. Ambiguous requirements that genuinely need clarification
-3. Unrecoverable errors that prevent further progress
-4. Security-sensitive operations (e.g., deleting existing files)
+1. **Event blocks with user interaction** (HIGHEST PRIORITY):
+   - `<block type="event" action="user-confirm">` — MUST pause and present prompt to user, wait for explicit confirmation
+   - This applies even in automated dispatch scenarios — user-confirm events override Worker autonomy
+   - FORBIDDEN: Skipping, auto-confirming, or bypassing with reasoning like "automated execution scenario"
+
+2. CHECKPOINT gates defined in workflow (user confirmation required by design)
+
+3. Ambiguous requirements that genuinely need clarification
+
+4. Unrecoverable errors that prevent further progress
+
+5. Security-sensitive operations (e.g., deleting existing files)
 
 ### Batch Execution Behavior
 

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-requirement-clarify/SKILL.md

@@ -86,7 +86,10 @@ Applies ISA-95 Stage 1 (Domain Description) for clarification:
 - Manually write JSON files
 - Auto-proceed to Phase 4 (PRD generation) without PM Agent's user confirmation gate
 - Auto-pass sufficiency checks without actual user answers
-- Write checkpoints in this Skill — checkpoints are managed by orchestration layer
+- **Checkpoint management is FORBIDDEN in this Skill**
+  - MUST NOT create, write, or modify `.checkpoints.json` or any checkpoint files
+  - Checkpoint write operations are the responsibility of the orchestration layer (PM Agent)
+  - After this Skill completes, PM Agent writes checkpoints ONLY after user confirmation is received
 
 ### MANDATORY: User Answer Verification Rule
 
@@ -94,3 +97,19 @@ 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: User Confirmation Event Enforcement
+
+1. **Event Block = Hard Stop**: Each `<block type="event" action="user-confirm">` (E-ROUND-CONFIRM) MUST trigger a pause. Worker MUST NOT proceed until user provides explicit confirmation.
+2. **No "Automated Scenario" Bypass**: Even in automated dispatch mode (speccrew-task-worker), `user-confirm` events override Worker autonomy. These are explicit user interaction gates, NOT internal automation points.
+3. **Template-Based Generation Only**: All clarification question files (`.clarification-questions-round-{N}.md`) MUST be generated using the loaded template (CLARIFICATION-QUESTIONS-TEMPLATE.md) with variable substitution. Freeform generation is FORBIDDEN.
+4. **Template-Based Summary Only**: The `.clarification-summary.md` MUST be generated using CLARIFICATION-SUMMARY-TEMPLATE.md with variable substitution. Freeform generation is FORBIDDEN.
+
+### 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

@@ -99,6 +99,13 @@
       <branch test="${complexity} == 'complex'" name="Complex Mode Clarification">
         <!-- Clarification Loop -->
         <block type="loop" id="L1" condition="sufficiency_checks_passed == false AND round_number <= max_rounds" desc="Clarification rounds until sufficiency">
+          <!-- MANDATORY: Template-based generation rule -->
+          <block type="rule" id="R-TEMPLATE-GENERATION" level="mandatory" desc="Template-based generation is MANDATORY">
+            <field name="text">MANDATORY: Clarification questions MUST be generated by loading the template file and performing variable substitution.</field>
+            <field name="text">FORBIDDEN: Freeform generation, manual writing, or creating clarification files without using the loaded template.</field>
+            <field name="text">The generated file must follow the template structure with all placeholders replaced by actual values.</field>
+          </block>
+
           <!-- Load Question Template -->
           <block type="task" id="B7-load-template" action="read-file" desc="Load clarification questions template">
             <field name="path" value="${skill_path}/templates/CLARIFICATION-QUESTIONS-TEMPLATE.md"/>
@@ -118,6 +125,13 @@
             <field name="output" var="questions_file"/>
           </block>
 
+          <!-- MANDATORY: User confirmation cannot be bypassed -->
+          <block type="rule" id="R-USER-CONFIRM-MANDATORY" level="mandatory" desc="User-confirm events MUST pause Worker execution">
+            <field name="text">MANDATORY: The following user-confirm event is a HARD STOP. Worker MUST pause and present the prompt to user.</field>
+            <field name="text">FORBIDDEN: Skipping, auto-confirming, or bypassing user-confirm events for ANY reason including "automated execution scenario".</field>
+            <field name="text">Worker MUST wait for explicit user response before proceeding to the next block.</field>
+          </block>
+
           <!-- MANDATORY: Wait for user to answer clarification questions -->
           <block type="event" id="E-ROUND-CONFIRM" action="user-confirm" desc="Wait for user to answer clarification questions">
             <field name="prompt">📋 第 ${round_number} 轮澄清问题已生成: ${questions_file}
@@ -168,34 +182,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>
 
-    <!-- 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 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})"/>
+        </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/package.json

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

package/workspace-template/docs/rules/agentflow-spec.md

@@ -184,6 +184,18 @@ Logging, confirmation, and signaling.
 - `action`: `log` | `confirm` | `signal`
 - `level` (for log): `debug` | `info` | `warn` | `error`
 
+#### User-Confirm Event Execution Rules (MANDATORY)
+
+When a Worker encounters `<block type="event" action="user-confirm">`:
+
+1. **MUST pause execution** — Stop all processing and present the prompt to the user
+2. **CANNOT be skipped or auto-confirmed** — Even if Worker considers the scenario "automated"
+3. **Applies to ALL execution modes** — Including dispatch-to-worker, batch processing, and automated scenarios
+4. **`skippable="false"` is absolute** — When set, no bypass mechanism is permitted under any circumstances
+5. **Variable preservation** — Before pausing, ensure all workflow variables are properly set for resumption
+
+`user-confirm` events represent **explicit user interaction gates** in the workflow. They exist to ensure human oversight at critical decision points and MUST NOT be optimized away.
+
 ### error-handler
 
 Try/catch/finally error handling.