speccrew 0.3.7 → 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-pm-requirement-analysis/SKILL.md

@@ -8,7 +8,7 @@ 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 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
 
@@ -34,6 +34,18 @@ This skill applies the ISA-95 six-stage methodology (Stages 1-3) as an internal
 
 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.**
@@ -143,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)
@@ -403,10 +458,10 @@ For both simple and complex requirements, extract Feature Breakdown to guide dow
 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
 
@@ -416,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.
 
@@ -436,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
@@ -623,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
@@ -707,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"
     }
   }
 }
@@ -771,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

@@ -77,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)
 
@@ -223,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

@@ -130,14 +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 | Priority | Pages/Endpoints | Description |
-|------------|-------------|------|----------|-----------------|-------------|
-| F-{MODULE}-01 | {Feature name} | Page+API / API-only | P0 (Must) / P1 (Should) / P2 (Could) | {count} | {Brief description} |
-| F-{MODULE}-02 | {Feature name} | Page+API / API-only | P0 (Must) / P1 (Should) / P2 (Could) | {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
 
@@ -197,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.7",
+  "version": "0.3.8",
   "description": "Spec-Driven Development toolkit for AI-powered IDEs",
   "author": "charlesmu99",
   "repository": {