speccrew 0.7.73 → 0.7.75

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

@@ -1,88 +1,15 @@
 ---
 name: speccrew-pm-requirement-model
-description: SpecCrew PM Requirement Modeling Skill. Applies ISA-95 Stages 1-3 for business domain analysis, WBS decomposition, and module ordering. Produces .module-design.md as interface contract for downstream PRD generation. Second step in PRD workflow.
+description: SpecCrew PM Requirement Modeling Skill. Applies ISA-95 Stages 1-3 for business domain analysis, WBS decomposition, and module ordering. Produces .module-design.md as interface contract.
 tools: Read, Write, Glob, Grep
 ---
 
-# Skill Overview
-
-ISA-95 business modeling and module decomposition. Produces `.module-design.md` as the interface contract for PRD generation.
-
-## Trigger Scenarios
-
-- Clarification completed (`.clarification-summary.md` exists)
+# Trigger Scenarios
+- Clarification completed (.clarification-summary.md exists)
 - Complex requirements requiring ISA-95 analysis
 - Multi-module system requiring decomposition
 
-## Input Parameters
-
-| Parameter | Type | Required | Description |
-|-----------|------|----------|-------------|
-| `iteration_path` | string | Yes | Path to iteration directory |
-| `clarification_file` | string | No | Path to clarification summary (default: `{iteration_path}/01.product-requirement/.clarification-summary.md`) |
-
-## Methodology Foundation
-
-Applies ISA-95 Stages 1-3 as structured analysis framework:
-
-| Stage | Purpose | Output |
-|-------|---------|--------|
-| Stage 1: Domain Description | Boundary, actors, glossary | Domain model |
-| Stage 2: Functions in Domain | WBS decomposition | Function map |
-| Stage 3: Functions of Interest | MoSCoW prioritization | MVP scope |
-
-## PM Stage Content Boundary
-
-> **DO NOT include:** API definitions, DB structures, code snippets, technical terminology. These belong to Feature Designer or System Designer.
-
----
-
-# AgentFlow Definition
-
+## AgentFlow Definition
 <!-- @agentflow: SKILL.xml -->
-
-> **REQUIRED**: Before executing this workflow, read the XML workflow specification: `speccrew-workspace/docs/rules/agentflow-spec.md`
-
----
-
-# Output Checklist
-
-- [ ] `.clarification-summary.md` verified (prerequisite)
-- [ ] ISA-95 Stage 1 complete (Domain Description)
-- [ ] Checkpoint A passed (domain boundary confirmed)
-- [ ] ISA-95 Stage 2 complete (Functions in Domain)
-- [ ] ISA-95 Stage 3 complete (Functions of Interest)
-- [ ] Checkpoint B passed (MVP scope confirmed)
-- [ ] Checkpoint C passed (complete analysis confirmed)
-- [ ] Module list defined
-- [ ] Dependency matrix created
-- [ ] Implementation phases determined
-- [ ] Module decomposition confirmed with user
-- [ ] `.module-design.md` created
-- [ ] `.checkpoints.json` updated via script
-
----
-
-# Constraints
-
-**Must do:**
-- Verify `.clarification-summary.md` exists before starting
-- Use 3 checkpoints (A/B/C) for progressive user confirmation
-- Define clear module boundaries with minimal coupling
-- Use `update-progress.js` for JSON files
-
-**Must not do:**
-- Skip user checkpoints in complex mode
-- 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
+> **REQUIRED**: Before executing this workflow, read the XML workflow specification: speccrew-workspace/docs/rules/agentflow-spec.md
+> Then read and execute the XML workflow in SKILL.xml block-by-block as the authoritative execution plan.

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

@@ -1,87 +1,15 @@
 ---
 name: speccrew-pm-requirement-simple
-description: SpecCrew PM Simple Requirement Skill. Handles lightweight requirements (field additions, minor feature changes, single-module enhancements) with a streamlined PRD generation process. Produces a single concise PRD document without Master-Sub structure or worker dispatch.
+description: SpecCrew PM Simple Requirement Skill. Handles lightweight requirements with a streamlined PRD generation process. Produces a single concise PRD document without Master-Sub structure.
 tools: Read, Write, Glob, Grep, Terminal
 ---
 
-# Skill Overview
-
-Simple requirement analysis skill for lightweight changes. Produces a single concise PRD.
-
-## Trigger Scenarios
-
+# Trigger Scenarios
 - User requests a small change (add field, modify behavior, fix workflow)
 - Requirement scope is within 1-2 modules
 - Estimated 1-5 Features
 
-## Methodology Foundation
-
-This skill applies ISA-95 Stages 1-3 in lightweight mode:
-
-| ISA-95 Stage | Lightweight Application |
-|---|---|
-| Stage 1: Domain Description | Quick scope confirmation (no formal glossary needed) |
-| Stage 2: Functions in Domain | Identify affected functions (no full WBS needed) |
-| Stage 3: Functions of Interest | All identified features are core (no MoSCoW filtering) |
-
-> **No separate modeling documents.** Lightweight mode focuses on speed and clarity.
-
-## PM Stage Content Boundary
-
-> **PM Stage Content Boundary — DO NOT include:**
-> - API endpoint definitions, HTTP methods, request/response JSON
-> - Design class diagrams, component diagrams, deployment diagrams
-> - Database table structures, ER diagrams, SQL queries
-> - Code snippets, pseudocode, implementation logic
-> - Technical terminology (e.g., UUID, JWT, REST, Microservice, JSON)
-> - Technical metrics (e.g., "code files", "latency < 100ms", "CPU usage")
->
-> These belong to **Feature Designer** (interaction design, API contracts) or **System Designer** (technical architecture).
->
-> **Required:** Use business language only. Describe WHAT business operation needs to happen, not HOW the system implements it.
-> ✅ "Customer can search by name" ❌ "SELECT * FROM customers WHERE name LIKE '%keyword%'"
-> ✅ "Show friendly error message" ❌ "return HTTP 400 Bad Request"
-
----
-
-## Prerequisites
-
-> 🚨 MANDATORY: `.clarification-summary.md` MUST exist in the current iteration directory.
-> This file is generated by the `speccrew-pm-requirement-clarify` skill.
-> IF `.clarification-summary.md` is missing → ABORT immediately.
-
----
-
 ## AgentFlow Definition
-
 <!-- @agentflow: SKILL.xml -->
-
-> **REQUIRED**: Before executing this workflow, read the XML workflow specification: `speccrew-workspace/docs/rules/agentflow-spec.md`
-
----
-
-## Output Checklist
-
-- [ ] `.clarification-summary.md` read and complexity verified
-- [ ] PRD file created at correct path
-- [ ] All relevant sections filled (skip empty optional sections)
-- [ ] No technical implementation details (no API, no code, no class diagrams)
-- [ ] Feature Breakdown table present with at least 1 feature
-- [ ] Acceptance criteria are concrete and testable
-- [ ] Business language only — no technical jargon
-
-## Constraints
-
-**Must do:**
-- Verify `.clarification-summary.md` exists before proceeding
-- Keep PRD concise — 1-3 page PRDs
-- Use business language throughout
-- Extract key decisions from clarification summary into PRD
-
-**Must not do:**
-- Proceed without `.clarification-summary.md`
-- Generate Master-Sub PRD structure
-- Dispatch worker agents
-- Generate API definitions, class diagrams, or technical artifacts
-- Wait for user confirmation (handled by PM Agent)
-- Auto-transition to Feature Design stage
+> **REQUIRED**: Before executing this workflow, read the XML workflow specification: speccrew-workspace/docs/rules/agentflow-spec.md
+> Then read and execute the XML workflow in SKILL.xml block-by-block as the authoritative execution plan.

package/.speccrew/skills/speccrew-pm-sub-prd-generate/SKILL.md

@@ -4,289 +4,11 @@ description: Generate a single Sub-PRD document for one module. Used by PM Agent
 tools: Read, Write, Glob, Grep
 ---
 
-## PM Stage Content Boundary
-
-> ⚠️ **This Sub-PRD MUST adhere to PM Stage Content Boundary:**
-> - NO API endpoint definitions, HTTP methods, request/response JSON
-> - NO Database table structures, ER diagrams, SQL queries
-> - NO Design class diagrams, component diagrams, deployment diagrams
-> - NO Code snippets, pseudocode, implementation logic
-> - NO Technical terminology (e.g., UUID, JWT, REST, Microservice, JSON)
-> - NO Technical metrics (e.g., "code files", "latency < 100ms", "CPU usage")
->
-> **Required:** Use BUSINESS LANGUAGE ONLY.
-> Describe WHAT business operation needs to happen, not HOW the system implements it.
->
-> **ABORT CONDITIONS:**
-> - IF any section being generated contains SQL, API definitions, or code → STOP
-> - IF inherited module_requirements contain technical details → Strip them, use business descriptions only
-
 # Trigger Scenarios
-
 - PM Agent dispatches worker to generate Sub-PRD for a specific module
 - Worker receives module context from PM Agent's dispatch plan
 
-# Input Parameters
-
-| Parameter | Required | Description |
-|-----------|----------|-------------|
-| module_id | Yes | Module ID for feature registry (e.g., "M1", "M2") |
-| module_name | Yes | Human-readable module name (e.g., "Customer Management") |
-| module_key | Yes | Module identifier for file naming (e.g., "customer") |
-| module_scope | Yes | What this module covers |
-| module_entities | Yes | Core business entities in this module |
-| module_user_stories | Yes | User stories specific to this module |
-| module_requirements | Yes | Functional requirements for this module (P0/P1/P2) |
-| module_features | Yes | Feature Breakdown entries for this module (Feature IDs, Types, Dependencies) |
-| module_dependencies | No | Dependencies on other modules |
-| master_prd_path | Yes | Path to the Master PRD (for cross-referencing) |
-| feature_name | Yes | System-level feature name (for file naming prefix) |
-| template_path | Yes | Path to PRD-TEMPLATE.md |
-| output_path | Yes | Full path for the Sub-PRD output file |
-
-# Absolute Constraints
-
-> **These rules apply to ALL document generation steps. Violation = task failure.**
-
-1. **FORBIDDEN: Full-file rewrite** — NEVER replace the entire document content in a single operation. Always use targeted `search_replace` on specific sections.
-2. **MANDATORY: Template-first workflow** — Copy template MUST execute before filling sections.
-
-# AgentFlow Definition
-
+## AgentFlow Definition
 <!-- @agentflow: SKILL.xml -->
-
-> **REQUIRED**: Before executing this workflow, read the XML workflow specification: `speccrew-workspace/docs/rules/agentflow-spec.md`
-
----
-
-## Step 1: Load Context
-
-1. Read Master PRD at `{master_prd_path}` to understand:
-   - System-wide background and goals
-   - Cross-module dependency matrix
-   - This module's position in the overall system
-
-2. Read PRD template at `{template_path}`
-
-## Step 2: Create Sub-PRD File
-
-1. Copy template content to `{output_path}` using `create_file`
-2. Replace the title: `# PRD - [Feature Name]` → `# Sub-PRD - {module_name}`
-
-## Step 3: Fill Module-Specific Content
-
-> **⚠️ CRITICAL: Two-Phase Strategy (Skeleton-First, Content-After)**
->
-> This step MUST be executed in two phases to ensure consistent document structure.
-
-### Phase A: Skeleton Construction (BEFORE any content filling)
-
-1. Read PRD-TEMPLATE.md to identify the complete section structure
-2. Count the number of features from `{module_features}` input
-3. For Section 3.5 Feature Details, replicate the template's Feature block structure for EACH feature:
-   - Copy the EXACT template structure (all 6 sub-sections) from PRD-TEMPLATE.md
-   - Create `#### Feature 1: {feature_name}` through `#### Feature N: {feature_name}`
-   - Each feature block MUST contain these 6 sub-section headers (copied from template):
-     ```
-     **Requirement Description:**
-     [TO BE FILLED]
-     
-     **Interaction Flow:**
-     [TO BE FILLED]
-     
-     **Boundary Conditions:**
-     [TO BE FILLED]
-     
-     **Exception Scenarios:**
-     [TO BE FILLED]
-     
-     **Operation Flow Diagram:**
-     [TO BE FILLED]
-     
-     **Operation Steps Detail:**
-     [TO BE FILLED]
-     ```
-4. Verify skeleton: confirm ALL features have ALL 6 sub-section headers before proceeding
-
-> ⚠️ DO NOT start filling content until the complete skeleton is verified.
-
-### Phase B: Content Filling (AFTER skeleton is complete)
-
-Fill each `[TO BE FILLED]` placeholder with actual content:
-- Requirement Description → Business requirements in business language
-- Interaction Flow → User interaction steps (numbered list)
-- Boundary Conditions → Table with Condition Type | Scenario | Handling Rule
-- Exception Scenarios → Bullet list of exception handling
-- Operation Flow Diagram → Mermaid `graph LR` diagram showing operation flow
-- Operation Steps Detail → Table with Step | Action | Expected Outcome | Exception Handling
-
----
-
-Fill each section using `search_replace`:
-
-### 3.1 Section 1: Background & Goals
-- 1.1 Background: Why this module exists within the system, what problem it solves
-- 1.2 Goals: Module-specific business objectives
-
-### 3.2 Section 2: User Stories
-- 2.1 Target Users: Users who interact with this specific module
-- 2.2 User Scenarios: Module-specific user stories in "As a / I want / So that" format
-
-### 3.3 Section 3: Functional Requirements
-- 3.1 Use Case Diagram: Module-specific use case diagram (Mermaid flowchart TB) — **Business use cases showing user interactions — NOT system APIs or technical components**
-- 3.2 Business Process Flow: Module-internal process flow — **Business process steps — NOT database operations or API calls**
-- 3.3 Feature List: Module features with P0/P1/P2 priority — **Business feature descriptions — NOT technical implementation**
-- 3.4 Feature Breakdown: **REQUIRED** — Fill with `{module_features}` data:
-  - Feature ID, Feature Name, Type (User Interaction / Backend Process), Scope, Description
-  - Feature Dependencies table
-- 3.5 Feature Details: **FOR EACH feature in module_features, fill ALL 6 sub-sections below:**
-  
-  **Complete structure (MUST repeat for every Feature 1, 2, ... N):**
-  - Requirement Description — **Business requirements in business language**
-  - Interaction Flow — **User interaction steps in business terms**
-  - Boundary Conditions table — **Business scenarios and business handling rules**
-  - Exception Scenarios — **Business exception handling in business language**
-  - Operation Flow Diagram — **Mermaid `graph LR` showing business operation steps (REQUIRED for EVERY feature)**
-  - Operation Steps Detail — **Table: Step | Action | Expected Outcome | Business Exception Handling (REQUIRED for EVERY feature)**
-  
-  > ⚠️ **CRITICAL**: ALL features MUST have the SAME 6-section structure. DO NOT skip Operation Flow Diagram or Operation Steps Detail for ANY feature. Check the PRD-TEMPLATE.md for the exact format.
-
-### 3.4 Section 4: Non-functional Requirements
-- Module-specific performance, security, compatibility requirements
-- Reference Master PRD for system-wide NFRs
-
-### 3.5 Section 5: Acceptance Criteria
-- 5.1 Must Have: Module-specific acceptance items
-- 5.2 Should Have: Module-specific nice-to-have items
-
-### 3.6 Section 6: Boundary Description
-- 6.1 In Scope: What this module covers
-- 6.2 Out of Scope: What this module explicitly does NOT cover
-
-### 3.7 Section 7: Assumptions & Dependencies
-- Dependencies on other modules (reference Master PRD dependency matrix)
-- External system dependencies
-- Prerequisites
-
-> ⚠️ **FORBIDDEN: `create_file` to rewrite the entire document. MUST use `search_replace` per section.**
-
-### ⚠️ Content Boundary Validation
-
-Before filling each section, verify:
-- Feature descriptions use BUSINESS language (✅ "Customer can view order history" ❌ "GET /api/orders returns JSON")
-- Boundary conditions describe BUSINESS scenarios (✅ "Customer name is empty" ❌ "null pointer exception")
-- Exception handling describes BUSINESS rules (✅ "Show friendly error message" ❌ "return HTTP 400")
-- Process flows show BUSINESS steps (✅ "Customer submits order" ❌ "POST request to order service")
-
-## Step 4: Verify Output
-
-1. Read the generated file to verify:
-   - File exists and is non-empty
-   - File size > 3KB (not a placeholder)
-   - Section 3.4 Feature Breakdown is populated
-   - Title contains module name
-
-2. Report result:
-
-```
-IF verification passes:
-  → Output: "✅ Sub-PRD generated: {output_path}"
-IF verification fails:
-  → Output: "❌ Sub-PRD verification failed: {reason}"
-  → Attempt to fix the specific issue
-```
-
-## Step 5: Write Module Features to Feature List
-
-> **Purpose:** Separate feature data from dispatch plan into dedicated `.prd-feature-list.json` file.
-> Each Sub-PRD Worker writes its module's features upon completion.
-
-> **CRITICAL: UTF-8 Encoding**
-> 
-> When writing ANY file (JSON, Markdown, or other text files), you MUST ensure UTF-8 encoding:
-> - Use `create_file` tool (which defaults to UTF-8) for file creation
-> - If using Node.js scripts: `fs.writeFileSync(path, content, 'utf8')`
-> - NEVER rely on system default encoding (may be GBK on Chinese Windows)
-> - This applies to ALL output files including `.prd-feature-list.json`
-
-### 5.1 Determine Feature List File Path
-
-```
-feature_list_path = dirname(output_path) + '/.prd-feature-list.json'
-```
-
-This is the same directory containing `.sub-prd-dispatch-plan.json`.
-
-### 5.2 Read or Initialize Feature List File
-
-```javascript
-IF file exists at feature_list_path:
-  feature_list = read_json(feature_list_path)
-ELSE:
-  feature_list = {
-    "created_at": "{timestamp from update-progress.js}",
-    "updated_at": "{timestamp from update-progress.js}",
-    "modules": []
-  }
-```
-
-> ⚠️ **Timestamp constraint:** Use `node scripts/update-progress.js write-checkpoint` or similar script to get accurate timestamps. DO NOT fabricate timestamps.
-
-### 5.3 Build Current Module Feature Entry
-
-Construct the module entry from input parameters:
-
-```json
-{
-  "module_id": "{module_id}",
-  "module_name": "{module_name}",
-  "module_key": "{module_key}",
-  "source_prd": "{feature_name}-sub-{module_key}.md",
-  "feature_count": {module_features.length},
-  "features": [
-    // Map each item in module_features to:
-    {
-      "feature_id": "{item.feature_id}",
-      "feature_name": "{item.feature_name}",
-      "type": "{item.type}",
-      "priority": "{item.priority}",
-      "sub_features": "{item.sub_features}",
-      "description": "{item.description}"
-    }
-  ]
-}
-```
-
-### 5.4 Merge into Feature List
-
-```javascript
-existing_index = find_index(feature_list.modules, m => m.module_key === module_key)
-
-IF existing_index >= 0:
-  // Retry scenario: replace existing entry
-  feature_list.modules[existing_index] = module_entry
-ELSE:
-  // New module: append
-  feature_list.modules.push(module_entry)
-
-// Update timestamp
-feature_list.updated_at = "{current timestamp}"
-```
-
-### 5.5 Write Feature List File
-
-Write the updated `feature_list` to `{feature_list_path}` using `create_file`.
-
-### 5.6 Report Result
-
-```
-IF write succeeds:
-  → Output: "✅ Feature list updated: {feature_count} features for module {module_id}"
-IF write fails:
-  → Output: "⚠️ Feature list write failed: {error}"
-  → Continue without blocking Sub-PRD completion
-```
-
----
-
-> **Note:** Step 5 is a pure incremental operation. Failure here should NOT affect the Sub-PRD file generation result. The primary deliverable is the Sub-PRD document itself.
+> **REQUIRED**: Before executing this workflow, read the XML workflow specification: speccrew-workspace/docs/rules/agentflow-spec.md
+> Then read and execute the XML workflow in SKILL.xml block-by-block as the authoritative execution plan.

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

@@ -1,177 +1,18 @@
 ---
 name: speccrew-product-manager-orchestration
-version: 2.0.0
 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
 ---
 
-> **⚠️ MANDATORY EXECUTION PROTOCOL — READ BEFORE EXECUTING ANY BLOCK**
->
-> **Step 1**: Load XML workflow specification: `speccrew-workspace/docs/rules/agentflow-spec.md` — this defines all block types and action-to-tool mappings
->
-> **Step 2**: Execute this SKILL.md's XML workflow **block by block in document order**. For EVERY block, you MUST follow this 3-step cycle:
->
-> ```
-> 🏷️ Block [ID] (action=[action]) — [desc]
-> 🔧 Tool: [which IDE tool to call]
-> ✅ Result: [output or status]
-> ```
+# Trigger Scenarios
 
-> ⚠️ **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)
-> - `action="run-script"` → Execute via **Terminal tool** (pass the `<field name="command">` value EXACTLY)
-> - `action="dispatch-to-worker"` → Create **Task** via **Task tool** for `speccrew-task-worker`
-> - `action="read-file"` → Read via **Read tool**
-> - `action="log"` → Output message directly
-> - `action="user-confirm"` → Present to user and wait for EXPLICIT confirmation (NON-SKIPPABLE)
->
-> **CRITICAL DISPATCH RULE:**
-> - PM Agent (Team Leader) MUST NOT execute Skills directly
-> - ALL Skill executions MUST go through `dispatch-to-worker` action
-> - Worker Agent (`speccrew-task-worker`) receives the Skill name and context, then executes the Skill
->
-> **Step 3**: Execute ALL blocks sequentially without pausing (only stop at explicit `<event action="user-confirm">` blocks)
-
-# Product Manager Orchestration (v2.0)
-
-Pure routing layer orchestration skill, responsible for:
-
-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
-
-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` | 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)
-
-There are **mandatory user confirmation gates** after Phase 3 and Phase 4a:
-
-### R-CONFIRM Rule Block
-
-```xml
-<block type="rule" id="R-CONFIRM" level="mandatory" desc="User confirmation is MANDATORY">
-  <field name="text">MANDATORY: After each phase completes, you MUST wait for EXPLICIT user confirmation.</field>
-  <field name="text">DO NOT mark checkpoint as passed by yourself. DO NOT skip user confirmation.</field>
-  <field name="text">The checkpoint write-checkpoint command MUST ONLY be executed AFTER user confirms.</field>
-</block>
-```
-
-### user-confirm Event Block
-
-```xml
-<block type="event" id="P3-CONFIRM" action="user-confirm" desc="User confirmation required">
-  <field name="prompt">📋 Phase Complete. Please review and confirm.</field>
-  <field name="skippable" value="false"/>
-</block>
-```
-
-**Key Points:**
-- `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 outputs `resume_target` to control resume routing:
-
-| resume_target | Target Block | Description |
-|---------------|--------------|-------------|
-| `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
-
-**CRITICAL**: This skill is loaded directly by Product Manager Agent — do NOT invoke via Worker Agent.
-
-```xml
-<block type="task" action="run-skill" desc="Product Manager orchestration workflow">
-  <field name="skill">speccrew-product-manager-orchestration</field>
-</block>
-```
-
-## Input Parameters
-
-| Parameter | Type | Required | Description |
-|-----------|------|----------|-------------|
-| `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` - 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
-
----
+- Product Manager Agent starts the PRD workflow for a new user requirement
+- User submits a requirement and needs PRD generation
+- Workflow resume after Phase checkpoint (resume_target routing)
 
 ## AgentFlow Definition
 
 <!-- @agentflow: SKILL.xml -->
 
----
-
-## CONTINUOUS EXECUTION RULES
-
-This skill MUST execute tasks continuously without unnecessary interruptions.
-
-### FORBIDDEN Interruptions
-
-1. DO NOT ask user "Should I continue?" after completing a subtask
-2. DO NOT suggest "Let me split this into batches" or "Let's do this in parts"
-3. DO NOT pause to list what you plan to do next — just do it
-4. DO NOT ask for confirmation before generating output files
-5. DO NOT warn about "large number of files" — proceed with generation
-6. DO NOT offer "Should I proceed with the remaining items?"
-
-### When to Pause (ONLY these cases)
-
-1. **User Confirmation Gates** — `action="user-confirm"` blocks (Phase 3, Phase 4a)
-2. Ambiguous requirements that genuinely need clarification
-3. Unrecoverable errors that prevent further progress
-4. Security-sensitive operations (e.g., deleting existing files)
-
-### Orchestrator Principle (v2.0)
-
-This agent is a **pure router/dispatcher**. Key constraints:
-
-| Phase | Skill | ORCHESTRATOR Rule |
-|-------|-------|-------------------|
-| Phase 0 | `speccrew-pm-phase0-init` | Route to correct Phase based on resume_target |
-| Phase 1-6 | All Phase Skills | DO NOT execute logic yourself — Dispatch Worker |
-
-**UNIVERSAL DISPATCH RULE:**
-- PM Agent NEVER invokes Skills directly via `action="run-skill"`
-- ALL Skill invocations use `action="dispatch-to-worker"` with `speccrew-task-worker`
-- Worker Agent receives the Skill name in context and executes it
-
-**UNIVERSAL ABORT RULE:**
-- IF ANY skill fails → STOP and report to user
-- DO NOT generate content as fallback
-- DO NOT proceed to next phase
+> **REQUIRED**: Before executing this workflow, read the XML workflow specification: speccrew-workspace/docs/rules/agentflow-spec.md
+> Then read and execute the XML workflow in SKILL.xml block-by-block as the authoritative execution plan.