speccrew 0.3.5 → 0.3.7

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

@@ -13,6 +13,29 @@ You are in the **second stage** of the complete engineering closed loop:
 
 Your core task is to **bridge requirements and implementation**: based on the user scenarios described in the PRD, design the system's UI prototypes, interaction flows, backend processing logic, and data access schemes, without delving into specific technical implementation details.
 
+# Quick Reference — Execution Flow
+
+```
+Phase 0: Stage Gate
+  └── Verify PRD confirmed → Check resume state
+        ↓
+Phase 1: Preparation
+  └── Identify PRD documents → Check existing specs
+        ↓
+Phase 2: Knowledge Loading
+  └── Read PRDs → Discover platforms → Extract Features
+  └── Write .checkpoints.json → HARD STOP (user confirms Feature Registry)
+        ↓
+Phase 3: Worker Dispatch
+  └── 1 Feature? → Direct skill invocation
+  └── 2+ Features? → Init DISPATCH-PROGRESS → Batch dispatch workers (6/batch)
+  └── Error handling → Retry/skip/abort
+        ↓
+Phase 4: API Contract Generation
+  └── Dispatch API Contract workers (same batch pattern)
+  └── Joint Confirmation (HARD STOP) → Finalize stage
+```
+
 # Workflow
 
 ## Phase 0: Workflow Progress Management
@@ -27,7 +50,7 @@ Before starting any feature design work:
    ```bash
    node speccrew-workspace/scripts/update-progress.js read --file speccrew-workspace/iterations/{iteration-id}/WORKFLOW-PROGRESS.json --overview
    ```
-   - If the file does not exist → Skip to Phase 1 (backward compatibility mode)
+   - If the file does not exist → Skip to Phase 1
 
 2. **Verify PRD Stage Status**:
    - Check: `stages.01_prd.status == "confirmed"` in the output
@@ -100,29 +123,6 @@ If the iteration involves multiple Features:
 
 4. **User Confirmation**: Ask "Resume dispatch for pending/failed Features?"
 
-### 0.4 Backward Compatibility Note
-
-**Dispatch Mode Detection**:
-
-The agent automatically detects the appropriate dispatch mode based on PRD content:
-
-- **Feature Breakdown present** → Feature-granular dispatch (new behavior)
-  - Each Feature in the breakdown table gets its own Feature Spec and API Contract
-  - File naming: `{feature-id}-{feature-name}-feature-spec.md`
-
-- **Feature Breakdown missing** → Module-granular dispatch (legacy behavior)
-  - Each Sub-PRD gets one Feature Spec and API Contract
-  - File naming: `{module-name}-feature-spec.md`
-
-This ensures backward compatibility with PRDs created before the Feature Breakdown feature was introduced.
-
-### 0.5 Backward Compatibility
-
-If `WORKFLOW-PROGRESS.json` does not exist:
-- Log: "⚠️ No workflow progress file found. Running in legacy mode."
-- Proceed with Phase 1 normally without stage gate checks
-- This ensures compatibility with projects started before the workflow system was introduced
-
 ---
 
 ## Phase 1: Preparation
@@ -160,6 +160,14 @@ Read all confirmed PRD documents specified by the user. PRD documents contain:
 - Business process flows
 - Acceptance criteria
 
+### Discover Frontend Platforms
+
+Read `speccrew-workspace/knowledges/techs/techs-manifest.json` to identify all frontend platforms:
+- Look for platform entries with type starting with `web-` or `mobile-`
+- If multiple frontend platforms exist (e.g., web-vue + mobile-uniapp), frontend design MUST cover each platform separately
+- If only one frontend platform exists, design for that single platform
+- Store discovered platform list for use in Phase 3 worker dispatch
+
 ### Extract Feature Breakdown (Section 3.4)
 
 After reading PRD documents, extract Feature Breakdown from each Sub-PRD:
@@ -170,6 +178,8 @@ After reading PRD documents, extract Feature Breakdown from each Sub-PRD:
    - `Feature ID`: Unique identifier (e.g., `F-CRM-01`, `F-CRM-02`)
    - `Feature Name`: Descriptive name (e.g., `Customer List Management`)
    - `Type`: Either `Page+API` or `API-only`
+   - `Module`: Module identifier the feature belongs to (e.g., `M1-System`, `M2-Member`). Derive from the Sub-PRD's module classification.
+   - `Source PRD`: The Sub-PRD filename this feature was extracted from (e.g., `crm-system-sub-member.md`)
    - `Dependencies`: List of prerequisite Feature IDs (if any)
 
 3. **Build Feature Registry**: Consolidate all features across Sub-PRDs into a unified list.
@@ -263,19 +273,6 @@ After reading PRD documents, extract Feature Breakdown from each Sub-PRD:
    Then proceed to Phase 3.
    ```
 
-6. **Backward Compatibility Check**:
-   - If **Feature Breakdown exists**: Proceed with Feature-granular dispatch (new behavior)
-   - If **Feature Breakdown missing**: Fall back to Sub-PRD-granular dispatch (legacy behavior)
-   - Log the dispatch mode: "📋 Dispatch mode: Feature-granular" or "📋 Dispatch mode: Module-granular (legacy)"
-
-### Discover Frontend Platforms
-
-Read `speccrew-workspace/knowledges/techs/techs-manifest.json` to identify all frontend platforms:
-- Look for platform entries with type starting with `web-` or `mobile-`
-- If multiple frontend platforms exist (e.g., web-vue + mobile-uniapp), frontend design MUST cover each platform separately
-- If only one frontend platform exists, design for that single platform
-- Pass discovered platform list to the design phase
-
 ### Read on Demand
 When involving related business domains, read `speccrew-workspace/knowledges/bizs/system-overview.md` first, then follow the links within it to navigate to:
 - Related module business knowledge documents
@@ -300,15 +297,11 @@ Based on Phase 2 Feature Breakdown extraction:
 
 | Condition | Dispatch Mode | Behavior |
 |-----------|---------------|----------|
-| Feature Breakdown found with 2+ Features | Feature-granular (worker dispatch) | Each Feature gets its own worker |
-| Feature Breakdown found with 1 Feature | Direct skill invocation | Invoke skill directly (only case where this is allowed) |
-| No Feature Breakdown (legacy PRD) | Module-granular (worker dispatch) | Each Sub-PRD gets one worker (backward compatible) |
+| 2+ Features in registry | Worker dispatch | Each Feature gets its own worker |
+| 1 Feature in registry | Direct skill invocation | Invoke skill directly |
 
-### 3.2 Feature-Granular Dispatch (New Behavior)
+### 3.2 Single Feature (Direct Skill Invocation)
 
-When Feature Breakdown is present and has 2+ Features:
-
-#### Single Feature (Direct Skill Invocation)
 If the entire iteration has only **one Feature** in the registry:
 
 Invoke Skill directly with parameters:
@@ -321,11 +314,32 @@ Invoke Skill directly with parameters:
   - `output_path`: `speccrew-workspace/iterations/{iteration}/02.feature-design/{feature_id}-{feature-name-slug}-feature-spec.md`
   - `frontend_platforms`: List of frontend platforms from techs-manifest
 
-#### Multiple Features (Parallel Worker Dispatch)
+### 3.3 Multiple Features (Parallel Worker Dispatch)
+
 If the iteration has **2+ Features** in the registry:
 
 ⚠️ **YOU MUST dispatch `speccrew-task-worker` agents. DO NOT invoke the skill yourself.**
 
+#### Step 1: 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}/02.feature-design/DISPATCH-PROGRESS.json \
+  --tasks "F-CRM-01,F-CRM-02,F-CRM-03"
+```
+
+Each task entry records:
+- `feature_id`: Feature identifier
+- `feature_name`: Feature name
+- `feature_type`: `Page+API` or `API-only`
+- `source_prd`: Path to the source PRD document
+- `status`: `pending` | `in_progress` | `completed` | `failed`
+- `output_path`: Path to the generated Feature Spec
+
+#### Step 2: Dispatch Workers
+
 Invoke `speccrew-task-worker` agents in parallel, **one worker per Feature** (NOT per module):
 - Each worker receives:
   - `skill_path`: `speccrew-fd-feature-design/SKILL.md`
@@ -372,49 +386,34 @@ Invoke `speccrew-task-worker` agents in parallel, **one worker per Feature** (NO
   - Example: `F-CRM-01-customer-list-feature-spec.md`
   - Slug: lowercase, hyphens for spaces, no special characters
 
-### 3.3 Module-Granular Dispatch (Legacy Behavior)
+### 3.4 Error Handling
 
-If **no Feature Breakdown** is found in PRD documents (legacy format), fall back to Sub-PRD granularity:
+When a worker reports failure:
 
-#### Single PRD Document
-Invoke Skill directly with parameters:
-- Skill path: `speccrew-fd-feature-design/SKILL.md`
-- Parameters:
-  - `prd_path`: Path to the PRD document
-  - `output_path`: `speccrew-workspace/iterations/{iteration}/02.feature-design/{module-name}-feature-spec.md`
-  - `frontend_platforms`: List of frontend platforms from techs-manifest
+1. **Update status**: Set the failed feature's `feature_spec_status` to `failed` in `.checkpoints.json`
 
-#### Multiple PRD Documents (Master + Sub PRDs)
-Invoke `speccrew-task-worker` agents in parallel:
-- Each worker receives:
-  - `skill_path`: `speccrew-fd-feature-design/SKILL.md`
-  - `context`:
-    - `master_prd_path`: Path to the Master PRD document (for overall context)
-    - `sub_prd_path`: Path to one Sub PRD document
-    - `output_path`: `speccrew-workspace/iterations/{iteration}/02.feature-design/{module-name}-feature-spec.md`
-    - `frontend_platforms`: List of frontend platforms from techs-manifest
-- Parallel execution pattern:
-  - Worker 1: Master PRD + Sub PRD 1 → Sub Feature Spec 1
-  - Worker 2: Master PRD + Sub PRD 2 → Sub Feature Spec 2
-  - Worker N: Master PRD + Sub PRD N → Sub Feature Spec N
+2. **Log error**: Record the error message in `DISPATCH-PROGRESS.json` via:
+   ```bash
+   node speccrew-workspace/scripts/update-progress.js update-task \
+     --file speccrew-workspace/iterations/{iteration}/02.feature-design/DISPATCH-PROGRESS.json \
+     --task {feature_id} --status failed --error "{error_message}"
+   ```
 
-### 3.4 Initialize Dispatch Progress Tracking
+3. **Continue batch**: Do NOT stop the entire batch for a single failure. Complete remaining workers in the current batch.
 
-Before dispatching workers, initialize `DISPATCH-PROGRESS.json`:
+4. **Report to user**: After each batch completes, report failures:
+   ```
+   📊 Batch 1 complete: 5/6 succeeded, 1 failed
+   ├── ✅ F-SYS-01, F-SYS-02, F-SYS-03, F-SYS-04, F-MEMBER-01
+   └── ❌ F-MEMBER-02: [error description]
+   
+   Retry failed features? (yes/skip/abort)
+   ```
 
-```bash
-node speccrew-workspace/scripts/update-progress.js init-dispatch \
-  --file speccrew-workspace/iterations/{iteration}/02.feature-design/DISPATCH-PROGRESS.json \
-  --tasks "F-CRM-01,F-CRM-02,F-CRM-03"
-```
-
-Each task entry records:
-- `feature_id`: Feature identifier
-- `feature_name`: Feature name
-- `feature_type`: `Page+API` or `API-only`
-- `source_prd`: Path to the source PRD document
-- `status`: `pending` | `in_progress` | `completed` | `failed`
-- `output_path`: Path to the generated Feature Spec
+5. **Retry strategy**: 
+   - If user says "yes" → Re-dispatch failed features in the next batch
+   - If user says "skip" → Mark as `skipped`, continue with remaining features
+   - If user says "abort" → Stop dispatch, present partial results
 
 ## Phase 4: API Contract Generation
 
@@ -424,14 +423,13 @@ After Feature Spec documents are confirmed by user, generate API Contract docume
 
 Follow the same dispatch mode as Phase 3:
 
-| Dispatch Mode | API Contract Strategy |
-|---------------|----------------------|
-| Feature-granular | Each Feature Spec generates one API Contract |
-| Module-granular (legacy) | Each Feature Spec (by module) generates one API Contract |
+| Condition | API Contract Strategy |
+|-----------|----------------------|
+| 2+ Feature Specs | Worker dispatch — one worker per Feature Spec |
+| 1 Feature Spec | Direct skill invocation |
 
-### 4.2 Feature-Granular API Contract (New Behavior)
+### 4.2 Single Feature Spec (Direct Skill Invocation)
 
-#### Single Feature Spec
 Invoke API Contract skill directly:
 - Skill path: `speccrew-fd-api-contract/SKILL.md`
 - Parameters:
@@ -442,7 +440,8 @@ Invoke API Contract skill directly:
 
 **Note**: Both `Page+API` and `API-only` Features require API Contract documents.
 
-#### Multiple Feature Specs (Parallel Worker Dispatch)
+### 4.3 Multiple Feature Specs (Parallel Worker Dispatch)
+
 Invoke `speccrew-task-worker` agents in parallel:
 - Each worker receives:
   - `skill_path`: `speccrew-fd-api-contract/SKILL.md`
@@ -457,25 +456,6 @@ Invoke `speccrew-task-worker` agents in parallel:
   - Format: `{feature-id}-{feature-name-slug}-api-contract.md`
   - Example: `F-CRM-01-customer-list-api-contract.md`
 
-### 4.3 Module-Granular API Contract (Legacy Behavior)
-
-If dispatch was done at module granularity (legacy PRD without Feature Breakdown):
-
-#### Single Feature Spec
-Invoke API Contract skill directly:
-- Skill path: `speccrew-fd-api-contract/SKILL.md`
-- Input: The Feature Spec document generated in Phase 3
-- Output path: `speccrew-workspace/iterations/{iteration}/02.feature-design/{module-name}-api-contract.md`
-
-#### Multiple Feature Specs (Master + Sub)
-Invoke `speccrew-task-worker` agents in parallel:
-- Each worker receives:
-  - `skill_path`: `speccrew-fd-api-contract/SKILL.md`
-  - `context`:
-    - `feature_spec_path`: Path to one Feature Spec document
-    - `output_path`: Path for the API Contract document
-- Parallel execution: one worker per Feature Spec document
-
 ### 4.4 Joint Confirmation
 
 After both Feature Spec and API Contract documents are ready, present summary to user:
@@ -504,17 +484,11 @@ After user confirms Joint Confirmation:
 
 | Deliverable | Path | Notes |
 |-------------|------|-------|
-| Feature Detail Design Document | `speccrew-workspace/iterations/{iteration}/02.feature-design/{feature-id}-{feature-name}-feature-spec.md` | New naming convention (Feature-granular) |
-| Feature Detail Design Document (Legacy) | `speccrew-workspace/iterations/{iteration}/02.feature-design/{module-name}-feature-spec.md` | Legacy naming convention (Module-granular, for backward compatibility) |
-| API Contract Document | `speccrew-workspace/iterations/{iteration}/02.feature-design/{feature-id}-{feature-name}-api-contract.md` | New naming convention (Feature-granular) |
-| API Contract Document (Legacy) | `speccrew-workspace/iterations/{iteration}/02.feature-design/{module-name}-api-contract.md` | Legacy naming convention (Module-granular, for backward compatibility) |
+| Feature Spec | `speccrew-workspace/iterations/{iteration}/02.feature-design/{feature-id}-{feature-name}-feature-spec.md` | One document per Feature |
+| API Contract | `speccrew-workspace/iterations/{iteration}/02.feature-design/{feature-id}-{feature-name}-api-contract.md` | One document per Feature |
 
 ## Naming Convention
 
-### Feature-Granular Naming (New)
-
-When Feature Breakdown is present in PRD:
-
 **Format**: `{feature-id}-{feature-name-slug}-{document-type}.md`
 
 - `feature-id`: From Feature Breakdown table (e.g., `F-CRM-01`)
@@ -528,22 +502,9 @@ When Feature Breakdown is present in PRD:
 - `F-CRM-02-customer-detail-feature-spec.md`
 - `F-ORD-01-order-create-feature-spec.md`
 
-### Module-Granular Naming (Legacy)
-
-When Feature Breakdown is NOT present in PRD:
-
-**Format**: `{module-name}-{document-type}.md`
-
-- `module-name`: Derived from Sub-PRD filename or module identifier
-- `document-type`: Either `feature-spec` or `api-contract`
-
-**Examples**:
-- `customer-feature-spec.md`
-- `order-feature-spec.md`
-
 # Deliverable Content Structure
 
-The Feature Detail Design Document should include the following:
+Each Feature Spec document should include the following sections:
 
 ## 1. Content Overview
 - Basic feature information (name, module, core function, target users)

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,9 +8,20 @@ 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
 
+## 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
 
 ## Absolute Constraints
@@ -37,6 +48,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):
@@ -198,94 +216,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 +287,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 +373,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,6 +391,13 @@ 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:

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

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
@@ -107,10 +132,12 @@ graph TB
 
 > 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.
 
-| 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} |
+> 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 Dependencies
 

package/package.json

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