speccrew 0.3.6 → 0.3.8

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

@@ -1,6 +1,6 @@
 ---
 name: speccrew-product-manager
-description: SpecCrew Product Manager. Based on user requirements, reads business knowledge and domain specifications, writes structured PRD documents, and waits for manual confirmation before transitioning to speccrew-planner. Trigger scenarios: user describes new feature requirements, feature changes, or bug fix requests.
+description: SpecCrew Product Manager. Analyzes user requirements, performs complexity assessment to route between simple (single PRD) and complex (Master-Sub PRD) workflows, reads business knowledge and domain specifications, writes structured PRD documents, and waits for manual confirmation before transitioning to speccrew-planner. Handles both lightweight requirements (1-2 modules, ≤5 features) and complex multi-module requirements (3+ modules, 6+ features). Trigger scenarios: user describes new feature requirements, feature changes, or bug fix requests.
 tools: Read, Write, Glob, Grep
 ---
 
@@ -69,20 +69,35 @@ Before starting work, check the workflow progress state:
      }
      ```
 
-## Phase 0.2: Check Resume State
+## Phase 0.2: Check Resume State (Checkpoint Recovery)
 
-If `01_prd.status` is `confirmed` or `completed`, check for checkpoint file:
+If `01_prd.status` is `in_progress` or resuming from an interrupted session:
 
-1. **Read checkpoint file**: `speccrew-workspace/iterations/{iteration}/01.product-requirement/.checkpoints.json`
-2. **If `prd_review.passed == true`**:
-   - PRD has been completed and confirmed previously
-   - Ask user to choose:
-     - **(a) View existing PRD and continue to next stage**: Show PRD content, prepare to transition to `02_feature_design`
-     - **(b) Regenerate PRD (overwrite)**: Reset `01_prd.status` to `in_progress`, proceed with normal workflow
-3. **If checkpoint does not exist or `passed == false`**:
-   - Proceed with normal PRD generation workflow
+1. **Read checkpoints** (if file exists):
+   ```bash
+   node speccrew-workspace/scripts/update-progress.js read --file speccrew-workspace/iterations/{iteration}/01.product-requirement/.checkpoints.json --checkpoints
+   ```
+   - If the file does not exist → Start from Phase 1 (no previous progress)
+
+2. **Evaluate Checkpoint Status**:
+
+| Checkpoint | If Passed | Resume Point |
+|------------|-----------|--------------|
+| `requirement_clarification.passed == true` | Skip clarification | Start from Step 4 (Template Selection) |
+| `sub_prd_dispatch.passed == true` | Skip Sub-PRD generation | Start from Phase 4 (Verification) |
+| `prd_review.passed == true` | All complete | Ask user: "PRD stage already confirmed. Redo?" |
+
+3. **Check Sub-PRD Dispatch Resume** (if applicable):
+   ```bash
+   node speccrew-workspace/scripts/update-progress.js read --file speccrew-workspace/iterations/{iteration}/01.product-requirement/DISPATCH-PROGRESS.json --summary
+   ```
+   - Skip tasks with `status == "completed"`
+   - Re-execute tasks with `status == "failed"`
+   - Execute tasks with `status == "pending"`
 
-## Phase 0.3: Backward Compatibility
+4. **Display Resume Summary** and ask user to confirm.
+
+### 0.3 Backward Compatibility
 
 If WORKFLOW-PROGRESS.json does not exist (legacy iterations or new workspace):
 - Execute the original workflow without progress tracking
@@ -98,11 +113,62 @@ Detect current IDE environment and determine skill loading strategy:
 
 1. **Detect IDE**: Check environment variables or context to identify current IDE (Claude Code, Cursor, Qoder, etc.)
 2. **Set skill_path**: Based on IDE detection result, set the appropriate skill search path
-3. **Proceed to Requirement Assessment**
+3. **Proceed to Complexity Assessment**
 
 ---
 
-## Phase 1: Pre-Skill Requirement Assessment
+## Phase 1: Complexity Assessment & Skill Routing
+
+Before starting requirement analysis, assess the requirement complexity to determine the appropriate skill path.
+
+### 1.1 Complexity Indicators
+
+Evaluate the user's requirement against these indicators:
+
+| Indicator | Simple | Complex |
+|-----------|--------|---------|
+| Modules affected | 1-2 modules | 3+ modules |
+| Estimated features | 1-5 features | 6+ features |
+| System scope | Change to existing system | New system or major subsystem |
+| PRD structure needed | Single PRD | Master + Sub-PRDs |
+| Cross-module dependencies | None or minimal | Significant |
+
+### 1.2 Complexity Decision
+
+Based on the indicators above:
+
+**→ Simple Requirement** (ANY of these):
+- Adding/modifying fields on an existing page
+- Minor feature enhancement within 1-2 modules
+- Business logic adjustment
+- Bug fix documentation
+- Scope: ≤ 5 features, ≤ 2 modules
+
+**→ Complex Requirement** (ANY of these):
+- New system or major subsystem development
+- Involves 3+ modules
+- Requires 6+ features
+- Needs cross-module dependency management
+- User explicitly requests comprehensive analysis
+
+### 1.3 Skill Routing
+
+| Complexity | Skill | Key Differences |
+|-----------|-------|-----------------|
+| Simple | `speccrew-pm-requirement-simple/SKILL.md` | Single PRD, no Master-Sub, no worker dispatch, streamlined 6-step flow |
+| Complex | `speccrew-pm-requirement-analysis/SKILL.md` | Master-Sub PRD, worker dispatch for Sub-PRDs, full ISA-95 methodology, 13-step flow |
+
+**Routing behavior:**
+1. Assess complexity based on user's initial requirement description
+2. If uncertain, ask user ONE question: "This requirement seems to involve [X modules / Y features]. Should I use the streamlined process (single PRD) or the comprehensive process (Master + Sub-PRDs)?"
+3. Invoke the selected skill
+4. If during simple skill execution, complexity escalates → the simple skill will auto-redirect to the complex skill
+
+> ⚠️ **Default to Simple when in doubt**. It's easier to escalate from simple to complex than to simplify an over-engineered analysis.
+
+---
+
+## Phase 2: Pre-Skill Requirement Assessment
 
 Before invoking the requirement analysis skill, assess the user input for completeness.
 
@@ -166,25 +232,32 @@ complexity_notes: <if complex, note affected modules>
 
 ---
 
-## Phase 2: Invoke Skill
+## Phase 3: Invoke Skill
+
+Based on the complexity assessment in Phase 1, invoke the appropriate skill:
 
-Invoke Skill: Find `speccrew-pm-requirement-analysis/SKILL.md` in the skills directory
+**For Simple Requirements:**
+- Find `speccrew-pm-requirement-simple/SKILL.md` in the skills directory
+
+**For Complex Requirements:**
+- Find `speccrew-pm-requirement-analysis/SKILL.md` in the skills directory
 
 Pass the following context to the Skill:
 - User's original requirement input
 - Pre-skill assessment results (clarification_status, expected_complexity, etc.)
 - Clarification Q&A records (if any)
+- Complexity routing decision (simple|complex)
 
 ---
 
-## Phase 3: Sub-PRD Worker Dispatch (Master-Sub Structure Only)
+## Phase 4: Sub-PRD Worker Dispatch (Master-Sub Structure Only)
 
 **IF the Skill output includes a Sub-PRD Dispatch Plan (from Step 12c), execute this phase.**
-**IF Single PRD structure, skip to Phase 4.**
+**IF Single PRD structure, skip to Phase 5.**
 
 After the Skill generates the Master PRD and outputs the dispatch plan, the PM Agent takes over to generate Sub-PRDs in parallel using worker agents.
 
-### 3.1 Read Dispatch Plan
+### 4.1 Read Dispatch Plan
 
 From the Skill's Step 12c output, collect:
 - `feature_name`: System-level feature name
@@ -196,7 +269,31 @@ From the Skill's Step 12c output, collect:
   - `module_user_stories`, `module_requirements`, `module_features`
   - `module_dependencies`
 
-### 3.2 Dispatch Workers
+### 4.2 Initialize Dispatch Progress Tracking
+
+Before dispatching workers, initialize `DISPATCH-PROGRESS.json`:
+
+```bash
+node speccrew-workspace/scripts/update-progress.js init-dispatch \
+  --file speccrew-workspace/iterations/{iteration}/01.product-requirement/DISPATCH-PROGRESS.json \
+  --tasks "module-1,module-2,module-3,..."
+```
+
+After each worker completes, update its status:
+```bash
+node speccrew-workspace/scripts/update-progress.js update-task \
+  --file speccrew-workspace/iterations/{iteration}/01.product-requirement/DISPATCH-PROGRESS.json \
+  --task {module_key} --status completed
+```
+
+If a worker fails:
+```bash
+node speccrew-workspace/scripts/update-progress.js update-task \
+  --file speccrew-workspace/iterations/{iteration}/01.product-requirement/DISPATCH-PROGRESS.json \
+  --task {module_key} --status failed --error "{error_message}"
+```
+
+### 4.3 Dispatch Workers
 
 Invoke `speccrew-task-worker` agents in parallel, one per module:
 
@@ -227,7 +324,7 @@ Worker N: Module "{module-N}"   → crm-system-sub-{module-N}.md
 
 **All workers execute simultaneously.** Wait for all workers to complete before proceeding.
 
-### 3.3 Collect Results
+### 4.4 Collect Results
 
 After all workers complete:
 
@@ -247,21 +344,37 @@ After all workers complete:
    - Re-dispatch failed modules (retry once)
    - If retry fails, report to user for manual intervention
 
+After all workers complete, report dispatch summary:
+```
+📊 Sub-PRD Generation Complete:
+├── Total: 11 modules
+├── ✅ Completed: 10
+├── ❌ Failed: 1 (member — error description)
+└── Retry failed modules? (yes/skip)
+```
+
+Update `.checkpoints.json` → `sub_prd_dispatch.passed = true` (only if all succeeded or user skips failures).
+
 ---
 
-## Phase 4: Verification & Confirmation
+## Phase 5: Verification & Confirmation
 
-### 4.1 Execute Verification Checklist
+### 5.1 Execute Verification Checklist
 
 Return to the Skill's Step 12d for verification:
-- Verify Master PRD exists and size > 2KB
-- Verify all Sub-PRD files exist and each size > 3KB
-- Verify Master PRD Sub-PRD Index matches actual files
-- Verify each Sub-PRD contains Feature Breakdown (Section 3.4)
+- Verify Master PRD exists and size > 2KB (for complex requirements)
+- Verify all Sub-PRD files exist and each size > 3KB (for complex requirements)
+- Verify Master PRD Sub-PRD Index matches actual files (for complex requirements)
+- Verify each Sub-PRD contains Feature Breakdown (Section 3.4) (for complex requirements)
+- Verify Single PRD exists and size > 2KB (for simple requirements)
 
-### 4.2 Present Documents for User Review
+After verification passes, update `.checkpoints.json`:
+- Set `verification_checklist.passed = true`
+- Record each check result in the checklist
 
-Execute Skill's Step 12e to present document summary and ask user to review.
+### 5.2 Present Documents for User Review
+
+Execute Skill's Step 12e (for complex) or the simple skill's final step to present document summary and ask user to review.
 
 ⚠️ **HARD STOP — WAIT FOR USER CONFIRMATION**
 - DO NOT update any status files yet
@@ -270,10 +383,14 @@ Execute Skill's Step 12e to present document summary and ask user to review.
 - Wait for user to explicitly confirm (e.g., "确认", "OK", "没问题")
 - IF user requests changes → make the changes, then re-present for review
 
-### 4.3 Finalize PRD Stage (ONLY after user explicitly confirms)
+### 5.3 Finalize PRD Stage (ONLY after user explicitly confirms)
 
 After user confirms the PRD documents are correct:
 
+After user confirms (HARD STOP passed), update `.checkpoints.json`:
+- Set `prd_review.passed = true`
+- Set `prd_review.confirmed_at` via: `node -e "console.log(new Date().toISOString())"`
+
 1. Execute Skill's Step 13 to finalize:
    - Use `update-progress.js` script to update WORKFLOW-PROGRESS.json with **real timestamps** (NOT LLM-generated)
    - Write checkpoint file with **real timestamps** (use `node -e "console.log(new Date().toISOString())"` if script unavailable)
@@ -307,7 +424,8 @@ After user confirms the PRD documents are correct:
 - Explicitly prompt user for review and confirmation after PRD completion
 - Execute Pre-Skill Requirement Assessment before invoking the Skill
 - Pass clarification context and complexity assessment to the Skill
-- For complex requirements (2+ modules), dispatch Sub-PRD generation to parallel workers using `speccrew-pm-sub-prd-generate/SKILL.md`
+- Perform Complexity Assessment & Skill Routing at Phase 1 to determine simple vs complex workflow
+- For complex requirements (3+ modules), dispatch Sub-PRD generation to parallel workers using `speccrew-pm-sub-prd-generate/SKILL.md`
 
 **Must not do:**
 - Do not make technical solution decisions (that's speccrew-planner's responsibility)

package/.speccrew/skills/speccrew-fd-feature-design/SKILL.md

@@ -4,6 +4,18 @@ description: Feature Design SOP. Guide Feature Designer Agent to transform PRD r
 tools: Read, Write, Glob, Grep
 ---
 
+# Methodology Foundation
+
+This skill applies the ISA-95 six-stage methodology (Stages 4-6) as an internal thinking framework:
+
+| ISA-95 Stage | Integrated Into | Purpose |
+|---|---|---|
+| Stage 4: Information Flows | Feature Spec Section 3 (Interaction Flow) | Map cross-module data flows, identify API endpoints |
+| Stage 5: Categories of Information | Feature Spec Section 4 (Data Field Definition) | Classify data entities, build data dictionary |
+| Stage 6: Information Descriptions | Feature Spec Section 5 (Business Rules) + API Contract | Define validation rules, output standards, traceability |
+
+> ⚠️ **No separate modeling documents.** The methodology guides thinking quality, not document quantity.
+
 # Trigger Scenarios
 
 - PRD has been confirmed, user requests to start feature design
@@ -336,6 +348,14 @@ Document user actions and system responses:
 User Action → Frontend Response → Backend API Call
 ```
 
+> **ISA-95 Stage 4 Thinking — Information Flows of Interest**
+> When designing interaction flows:
+> - **Cross-module Information Flow**: Map all data flows between this feature and other modules/systems. Identify data source, destination, format, and frequency.
+> - **Sequence Diagram Coverage**: The sequence diagram must cover the complete interaction chain — user action → frontend → backend → database → external systems.
+> - **Interface Identification**: Every data exchange point becomes a potential API endpoint. List all interface interactions with direction, format, and core fields.
+> - **Exception Flows**: Identify and document alternative/exception paths, not just the happy path.
+> These elements flow into Feature Spec Section 3 (Interaction Flow) — no separate DFD document needed.
+
 **Example:**
 ```
 1. User clicks "New User" button
@@ -424,6 +444,14 @@ For each new entity:
 |-------|------|-------------|-------------|
 | {field name} | {data type} | {required/unique/etc} | {purpose} |
 
+> **ISA-95 Stage 5 Thinking — Categories of Information**
+> When defining data fields:
+> - **Information Classification**: Categorize data entities (master data, transactional data, reference data, computed data). This determines storage strategy and update frequency.
+> - **Data Dictionary Rigor**: Every field must have: name, type, constraints, semantic description, and data source.
+> - **Semantic Consistency**: Field names and definitions must align with the domain glossary established in the PRD clarification phase. No "同物异名" (same thing, different names).
+> - **Entity Relationships**: Identify core entity relationships (1:1, 1:N, N:N) that will drive database design downstream.
+> These elements flow into Feature Spec Section 4 (Data Field Definition) — no separate data dictionary document needed.
+
 ### 7.2 Modifications to Existing Data Structures
 
 | Entity | Change Type | Details | Impact |
@@ -451,6 +479,14 @@ EntityA --N:1--> EntityC
 
 ## Step 8: Business Rules and Constraints
 
+> **ISA-95 Stage 6 Thinking — Information Descriptions**
+> When defining business rules and constraints:
+> - **Validation Rules**: Define field-level validation (format, range, required), cross-field validation, and business logic validation.
+> - **Output Format Standards**: Specify information output format (JSON for API, specific encoding), ensuring consistency with downstream API Contract.
+> - **Permission Rules**: Define data access permissions that will map to API authorization logic.
+> - **Traceability**: Every business rule should trace back to a PRD requirement. Every data field should trace to a user story.
+> These elements flow into Feature Spec Section 5 (Business Rules) and prepare the foundation for API Contract generation.
+
 ### 8.1 Permission Rules
 
 | Function | Required Permission | Scope |

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

@@ -1,6 +1,6 @@
 ---
 name: speccrew-pm-requirement-analysis
-description: PRD Writing SOP with ISA-95 business modeling. Guide PM Agent through requirements clarification, business domain analysis, and PRD document generation. For complex requirements, applies ISA-95 six-stage methodology for structured domain modeling before PRD writing. Use when PM needs to write PRD, organize requirements, model business domains, or create structured requirement documents.
+description: PRD Writing SOP with ISA-95 methodology integration. Guide PM Agent through requirements clarification, business domain analysis, and PRD document generation. Applies ISA-95 Stages 1-3 as internal thinking framework for clarification, functional decomposition, and prioritization — no separate modeling documents. Use when PM needs to write PRD, organize requirements, or create structured requirement documents.
 tools: Read, Write, Glob, Grep
 ---
 
@@ -8,8 +8,19 @@ tools: Read, Write, Glob, Grep
 
 - PM Agent receives user requirement description
 - User requests "Write a PRD" or "Help organize requirements" or "New feature requirements"
-- User requests "Create business model" or "Model business requirements"
-- User needs structured requirement document with UML diagrams
+- User needs structured requirement document with business-level diagrams (use case diagrams, business process flows, activity diagrams)
+
+## Methodology Foundation
+
+This skill applies the ISA-95 six-stage methodology (Stages 1-3) as an internal thinking framework:
+
+| ISA-95 Stage | Integrated Into | Purpose |
+|---|---|---|
+| Stage 1: Domain Description | Clarification process | Define domain boundary, participants, glossary |
+| Stage 2: Functions in Domain | PRD Section 3 (Functional Requirements) | WBS decomposition, capability mapping |
+| Stage 3: Functions of Interest | PRD Section 3.4 (Feature Breakdown) | MoSCoW prioritization, MVP scoping |
+
+> ⚠️ **No separate modeling documents.** The methodology guides thinking quality, not document quantity.
 
 # Workflow
 
@@ -23,6 +34,18 @@ tools: Read, Write, Glob, Grep
 
 3. **MANDATORY: Template-first workflow** — Copy template MUST execute before filling sections. Skipping copy and writing content directly is FORBIDDEN.
 
+## 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
+> - Code snippets, pseudocode
+> - Technical terminology in Domain Glossary (e.g., UUID, JSON, REST)
+> - Technical metrics (e.g., "code files", "CPU usage")
+>
+> These belong to Feature Designer (interaction design, data modeling) or System Designer (technical architecture).
+
 ## Step 1: Requirements Clarification (MANDATORY)
 
 ⚠️ **MANDATORY: This step CANNOT be skipped.**
@@ -37,6 +60,13 @@ IF user provided incomplete input:
 
 Use progressive questioning to clarify requirements. Do NOT ask all questions at once.
 
+> **ISA-95 Stage 1 Thinking — Domain Description**
+> During clarification, apply domain description methodology:
+> - **Domain Boundary**: Explicitly define what is in-scope and out-of-scope. Record in clarification summary.
+> - **External Participants**: Identify all user roles, external systems, and integration points.
+> - **Domain Glossary**: Unify key business terms to eliminate ambiguity across stakeholders.
+> These elements should naturally flow into the clarification summary, NOT as a separate document.
+
 ### Round 1: Core Understanding
 
 Ask these first (2-3 questions max per round):
@@ -125,6 +155,49 @@ IF both conditions met → Proceed to Step 2
 IF any condition fails → STOP and complete the missing items
 ```
 
+After clarification is confirmed sufficient, write initial `.checkpoints.json`:
+
+```bash
+# Create or update checkpoint file
+```
+
+Write the following structure to `speccrew-workspace/iterations/{iteration}/01.product-requirement/.checkpoints.json`:
+
+```json
+{
+  "stage": "01_prd",
+  "checkpoints": {
+    "requirement_clarification": {
+      "passed": true,
+      "confirmed_at": "{REAL_TIMESTAMP via node -e}",
+      "description": "Requirement clarification completed",
+      "clarification_file": ".clarification-summary.md",
+      "sufficiency_checks": {
+        "business_problem": true,
+        "target_users": true,
+        "scope_boundaries": true,
+        "existing_system": true
+      }
+    },
+    "sub_prd_dispatch": {
+      "passed": false,
+      "confirmed_at": null,
+      "description": "Sub-PRD generation via worker dispatch"
+    },
+    "verification_checklist": {
+      "passed": false,
+      "confirmed_at": null,
+      "description": "PRD structure and content verification"
+    },
+    "prd_review": {
+      "passed": false,
+      "confirmed_at": null,
+      "description": "User review and confirmation of all PRD documents"
+    }
+  }
+}
+```
+
 **Principles:**
 - Ask 2-3 questions per round, not 5+ at once
 - Adapt questions based on previous answers (skip what's already clear)
@@ -198,94 +271,68 @@ Evaluate requirement complexity to determine the appropriate workflow path:
 | Modules involved | 1 module | 2+ modules or new domain |
 | Domain clarity | Well-understood domain | New/unclear domain |
 | Cross-module deps | None or minimal | Significant |
-| Template | PRD-TEMPLATE.md only | BIZS-MODELING-TEMPLATE.md + PRD-TEMPLATE.md |
+| Template | PRD-TEMPLATE.md only | PRD-TEMPLATE.md (with deeper analysis) |
 
 **Workflow Path:**
 - **Simple path**: Skip to Step 7 (Read PRD Template)
 - **Complex path**: Proceed to Step 5 (ISA-95 Business Modeling) → Step 6 (Module Decomposition)
 
-## Step 5: ISA-95 Business Modeling (Complex Requirements Only)
+## Step 5: ISA-95 Business Modeling Thinking (Complex Requirements Only)
 
-Read the modeling template:
-```
-speccrew-pm-requirement-analysis/templates/BIZS-MODELING-TEMPLATE.md
-```
+> ⚠️ **This step is a THINKING PROCESS, not a document generation step.**
+> Apply ISA-95 methodology internally to deepen your analysis. Results flow into the PRD.
 
-Execute ISA-95 six stages **in condensed form**:
+Apply ISA-95 six stages as internal thinking framework:
 
-### 5.1 Stage 1 - Domain Description
+### 5.1 Stage 1 - Domain Description (Thinking)
 - Define domain boundary (in-scope, out-of-scope)
 - Identify external participants (users, systems, agents)
 - Create domain glossary
-- Draw system context diagram (graph TD)
+- Visualize system context (mental model or rough sketch)
 
 **Checkpoint A: Briefly confirm domain boundary with user before proceeding.**
 Ask: "Here is the domain boundary and key participants. Does this match your understanding?"
 
-### 5.2 Stage 2 - Functions in Domain
-- Create WBS decomposition (graph TD)
+### 5.2 Stage 2 - Functions in Domain (Thinking)
+- Create WBS decomposition (mental or rough sketch)
 - Map functions to business capabilities
-- Select UML visualization as needed (Use Case / Activity / State Machine)
+- Identify module boundaries
 
-### 5.3 Stage 3 - Functions of Interest
+### 5.3 Stage 3 - Functions of Interest (Thinking)
 - Apply MoSCoW prioritization
-- Create focused use case diagram (graph TB)
+- Identify core vs non-core functions
 - Document non-core functions and their iteration plan
 
 **Checkpoint B: Confirm MVP scope with user before proceeding.**
 Ask: "Here are the core functions (Must have) and deferred functions. Is the MVP scope correct?"
 
-### 5.4 Stage 4 - Information Flows
+### 5.4 Stage 4 - Information Flows (Thinking)
 - Document core information flows
-- Create sequence diagram (sequenceDiagram)
-- Create Data Flow Diagram (graph TD)
-- List interface interactions
+- Identify key interfaces
+- Understand data movement patterns
 
-### 5.5 Stage 5 - Categories of Information
+### 5.5 Stage 5 - Categories of Information (Thinking)
 - Define information categories
-- Create data dictionary
-- Draw conceptual class diagram (classDiagram)
+- Identify core entities
+- Understand data relationships
+
+### 5.6 Stage 6 - Information Descriptions (Thinking)
+- Consider technical implications
+- Identify component boundaries
+- Note implementation considerations
 
-### 5.6 Stage 6 - Information Descriptions
-- Create design class diagram with technical details
-- Create component diagram (graph TB)
-- Document implementation standards
+**Checkpoint C: Present analysis summary to user for final confirmation.**
 
-**Checkpoint C: Present complete modeling results (Stages 4-6) to user for final confirmation.**
+> All ISA-95 thinking results will be reflected in the PRD document, NOT as a separate modeling file.
 
 **Key rules for this step:**
 - Use 3 checkpoints (A/B/C) for progressive confirmation, not all-at-once
-- All Mermaid diagrams MUST follow mermaid-rule.md:
-  - No HTML tags (`<br/>`)
-  - No nested subgraphs
-  - No `direction` keyword
-  - No `style` definitions
-  - No special characters in node text
-- **Write modeling document using template-fill workflow:**
-
-  **5.7a Copy Template to Document Path:**
-  1. Read `templates/BIZS-MODELING-TEMPLATE.md`
-  2. Replace top-level placeholders (feature name, domain name, etc.)
-  3. Create document using `create_file` at: `iterations/{number}-{type}-{name}/01.product-requirement/{feature-name}-bizs-modeling.md`
-
-  **5.7b Fill Each Section Using search_replace:**
-  Fill each modeling stage section with results from Stages 1-6 above, using `search_replace` per section.
-  > ⚠️ FORBIDDEN: `create_file` to rewrite entire document. MUST use `search_replace` per section.
-
-**ISA-95 Quick Reference:**
-
-| Stage | Focus | Key Output | UML Type |
-|-------|-------|------------|----------|
-| 1. Domain Description | Boundary, terminology | System context diagram | graph TD |
-| 2. Functions in Domain | All functions | WBS, use case diagram | graph TD, graph TB |
-| 3. Functions of Interest | Core functions (MVP) | MoSCoW table | graph TB |
-| 4. Information Flows | Interactions, interfaces | Sequence diagram, DFD | sequenceDiagram, graph TD |
-| 5. Categories of Information | Entities, data dictionary | Conceptual class diagram | classDiagram |
-| 6. Information Descriptions | Design details | Design class diagram | classDiagram, graph TB |
+- This is an analysis phase — focus on understanding, not documentation
+- Results integrate into PRD Sections 3-7 during Step 9
 
 ## Step 6: Module Decomposition & Ordering (Complex Requirements Only)
 
-Map WBS Level-1 nodes from Stage 2 into independent modules. For each module:
+Based on ISA-95 analysis from Step 5, map identified modules into independent units. For each module:
 
 ### 6.1 Define Module List
 
@@ -295,7 +342,7 @@ Map WBS Level-1 nodes from Stage 2 into independent modules. For each module:
 
 ### 6.2 Cross-Module Dependency Matrix
 
-Extract dependencies from Stage 4 information flows and graph query results:
+Based on information flow analysis from Step 5, identify dependencies:
 
 | Module | Depends On | Dependency Type | Shared Entities |
 |--------|-----------|-----------------|-----------------|
@@ -381,6 +428,14 @@ Fill in according to the template structure, requirements:
 - **Background & Goals**: Explain why we're doing this and what success looks like
 - **User Stories**: `As a [user role], I want [to do something], so that [I can achieve some goal]`
 - **Functional Requirements**: Group by priority (P0 Core / P1 Important / P2 Optional)
+
+> **ISA-95 Stage 2 Thinking — Functions in Domain**
+> When decomposing functional requirements:
+> - **WBS Decomposition**: Break down the system into functional modules using Work Breakdown Structure logic. Each module should map to a clear business capability.
+> - **Function-Capability Mapping**: Every function must answer "what business capability does this deliver?"
+> - **Module Boundaries**: Ensure modules have clear boundaries with minimal coupling.
+> This thinking drives PRD Section 3 content quality — no separate WBS document needed.
+
 - **Feature Breakdown**: Extract business operation units for downstream Feature Design (see Step 9.1)
 - **Non-functional Requirements**: Performance, security, compatibility, etc.
 - **Acceptance Criteria**: Quantifiable, verifiable definition of done
@@ -391,15 +446,22 @@ Fill in according to the template structure, requirements:
 
 For both simple and complex requirements, extract Feature Breakdown to guide downstream Feature Design:
 
+> **ISA-95 Stage 3 Thinking — Functions of Interest**
+> When creating the Feature Breakdown table:
+> - **MoSCoW Prioritization**: Classify each feature as Must-have (P0), Should-have (P1), Could-have (P2), or Won't-have (deferred).
+> - **MVP Focus**: The Feature Breakdown table IS the MVP definition. Features marked P0 form the core scope.
+> - **Non-core Exclusion**: Explicitly note deferred features in Section 6 (Boundary & Constraints) with planned iteration.
+> The Feature Breakdown table in Section 3.4 serves as the core function selection — no separate priority matrix needed.
+
 **Analysis Steps:**
 1. **Analyze user stories and functional requirements** for this module/feature
 2. **Identify business operation units** - each unit should represent:
    - A complete business operation (e.g., "Customer List Management" includes search, filter, pagination, tag management)
    - Can span 1-2 pages but remains business-cohesive
-   - Estimated implementation: no more than 15 code files (frontend + backend combined)
+   - Estimated implementation: can be completed by 1-2 developers in 1 sprint
 3. **Classify Feature Type:**
-   - `Page+API`: Frontend page with corresponding backend APIs (for full-stack architecture)
-   - `API-only`: Group of related APIs (for backend-only features)
+   - `User Interaction`: Features involving user interface and business logic
+   - `Backend Process`: Background processing or business logic without direct user interaction
 4. **Assign Feature IDs**: Use format `F-{MODULE}-{NN}` (e.g., F-CRM-01, F-CRM-02)
 5. **Document dependencies**: Identify data or workflow dependencies between features
 
@@ -409,7 +471,7 @@ For both simple and complex requirements, extract Feature Breakdown to guide dow
 | Single CRUD operation group | Complete module with 5+ CRUDs |
 | One list page with filters | Entire reporting subsystem |
 | One form with validation | Multi-step wizard with 10+ steps |
-| Single API endpoint group | All APIs for a domain |
+| Single business process | All processes for a domain |
 
 **Output:** Complete the Feature Breakdown table in Section 3.4 of the PRD template.
 
@@ -429,7 +491,7 @@ When the requirement involves modifying existing system functions, clearly mark
 - User stories (prefix the story)
 - Functional requirements (prefix each requirement)
 - UI mockups descriptions
-- API specifications
+- System capability changes
 
 **Example:**
 ```markdown
@@ -616,6 +678,29 @@ After outputting the dispatch plan:
 
 IF any check fails → Report error and fix before proceeding.
 
+After all Sub-PRDs are verified, update `.checkpoints.json`:
+- Set `sub_prd_dispatch.passed = true`
+- Set `sub_prd_dispatch.confirmed_at` via real timestamp
+- Add sub_prd summary:
+
+```json
+"sub_prd_dispatch": {
+  "passed": true,
+  "confirmed_at": "{REAL_TIMESTAMP}",
+  "total_modules": 11,
+  "sub_prds": [
+    {
+      "module_key": "member",
+      "module_name": "Member Management",
+      "file_path": "crm-system-sub-member.md",
+      "status": "completed",
+      "has_feature_breakdown": true,
+      "feature_count": 5
+    }
+  ]
+}
+```
+
 ---
 
 ### Step 12e: Present Documents for User Review
@@ -700,10 +785,50 @@ Content (use the REAL timestamp from the command output):
 {
   "stage": "01_prd",
   "checkpoints": {
+    "requirement_clarification": {
+      "passed": true,
+      "confirmed_at": "{REAL_TIMESTAMP_FROM_COMMAND}",
+      "description": "Requirement clarification completed",
+      "clarification_file": ".clarification-summary.md",
+      "sufficiency_checks": {
+        "business_problem": true,
+        "target_users": true,
+        "scope_boundaries": true,
+        "existing_system": true
+      }
+    },
+    "sub_prd_dispatch": {
+      "passed": true,
+      "confirmed_at": "{REAL_TIMESTAMP_FROM_COMMAND}",
+      "description": "Sub-PRD generation via worker dispatch",
+      "total_modules": 11,
+      "sub_prds": [
+        {
+          "module_key": "member",
+          "module_name": "Member Management",
+          "file_path": "crm-system-sub-member.md",
+          "status": "completed",
+          "has_feature_breakdown": true,
+          "feature_count": 5
+        }
+      ]
+    },
+    "verification_checklist": {
+      "passed": true,
+      "confirmed_at": "{REAL_TIMESTAMP_FROM_COMMAND}",
+      "description": "PRD structure and content verification",
+      "checks": {
+        "master_prd_exists": true,
+        "master_prd_size": true,
+        "sub_prds_exist": true,
+        "sub_prd_index_match": true,
+        "feature_breakdown_present": true
+      }
+    },
     "prd_review": {
       "passed": true,
       "confirmed_at": "{REAL_TIMESTAMP_FROM_COMMAND}",
-      "description": "PRD review and confirmation"
+      "description": "User review and confirmation of all PRD documents"
     }
   }
 }
@@ -764,8 +889,8 @@ When you are ready to proceed with Feature Design, please start a new conversati
 - [ ] PRD structure (single vs master-sub) determined appropriately
 - [ ] **[Master-Sub]** Master PRD includes architecture overview, module list, dependency matrix, implementation phases
 - [ ] **[Master-Sub]** Each Sub-PRD covers exactly one module with interface contracts
-- [ ] **Feature Breakdown** extracted with appropriate granularity (each feature ≤ 15 code files)
-- [ ] **Feature Breakdown** includes Feature IDs, Types (Page+API / API-only), and dependencies
+- [ ] **Feature Breakdown** extracted with appropriate granularity (each feature completable in 1 sprint)
+- [ ] **Feature Breakdown** includes Feature IDs, Types (User Interaction / Backend Process), and dependencies
 - [ ] PRD completely filled according to template structure
 - [ ] User story granularity aligns with "single iteration completable" principle
 - [ ] Acceptance criteria are quantifiable and verifiable

package/.speccrew/skills/speccrew-pm-requirement-analysis/templates/BIZS-MODELING-TEMPLATE.md

@@ -1,3 +1,9 @@
+<!-- 
+  INTERNAL REFERENCE ONLY — This template is NOT used to generate standalone documents.
+  ISA-95 methodology is internalized into the PRD generation process.
+  All modeling insights should flow into PRD-TEMPLATE.md sections.
+  See SKILL.md "Methodology Foundation" section for the integration mapping.
+-->
 # Business Modeling - [Feature/Skill Name]
 
 ## Document Info
@@ -71,9 +77,9 @@ graph TD
 
 ### 2.2 Function-Capability Mapping Table
 
-| Function Module | Core Sub-function | Business Capability | UML Visualization |
-|-----------------|-------------------|---------------------|-------------------|
-| __________ | __________ | __________ | Use Case / Activity / State |
+| Function Module | Core Sub-function | Business Capability |
+|-----------------|-------------------|---------------------|
+| __________ | __________ | __________ |
 
 ### 2.3 UML Visualization (As Needed)
 
@@ -217,58 +223,36 @@ graph TD
 |-------------|-----------------|-----------|-------------|-------------|
 | __________ | __________ | String/Number/Enum | Non-null | __________ |
 
-### 5.3 Conceptual Class Diagram
+### 5.3 Business Entity Relationship Diagram (Optional)
+
+> Visualize core business entity relationships using natural language. Do NOT include programming constructs (visibility modifiers, method signatures, data types).
 
 ```mermaid
 classDiagram
     class Entity1 {
-        +attribute1
-        +attribute2
+        Core attribute 1
+        Core attribute 2
     }
     class Entity2 {
-        +attribute3
+        Core attribute 3
     }
-    Entity1 "1" -- "*" Entity2 : relates
+    Entity1 "1" -- "*" Entity2 : relationship description
 ```
 
 ---
 
-## 6. Information Descriptions
-
-<!-- AI-NOTE: IMPLEMENTATION-READY specifications with technical details. -->
-
-### 6.1 Design Class Diagram
-
-```mermaid
-classDiagram
-    class ClassName {
-        -privateAttribute: Type
-        +publicMethod(): ReturnType
-    }
-    class InterfaceName {
-        +interfaceMethod(): ReturnType
-    }
-    ClassName ..|> InterfaceName : implements
-```
-
-### 6.2 Component Diagram
+## 6. Data Format Requirements
 
-```mermaid
-graph TB
-    C1[Component 1] --> C2[Component 2]
-    C2 --> C3[Component 3]
-```
+<!-- AI-NOTE: Focus on user-visible data formats and business data quality. Technical implementation details are handled by Feature Designer. -->
 
-### 6.3 Information Description Standards
-
-**Output Format**: __________
-
-**Encoding**: UTF-8
-
-**Validation Rules**:
-- __________
+### 6.1 Data Format Requirements
 
-**Storage Requirements**: __________
+| Requirement | Description |
+|-------------|-------------|
+| Input Format | {User-visible input formats: forms, file upload (CSV/Excel), etc.} |
+| Output Format | {User-visible output formats: PDF reports, Excel export, etc.} |
+| Data Quality | {Business data quality rules: completeness, accuracy, timeliness} |
+| Compliance | {Data compliance requirements: privacy, retention, audit trail} |
 
 ---
 

package/.speccrew/skills/speccrew-pm-requirement-analysis/templates/PRD-TEMPLATE.md

@@ -8,6 +8,31 @@
 ### 1.2 Goals
 [Describe the business objectives to be achieved]
 
+### 1.3 Domain Boundary
+
+**In-Scope Domains:**
+- {Domain 1: brief description}
+- {Domain 2: brief description}
+
+**Out-of-Scope Domains:**
+- {Domain 1: reason for exclusion}
+
+**External Participants:**
+
+| Participant Type | Name | Description |
+|------------------|------|-------------|
+| User | {Role name} | {Role description} |
+| System | {System name} | {Integration description} |
+
+### 1.4 Domain Glossary
+
+> Unify key business terms to eliminate cross-stakeholder ambiguity.
+
+| Term | Definition | Related Concepts |
+|------|------------|------------------|
+| {Term 1} | {Precise definition} | {Related terms or modules} |
+| {Term 2} | {Precise definition} | {Related terms or modules} |
+
 ## 2. User Stories
 
 ### 2.1 Target Users
@@ -105,12 +130,14 @@ graph TB
 
 ### 3.4 Feature Breakdown
 
-> List all business operation units in this module. Each feature represents a cohesive business operation (e.g., one frontend page with its backend APIs, or one API group for backend-only). This breakdown guides downstream Feature Design to generate per-feature specs.
+> List all business operation units in this module. Each feature represents a cohesive business operation (e.g., a user-facing feature with business logic, or a backend process without direct user interaction). This breakdown guides downstream Feature Design to generate per-feature specs.
+
+> Priority follows MoSCoW method: P0 = Must have (MVP core), P1 = Should have, P2 = Could have, Deferred = Won't have this iteration.
 
-| Feature ID | Feature Name | Type | Pages/Endpoints | Description |
-|------------|-------------|------|-----------------|-------------|
-| F-{MODULE}-01 | {Feature name} | Page+API / API-only | {page count or endpoint count} | {Brief description} |
-| F-{MODULE}-02 | {Feature name} | Page+API / API-only | {page count or endpoint count} | {Brief description} |
+| Feature ID | Feature Name | Type | Priority | Scope | Description |
+|------------|-------------|------|----------|-------|-------------|
+| F-{MODULE}-01 | {Feature name} | User Interaction / Backend Process | P0 (Must) / P1 (Should) / P2 (Could) | {Brief scope description} | {Brief description} |
+| F-{MODULE}-02 | {Feature name} | User Interaction / Backend Process | P0 (Must) / P1 (Should) / P2 (Could) | {Brief scope description} | {Brief description} |
 
 #### Feature Dependencies
 
@@ -170,12 +197,12 @@ graph LR
 
 **Operation Steps Detail:**
 
-| Step | Action | System Response | User Feedback | Exception Handling |
-|------|--------|-----------------|---------------|-------------------|
-| 1 | [User action] | [System behavior] | [UI feedback] | [Error handling] |
-| 2 | [User action] | [System behavior] | [UI feedback] | [Error handling] |
-| 3 | [User action] | [System behavior] | [UI feedback] | [Error handling] |
-| 4 | [User action] | [System behavior] | [UI feedback] | [Error handling] |
+| Step | Action | Expected Outcome | Exception Handling |
+|------|--------|------------------|-------------------|
+| 1 | [User action] | [Expected result] | [Error handling] |
+| 2 | [User action] | [Expected result] | [Error handling] |
+| 3 | [User action] | [Expected result] | [Error handling] |
+| 4 | [User action] | [Expected result] | [Error handling] |
 
 ## 4. Non-functional Requirements
 

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

@@ -0,0 +1,176 @@
+---
+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.
+tools: Read, Write, Glob, Grep, Terminal
+---
+
+# Skill Overview
+
+Simple requirement analysis skill for lightweight changes. Produces a single concise PRD.
+
+## 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
+
+> **DO NOT include in PRD:** API definitions, class diagrams, ER diagrams, code snippets, technical metrics.
+> These belong to Feature Designer or System Designer.
+
+---
+
+## Workflow
+
+### Step 1: Quick Clarification
+
+Confirm the requirement in 1-3 rounds:
+
+1. **What to change**: Which page/function/module is affected?
+2. **What the change is**: Add field? Modify logic? New sub-feature?
+3. **Business reason**: Why is this change needed?
+4. **Acceptance criteria**: How to verify the change is correct?
+
+> **ISA-95 Stage 1 Thinking** — Confirm affected module boundary and impacted user roles. No formal glossary needed.
+
+If requirement is already clear, skip and proceed.
+
+**If requirement is complex** (3+ modules, 10+ features, new system), **STOP and redirect**:
+```
+⚠️ This requirement appears complex. Switching to full requirement analysis.
+Invoking skill: speccrew-pm-requirement-analysis/SKILL.md
+```
+
+### Step 2: Initialize Tracking
+
+1. **Determine iteration path**: Use existing or create `speccrew-workspace/iterations/{iteration-id}/`
+
+2. **Create checkpoint file** at `01.product-requirement/.checkpoints.json`:
+```json
+{
+  "stage": "01_prd",
+  "complexity": "simple",
+  "checkpoints": {
+    "requirement_clarification": { "passed": true, "confirmed_at": "{REAL_TIMESTAMP}", "description": "Quick clarification completed" },
+    "prd_review": { "passed": false, "confirmed_at": null, "description": "User review and confirmation" }
+  }
+}
+```
+Get real timestamp via: `node -e "console.log(new Date().toISOString())"`
+
+3. **Update WORKFLOW-PROGRESS.json** (if exists):
+```bash
+node speccrew-workspace/scripts/update-progress.js update-workflow \
+  --file speccrew-workspace/iterations/{iteration}/WORKFLOW-PROGRESS.json \
+  --stage 01_prd --status in_progress
+```
+
+### Step 3: Read PRD Template
+
+Read: `speccrew-workspace/docs/templates/PRD-TEMPLATE.md`
+
+If not found, check: `.speccrew/skills/speccrew-pm-requirement-analysis/templates/PRD-TEMPLATE.md`
+
+### Step 4: Generate Single PRD
+
+Create PRD at: `speccrew-workspace/iterations/{iteration}/01.product-requirement/{feature-name}-prd.md`
+
+> **ISA-95 Stage 2 Thinking** — List only directly affected functions. No full WBS needed.
+
+**Section filling guidance:**
+
+| PRD Section | Simple Requirement Approach |
+|---|---|
+| 1. Background & Goals | 2-3 sentences. What's changing and why. |
+| 1.2 Domain Boundary | In-scope: the specific change. Out-of-scope: everything else. |
+| 1.3/1.4 Glossary | Only if new business terms introduced. Skip if unnecessary. |
+| 2. User Stories | 1-3 user stories maximum. |
+| 3. Functional Requirements | Brief description of the change. |
+| 3.3 Feature List | Simple table, 1-5 rows. |
+| 3.4 Feature Breakdown | 1-5 features. All P0. |
+| 4. Non-Functional Requirements | Only if relevant. Skip if not applicable. |
+| 5. Acceptance Criteria | 3-5 concrete, testable criteria. |
+| 6. Boundary | Clear in/out scope. |
+| 7. Assumptions | Only if there are assumptions to document. |
+
+> **ISA-95 Stage 3 Thinking** — All identified features are Must-have (P0). No MoSCoW filtering needed.
+
+### Step 5: Present for User Review
+
+Display PRD summary:
+```
+📄 PRD Generated: {feature-name}-prd.md
+
+Summary:
+- Scope: {brief scope}
+- Features: {count} features
+- Modules affected: {module names}
+
+Please review and confirm the scope, acceptance criteria, and completeness.
+```
+
+⚠️ **HARD STOP — WAIT FOR USER CONFIRMATION**
+
+```
+DO NOT proceed until user explicitly confirms.
+IF user requests changes → update PRD, then re-present.
+ONLY after user confirms → proceed to Step 6.
+```
+
+### Step 6: Finalize PRD Stage
+
+After user confirms:
+
+1. **Update checkpoint** — set `prd_review.passed = true` with real timestamp
+
+2. **Update WORKFLOW-PROGRESS.json**:
+```bash
+node speccrew-workspace/scripts/update-progress.js update-workflow \
+  --file speccrew-workspace/iterations/{iteration}/WORKFLOW-PROGRESS.json \
+  --stage 01_prd --status confirmed \
+  --output "01.product-requirement/{feature-name}-prd.md"
+```
+
+3. **Output**: `✅ PRD confirmed. PRD stage is complete. Next: Start Feature Design in a new conversation.`
+
+4. **END** — Do not proceed further.
+
+---
+
+## Output Checklist
+
+- [ ] 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
+- [ ] .checkpoints.json created with requirement_clarification passed
+- [ ] Business language only — no technical jargon
+
+## Constraints
+
+**Must do:**
+- Keep PRD concise — 1-3 page PRDs
+- Use business language throughout
+- Verify with user before finalizing
+- Use real timestamps from `node -e "console.log(new Date().toISOString())"`
+
+**Must not do:**
+- Do not generate Master-Sub PRD structure
+- Do not dispatch worker agents
+- Do not generate API definitions, class diagrams, or technical artifacts
+- Do not skip user confirmation
+- Do not auto-transition to Feature Design stage

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

@@ -66,7 +66,7 @@ Fill each section using `search_replace`:
 - 3.2 Business Process Flow: Module-internal process flow
 - 3.3 Feature List: Module features with P0/P1/P2 priority
 - 3.4 Feature Breakdown: **REQUIRED** — Fill with `{module_features}` data:
-  - Feature ID, Feature Name, Type (Page+API / API-only), Pages/Endpoints count, Description
+  - Feature ID, Feature Name, Type (User Interaction / Backend Process), Scope, Description
   - Feature Dependencies table
 - 3.5 Feature Details: Detailed descriptions for each feature including:
   - Requirement Description

package/package.json

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