speccrew 0.4.4 → 0.5.0

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

@@ -1,261 +1,73 @@
 ---
 name: speccrew-fd-feature-design
-description: Feature Design SOP. Guide Feature Designer Agent to transform PRD requirements into system feature specifications, including frontend prototypes, backend interface logic, and data model design. Does not involve specific technology implementation details. Use when Feature Designer needs to create feature spec from confirmed PRD.
+description: Feature Design SOP. Transforms function decomposition into complete feature specifications including frontend prototypes, backend interface logic, and data model design. Reads .feature-analysis.md as input and outputs .feature-design-data.md as interface contract for downstream generate skill. Does not involve specific technology implementation details.
 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 Stages 4-6 as 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 |
+| Stage | Integrated Into | Purpose |
+|-------|-----------------|---------|
+| Stage 4: Information Flows | Interaction Flow | Map cross-module data flows, identify API endpoints |
+| Stage 5: Categories of Information | Data Model | Classify data entities, build data dictionary |
+| Stage 6: Information Descriptions | Business Rules | Define validation rules, output standards, traceability |
 
-> ⚠️ **No separate modeling documents.** The methodology guides thinking quality, not document quantity.
+> No separate modeling documents. Methodology guides thinking quality.
 
 # Trigger Scenarios
 
-- PRD has been confirmed, user requests to start feature design
-- User asks "Design this feature" or "Create feature specification" or "How should this feature work"
-- Feature Designer Agent receives task to design system features from PRD
+- Function decomposition completed (`.feature-analysis.md` exists)
+- Checkpoint A passed (function breakdown confirmed)
+- User requests feature specifications design
 
 # Workflow
 
 ## Absolute Constraints
 
-> **These rules apply to ALL steps. Violation = task failure.**
+**ABORT CONDITIONS:** `.feature-analysis.md` does not exist OR Checkpoint A not passed → HARD STOP
 
-1. **FORBIDDEN: `create_file` for documents** — NEVER use `create_file` to write the feature spec document. Documents MUST be created by copying the template (Step 10.2a) then filling sections with `search_replace` (Step 10.2b). `create_file` produces truncated output on large files.
+**FORBIDDEN:** `create_file` for final feature-spec documents (use template + search_replace in generate skill)
 
-2. **FORBIDDEN: Full-file rewrite** — NEVER replace the entire document content in a single operation. Always use targeted `search_replace` on specific sections.
+## Step 0: Precondition Check
 
-3. **MANDATORY: Template-first workflow** — Step 10.2a (copy template) MUST execute before Step 10.2b (fill sections). Skipping Step 10.2a and writing content directly is FORBIDDEN.
+**MANDATORY:** Verify `.feature-analysis.md` exists.
 
-## Step 1: Read PRD Input
+**IF missing → ABORT:** `ERROR: .feature-analysis.md not found. Run speccrew-fd-feature-analysis first.`
 
-### 1.1 Input Parameters
+**Actions:**
+1. Read `.feature-analysis.md`
+2. Verify Checkpoint A: `function_decomposition.passed == true`
+3. IF not passed → STOP
+4. Extract: feature_id, feature_name, feature_type, functions[], platforms[]
 
-The skill receives the following parameters from the calling agent:
+## Step 1: Determine Output Structure
 
-| Parameter | Required | Description |
-|-----------|----------|-------------|
-| `feature_id` | No | Feature identifier (e.g., `F-CRM-01`). If not provided, processes entire PRD (backward compatibility) |
-| `feature_name` | No | Feature name in English (e.g., `customer-list`). Used for file naming |
-| `feature_type` | No | `Page+API` or `API-only`. `API-only` skips frontend design steps |
-| `iteration_id` | No | Current iteration identifier. Paths come from `prd_path`/`output_path`; `iteration_id` is used only for progress messages when available |
-| `prd_path` | Yes | Path to the Sub-PRD document |
+### 1.1 Single Feature Output (when feature_id provided)
 
-### 1.2 Read PRD
+| Output | File Naming | Example |
+|--------|-------------|---------|
+| Single File | `{feature-id}-{feature-name}.feature-design-data.md` | `F-CRM-01-customer-list.feature-design-data.md` |
 
-Read in order:
+### 1.2 Legacy Output (backward compatibility)
 
-1. **Current iteration PRD**: `{prd_path}` (typically `speccrew-workspace/iterations/{number}-{type}-{name}/01.product-requirement/[module-name]-prd.md`)
-2. **Feature spec template**: `speccrew-fd-feature-design/templates/FEATURE-SPEC-TEMPLATE.md`
+When `feature_id` is NOT provided: Single PRD → Single file; Master-Sub PRD → Master + Sub files
 
-### 1.3 Focus on Specific Feature (when feature_id provided)
+**Master Design Data MUST include:** overall overview, cross-module diagram, module boundaries, interface contracts, shared data structures.
 
-If `feature_id` is provided:
-- Locate the specific Feature in PRD Section 3.4 "Feature Breakdown"
-- Extract only the user stories and requirements related to this Feature
-- Ignore other Features in the same PRD
-- Use the Feature's scope to guide function breakdown
+## Step 2: Frontend Design (Per Function)
 
-### 1.4 Backward Compatibility (when feature_id not provided)
+### 2.0 Conditional Execution
 
-If `feature_id` is NOT provided, process entire PRD using legacy mode. For Master-Sub PRD structure, read master PRD and all sub PRDs. See Reference Guides for detailed behavior.
+`feature_type = "Page+API"` → Execute design; `feature_type = "API-only"` → Skip; Not provided → Execute (backward compatibility)
 
-## Step 2: Load System Knowledge
+**Multi-Platform Rule:** Repeat design for EACH platform with platform-specific headers.
 
-### 2.1 Read System Overview
+**Mobile Wireframe Patterns:**
 
-Read the file to understand system context:
 ```
-speccrew-workspace/knowledges/bizs/system-overview.md
-```
-
-### 2.2 Load Related Module Overviews
-
-Based on PRD content, identify related modules and read their overview files:
-```
-speccrew-workspace/knowledges/bizs/{module-name}/{module-name}-overview.md
-```
-
-### 2.2b Discover Frontend Platforms
-
-Read `speccrew-workspace/knowledges/techs/techs-manifest.json` to identify frontend platforms:
-
-| Platform Type | Examples | Design Implications |
-|---------------|----------|---------------------|
-| `web-*` | web-vue, web-react | Desktop-width layouts, tables, modals, sidebars |
-| `mobile-*` | mobile-uniapp, mobile-flutter | Compact layouts, card lists, bottom nav, swipe actions |
-
-- If `frontend_platforms` parameter is provided by the agent, use that list
-- Otherwise, read techs-manifest.json directly
-- Store the platform list for use in Step 5
-
-### 2.3 Query Knowledge Graph (Optional)
-
-If cross-module relationships need analysis, use `speccrew-knowledge-graph-query` skill:
-
-| Action | Use Case |
-|--------|----------|
-| `query-nodes` | Find all nodes in a module |
-| `search` | Find related entities by keyword |
-| `trace-upstream` | Impact analysis for existing entities |
-| `trace-downstream` | Dependency analysis |
-
-## Step 3: Function Breakdown
-
-Break down PRD functional requirements into implementable system functions.
-
-### 3.1 Feature-Based Decomposition (when feature_id provided)
-
-When processing a single Feature:
-
-1. **Extract Feature Scope**: From PRD Section 3.4, locate the specific Feature by `feature_id`
-2. **Identify Related User Stories**: Extract only user stories mapped to this Feature
-3. **Decompose into Functions**: Break down into 3-8 focused Functions (not 10-20)
-4. **Check feature_type**:
-   - If `feature_type = API-only`: Mark for backend-only design (skip frontend in Step 5)
-   - If `feature_type = Page+API`: Include both frontend and backend design
-
-### 3.2 Full PRD Decomposition (backward compatibility)
-
-When `feature_id` is NOT provided (legacy mode):
-- Decompose entire PRD into all required Functions
-- May result in 10-20 Functions for complex modules
-
-### 3.3 Function Analysis
-
-For each function, identify:
-
-| Aspect | Analysis Content |
-|--------|------------------|
-| **Frontend Changes** | New pages, components, or modifications to existing UI |
-| **Backend Changes** | New interfaces or modifications to existing logic |
-| **Data Changes** | New data structures or modifications to existing data |
-| **System Relationship** | How this relates to existing system capabilities |
-
-### Mark Relationship to Existing System
-
-| Marker | Meaning | Example |
-|--------|---------|---------|
-| `[EXISTING]` | Reuse current system capability | `[EXISTING] User authentication system` |
-| `[MODIFIED]` | Enhance/change existing feature | `[MODIFIED] Add validation to user profile form` |
-| `[NEW]` | Create brand new functionality | `[NEW] Order management module` |
-
-**Checkpoint A: Present function breakdown to user for confirmation before proceeding.**
-
-Ask: "Here is the function breakdown with [EXISTING]/[MODIFIED]/[NEW] markers. Does this align with your understanding of the requirements?"
-
-### Checkpoint A Progress Update
-
-After user confirms the function breakdown:
-
-1. **Write/Update `.checkpoints.json`**:
-   - Path: `speccrew-workspace/iterations/{iteration-id}/02.feature-design/.checkpoints.json`
-   - Content:
-     ```json
-     {
-       "stage": "02_feature_design",
-       "checkpoints": {
-         "function_decomposition": {
-           "passed": true,
-           "confirmed_at": "{current_timestamp}",
-           "description": "Function decomposition confirmed"
-         },
-         "feature_spec_review": {
-           "passed": false,
-           "confirmed_at": null
-         },
-         "api_contract_joint": {
-           "passed": false,
-           "confirmed_at": null
-         }
-       }
-     }
-     ```
-
-2. If the file already exists, merge with existing content (preserve other checkpoints)
-
-3. Log: "✅ Checkpoint A (function_decomposition) passed and recorded"
-
-## Step 4: Determine Output Structure
-
-### 4.1 Single Feature Output (when feature_id provided)
-
-When processing a single Feature:
-
-| Output | Description |
-|--------|-------------|
-| **Single File** | One Feature Spec document for this Feature only |
-| **File Naming** | `[feature-id]-[feature-name]-feature-spec.md` |
-| **Example** | `F-CRM-01-customer-list-feature-spec.md` |
-
-**No Master-Sub structure** for single Feature mode.
-
-### 4.2 Legacy Output (backward compatibility)
-
-When `feature_id` is NOT provided:
-
-| PRD Structure | Feature Spec Structure |
-|---------------|------------------------|
-| **Single PRD** | Single Feature Spec |
-| **Master-Sub PRD** | Master Feature Spec + Sub Feature Specs (one per module) |
-
-#### Master Feature Spec Structure (Legacy)
-
-```
-02.feature-design/
-├── [feature-name]-feature-spec.md          # Master Feature Spec (overview + cross-module)
-├── [feature-name]-sub-[module1]-spec.md    # Sub Feature Spec: Module 1
-├── [feature-name]-sub-[module2]-spec.md    # Sub Feature Spec: Module 2
-└── ...
-```
-
-**Master Feature Spec MUST include:**
-- Overall feature overview and goals
-- Cross-module interaction diagram
-- Module list with scope boundaries
-- Cross-module interface contracts
-- Shared data structures
-
-**Each Sub Feature Spec covers ONE module:**
-- Module-specific frontend design
-- Module-specific backend interfaces
-- Module-internal data model
-- Interface contracts with other modules
-
-## Step 5: Frontend Design (Per Function)
-
-### 5.0 Conditional Execution Based on feature_type
-
-**Execution Logic:**
-```
-IF feature_type = "Page+API" THEN
-  → Execute Step 5 (Full frontend design)
-IF feature_type = "API-only" THEN
-  → Skip Step 5 entirely (No frontend design needed)
-IF feature_type is NOT provided THEN
-  → Execute Step 5 (backward compatibility)
-```
-
-**Multi-Platform Rule**: If multiple frontend platforms are identified, repeat the frontend design (5.1 UI Prototype + 5.2 Interface Elements + 5.3 Interaction Flow) for EACH platform. Use platform-specific section headers:
-
-| Platforms | Section Structure |
-|-----------|-------------------|
-| Single platform | `#### 2.N.1 Frontend Prototype` (as-is) |
-| Multiple platforms | `#### 2.N.1 Frontend Prototype - Web` + `#### 2.N.1b Frontend Prototype - Mobile` |
-
-**Mobile-specific wireframe patterns:**
-
-> **Note**: These are ASCII wireframe design specifications, NOT actual template files in the `templates/` directory.
-
-```
-Pattern M-A: Card List (replaces PC table list)
+Pattern M-A: Card List
 +----------------------------------+
 |  [Search...]            [Filter] |
 +----------------------------------+
@@ -269,13 +81,12 @@ Pattern M-A: Card List (replaces PC table list)
 |  | Subtitle / Key info        |  |
 |  | Detail line      [Action]  |  |
 |  +----------------------------+  |
-|                                  |
 |  [Load More / Pull to Refresh]   |
 +----------------------------------+
 |  [Tab1] [Tab2] [Tab3] [Tab4]    |
 +----------------------------------+
 
-Pattern M-B: Mobile Form (replaces PC wide form)
+Pattern M-B: Mobile Form
 +----------------------------------+
 |  < Back     Title       [Save]   |
 +----------------------------------+
@@ -292,10 +103,9 @@ Pattern M-B: Mobile Form (replaces PC wide form)
 |  [Switch toggle            O ]   |
 +----------------------------------+
 
-Pattern M-C: Action Sheet (replaces PC modal)
+Pattern M-C: Action Sheet
 +----------------------------------+
 | (dimmed background)              |
-|                                  |
 |  +----------------------------+  |
 |  | Action Sheet Title         |  |
 |  +----------------------------+  |
@@ -308,16 +118,11 @@ Pattern M-C: Action Sheet (replaces PC modal)
 +----------------------------------+
 ```
 
-For each function requiring frontend changes:
+### 2.1 UI Prototype
 
-### 5.1 UI Prototype
+Create ASCII wireframes showing layout, UI elements, navigation.
 
-Create ASCII wireframes showing:
-- Page/component layout
-- Key UI elements and their positions
-- Navigation structure
-
-**Example ASCII Wireframe:**
+**PC Wireframe Example:**
 ```
 +--------------------------------------------------+
 |  Header: User Management                          |
@@ -334,454 +139,168 @@ Create ASCII wireframes showing:
 +--------------------------------------------------+
 ```
 
-### 5.2 Interface Element Descriptions
+### 2.2 Interface Element Descriptions
 
 | Element | Type | Behavior |
 |---------|------|----------|
-| {element name} | {component type} | {description of behavior} |
-
-### 5.3 Interaction Flow
-
-Document user actions and system responses:
+| {name} | {component type} | {behavior description} |
 
-```
-User Action → Frontend Response → Backend API Call
-```
+### 2.3 Interaction Flow
 
-> **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.
+Document: `User Action → Frontend Response → Backend API Call`
 
-**Example:**
-```
-1. User clicks "New User" button
-   → Frontend displays modal form
-   → No API call yet
-
-2. User fills form and clicks "Save"
-   → Frontend validates input
-   → Calls POST /api/users
-   → On success: closes modal, refreshes list
-   → On error: displays error message
-```
+> **ISA-95 Stage 4 Thinking — Information Flows**
+> - Cross-module flows: Map data flows between feature and other modules
+> - Sequence coverage: Complete chain user→frontend→backend→database→external
+> - Interface identification: Every data exchange point = potential API endpoint
+> - Exception flows: Document alternative paths, not just happy path
 
-### 5.4 Backend API Mapping
+### 2.4 Backend API Mapping
 
 | Frontend Action | Backend API | Purpose |
 |-----------------|-------------|---------|
-| {action} | {API endpoint} | {what data is exchanged} |
+| {action} | {API endpoint} | {data exchanged} |
 
-## Step 6: Backend Design (Per Function)
+## Step 3: Backend Design (Per Function)
 
-For each function requiring backend changes:
-
-### 6.1 API/Interface List
+### 3.1 API/Interface List
 
 | Interface | Method | Description |
 |-----------|--------|-------------|
-| {name} | {GET/POST/PUT/DELETE} | {purpose, no technical implementation details} |
-
-### 6.2 Processing Logic Flow
+| {name} | {GET/POST/PUT/DELETE} | {purpose} |
 
-For each interface, document:
+### 3.2 Processing Logic Flow
 
 | Stage | Description |
 |-------|-------------|
-| **Input Validation** | What business rules validate the input |
-| **Business Logic** | Core processing steps (conceptual, not code) |
-| **Data Operations** | What data to read/write |
-| **Response** | What data to return |
-
-**Example:**
-```
-Interface: Create Order
+| Input Validation | Business rules validating input |
+| Business Logic | Core processing steps (conceptual) |
+| Data Operations | What data to read/write |
+| Response | What data to return |
 
-Input Validation:
-- User must be authenticated
-- Product must be available
-- Quantity must be positive
-
-Business Logic:
-1. Check product inventory
-2. Calculate total price
-3. Create order record
-4. Reserve inventory
-
-Data Operations:
-- Read: product info, inventory count
-- Write: order record, inventory reservation
-
-Response:
-- Order ID, status, estimated delivery
-```
-
-### 6.3 Data Access Scheme
+### 3.3 Data Access Scheme
 
 | Operation | Data Target | Type |
 |-----------|-------------|------|
-| Read | {existing/new data} | [EXISTING]/[NEW] |
-| Write | {existing/new data} | [EXISTING]/[NEW] |
-
-### 6.4 Cross-Module Interactions
+| Read | {data} | [EXISTING]/[NEW] |
+| Write | {data} | [EXISTING]/[NEW] |
 
-**[Cross-module functions only]**
+### 3.4 Cross-Module Interactions
 
 | This Module | Interacts With | Interface | Data Exchanged |
 |-------------|----------------|-----------|----------------|
 | {module} | {other module} | {API/Event} | {what data} |
 
-## Step 7: Data Model Design
+## Step 4: Data Model Design
 
-### 7.1 New Data Structures
-
-For each new entity:
+### 4.1 New Data Structures
 
 | Field | Type | Constraints | Description |
 |-------|------|-------------|-------------|
-| {field name} | {data type} | {required/unique/etc} | {purpose} |
+| {field} | {data type} | {required/unique} | {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.
+> - Classification: Categorize data (master, transactional, reference, computed)
+> - Dictionary rigor: Every field needs name, type, constraints, semantic description
+> - Semantic consistency: Align with domain glossary
+> - Relationships: Identify core relationships (1:1, 1:N, N:N)
 
-### 7.2 Modifications to Existing Data Structures
+### 4.2 Modifications to Existing Data Structures
 
 | Entity | Change Type | Details | Impact |
 |--------|-------------|---------|--------|
-| {entity} | Add field / Modify field / Remove field | {description} | {affected areas} |
+| {entity} | Add/Modify/Remove field | {description} | {affected areas} |
 
-### 7.3 Data Relationships
+### 4.3 Data Relationships
 
-**New Entity Relationships:**
-```
-EntityA --1:N--> EntityB
-EntityA --N:1--> EntityC
-```
+**New Relationships:** `EntityA --1:N--> EntityB`
 
-**Relationships with Existing Entities:**
 | New Entity | Existing Entity | Relationship |
 |------------|-----------------|--------------|
 | {new} | {existing} | {1:1 / 1:N / N:M} |
 
-### 7.4 Data Source Descriptions
+### 4.4 Data Source Descriptions
 
 | Data | Source | Update Frequency |
 |------|--------|------------------|
-| {data item} | {internal system / external API / user input} | {real-time / periodic / on-demand} |
+| {item} | {internal/external/user} | {real-time/periodic/on-demand} |
 
-## Step 8: Business Rules and Constraints
+## Step 5: 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.
+> - Validation: Field-level, cross-field, business logic rules
+> - Output standards: Format specifications for downstream API Contract
+> - Permissions: Data access rules mapping to API authorization
+> - Traceability: Every rule traces back to PRD requirement
 
-### 8.1 Permission Rules
+### 5.1 Permission Rules
 
 | Function | Required Permission | Scope |
 |----------|---------------------|-------|
-| {function} | {permission name} | {global / module-specific / resource-specific} |
+| {function} | {permission} | {global/module/resource-specific} |
 
-### 8.2 Business Logic Rules
+### 5.2 Business Logic Rules
 
 | Rule ID | Description | Trigger | Action |
 |---------|-------------|---------|--------|
-| BR-{number} | {rule description} | {when it applies} | {what happens} |
+| BR-{number} | {description} | {when applies} | {what happens} |
 
-### 8.3 Validation Rules
+### 5.3 Validation Rules
 
 | Field | Frontend Validation | Backend Validation |
 |-------|---------------------|---------------------|
-| {field} | {client-side rules} | {server-side rules} |
-
-## Step 9: Present Complete Feature Spec for Confirmation (Checkpoint B)
-
-Present summary to user before writing files:
-
-### Summary Structure
-
+| {field} | {client rules} | {server rules} |
+
+## Step 6: Write Output Contract
+
+Write to `{feature-id}-{feature-name}.feature-design-data.md`:
+
+```markdown
+# Feature Design Data: {feature-name}
+
+## Output Structure
+- Mode: {single-feature/legacy-master-sub}
+- Output path: {planned path}
+
+## Frontend Design
+### Platforms: {list}
+### UI Prototypes
+[Per-platform ASCII wireframes]
+### Interface Elements
+[Element tables]
+### Interaction Flows
+[Mermaid diagrams + descriptions]
+### Backend API Mapping
+[Action → API mapping tables]
+
+## Backend Design
+### API/Interface List
+[Interface tables]
+### Processing Logic
+[Logic flows]
+### Data Access Scheme
+[Operation tables]
+### Cross-Module Interactions
+[Cross-module tables]
+
+## Data Model
+### New Data Structures
+[Entity field tables]
+### Modified Data Structures
+[Modification tables]
+### Data Relationships
+[Relationship diagrams]
+### Data Sources
+[Source tables]
+
+## Business Rules
+### Permission Rules
+[Permission tables]
+### Business Logic Rules
+[Rule tables with BR-{number} IDs]
+### Validation Rules
+[Validation tables]
 ```
-Feature Design Summary for: {feature-name}
-
-Functions Designed: {count}
-├── [EXISTING] {count} functions reuse existing capabilities
-├── [MODIFIED] {count} functions enhance existing features
-└── [NEW] {count} functions are brand new
-
-Frontend Components: {count} pages/components
-Backend Interfaces: {count} APIs
-Data Entities: {count} new, {count} modified
-
-Output File: {filename}
-```
-
-**Ask user to confirm:**
-1. Is the frontend prototype appropriate for user needs? (if applicable)
-2. Is the backend logic flow correct and complete?
-3. Is the data model reasonable and extensible?
-4. Are all business rules and constraints captured?
-5. **[Legacy Master-Sub]** Is the module breakdown appropriate?
-
-### Checkpoint B Progress Update
-
-After user confirms the complete feature spec:
-
-1. **Update `.checkpoints.json`**:
-   - Path: `speccrew-workspace/iterations/{iteration-id}/02.feature-design/.checkpoints.json`
-   - Update content:
-     ```json
-     {
-       "stage": "02_feature_design",
-       "checkpoints": {
-         "function_decomposition": {
-           "passed": true,
-           "confirmed_at": "..."
-         },
-         "feature_spec_review": {
-           "passed": true,
-           "confirmed_at": "{current_timestamp}",
-           "description": "Feature specification confirmed"
-         },
-         "api_contract_joint": {
-           "passed": false,
-           "confirmed_at": null
-         }
-       }
-     }
-     ```
-
-2. Preserve `function_decomposition` checkpoint status when updating
-
-3. Log: "✅ Checkpoint B (feature_spec_review) passed and recorded"
-
-## Step 10: Write Files
-
-### 10.1 Determine Output Paths
-
-#### Single Feature Mode (when feature_id provided)
-
-```
-speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/{feature-id}-{feature-name}-feature-spec.md
-```
-
-**Naming Rules:**
-- `feature-id`: As provided in input (e.g., `F-CRM-01`)
-- `feature-name`: Converted to kebab-case (lowercase with hyphens)
-- **Example**: `F-CRM-01-customer-list-feature-spec.md`
-
-#### Legacy Mode (backward compatibility)
-
-**Single Feature Spec:**
-```
-speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/[feature-name]-feature-spec.md
-```
-
-**Master-Sub Feature Specs:**
-```
-speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/
-├── [feature-name]-feature-spec.md
-├── [feature-name]-sub-[module1]-spec.md
-├── [feature-name]-sub-[module2]-spec.md
-└── ...
-```
-
-If the iteration directory does not exist, refer to the `000-sample` directory structure to create it.
-
-### 10.2a Copy Template to Document Path
-
-1. **Read the template file**: `templates/FEATURE-SPEC-TEMPLATE.md`
-2. **Replace top-level placeholders** in the template content:
-   - `{Feature Name}` → actual feature name
-   - Other top-level identifiers from PRD input
-3. **Create the document file** using `create_file`:
-   - Target path: determined in Step 10.1
-   - Content: Template with top-level placeholders replaced
-4. **Verify**: Document should have complete section structure ready for filling
-
-### 10.2b Fill Each Section Using search_replace
-
-Fill each section of the document with actual data from analysis steps.
-
-> ⚠️ **CRITICAL CONSTRAINTS:**
-> - **FORBIDDEN: `create_file` to rewrite the entire document** — it destroys template structure
-> - **MUST use `search_replace` to fill each section individually**
-> - **All section titles and numbering MUST be preserved** — do not delete or renumber
-> - If a section has no applicable content, keep the section title and replace placeholder with "N/A"
-
-**Section Filling Order:**
-
-Fill sections sequentially using `search_replace` for each content block:
-
-| Section | Content Source |
-|---------|---------------|
-| **Feature Overview** | One paragraph explaining what this feature does |
-| **Function Breakdown** | All functions with [EXISTING]/[MODIFIED]/[NEW] markers |
-| **Frontend Design** | ASCII wireframes, interaction flows, API mapping |
-| **Backend Design** | Interface list, logic flows, data access schemes |
-| **Data Model** | Entity definitions, relationships, modifications |
-| **Business Rules** | Permissions, validation, business logic rules |
-| **Cross-Module Interactions** | **[If applicable]** Interface contracts between modules |
-
-For legacy Master-Sub specs (when feature_id not provided), repeat Step 10.2a + 10.2b for each sub-spec document.
-
-### 10.3 Mermaid Diagram Requirements
-
-When generating Mermaid diagrams (architecture diagrams, flow diagrams, etc.), you **MUST** follow the compatibility guidelines defined in:
-- **Reference**: `speccrew-workspace/docs/rules/mermaid-rule.md`
-
-Key requirements:
-- Use only basic node definitions: `A[text content]`
-- No HTML tags (e.g., `<br/>`)
-- No nested subgraphs
-- No `direction` keyword
-- No `style` definitions
-- No special characters in node text
-- Use standard `graph TB/LR` or `sequenceDiagram` syntax only
-
-### 10.4 Call API Contract Skill
-
-After feature spec documents are complete, call `speccrew-fd-api-contract/SKILL.md` to generate API contract document.
-
-### 10.5 Multi-Platform Dispatch Progress Management
-
-**For multi-platform feature design (multiple frontend platforms):**
-
-#### 10.5.1 Pre-Dispatch: Check Resume State
-
-Before dispatching to multiple platforms:
-
-1. **Read existing `DISPATCH-PROGRESS.json`**:
-   - Path: `speccrew-workspace/iterations/{iteration-id}/02.feature-design/DISPATCH-PROGRESS.json`
-   - If exists, analyze task status:
-     ```json
-     {
-       "stage": "02_feature_design",
-       "total": 3,
-       "completed": 2,
-       "failed": 0,
-       "pending": 1,
-       "tasks": [
-         {
-           "id": "fd-web-vue",
-           "platform": "web-vue",
-           "skill": "speccrew-fd-feature-design",
-           "status": "completed",
-           "started_at": "...",
-           "completed_at": "...",
-           "output": "02.feature-design/[feature]-web-vue-feature-spec.md",
-           "error": null
-         }
-       ]
-     }
-     ```
-
-2. **Resume Strategy**:
-   - Skip tasks with `status == "completed"`
-   - Re-execute tasks with `status == "failed"`
-   - Execute tasks with `status == "pending"`
-
-#### 10.5.2 Initialize/Update Dispatch Progress
-
-Create or update `DISPATCH-PROGRESS.json` before starting dispatch:
-
-```json
-{
-  "stage": "02_feature_design",
-  "total": {count},
-  "completed": 0,
-  "failed": 0,
-  "pending": {count},
-  "tasks": [
-    {
-      "id": "fd-{platform}",
-      "platform": "{platform}",
-      "skill": "speccrew-fd-feature-design",
-      "status": "pending",
-      "started_at": null,
-      "completed_at": null,
-      "output": null,
-      "error": null
-    }
-  ]
-}
-```
-
-#### 10.5.3 Update Task Status on Completion
-
-After each worker completes:
-
-1. **Read current `DISPATCH-PROGRESS.json`**
-
-2. **Update the corresponding task entry**:
-   - On success:
-     ```json
-     {
-       "status": "completed",
-       "completed_at": "{timestamp}",
-       "output": "{output_file_path}"
-     }
-     ```
-   - On failure:
-     ```json
-     {
-       "status": "failed",
-       "completed_at": "{timestamp}",
-       "error": "{error_message}"
-     }
-     ```
-
-3. **Update summary counters** (`completed`, `failed`, `pending`)
-
-4. **Write updated `DISPATCH-PROGRESS.json`**
-
-5. Log progress: "📊 Dispatch progress: {completed}/{total} completed, {failed} failed, {pending} pending"
-
----
-
-# Reference Guides
-
-## Backward Compatibility Details (Legacy Mode)
-
-When `feature_id` is NOT provided, the skill operates in legacy mode:
-
-### Master-Sub PRD Structure
-
-If master PRD exists, also read all sub PRDs:
-- Master PRD: `[feature-name]-prd.md`
-- Sub PRDs: `[feature-name]-sub-[module1].md`, `[feature-name]-sub-[module2].md`, etc.
-
-### Output Structure (Legacy)
-
-**Single Feature Spec:**
-```
-speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/[feature-name]-feature-spec.md
-```
-
-**Master-Sub Feature Specs:**
-```
-02.feature-design/
-├── [feature-name]-feature-spec.md          # Master Feature Spec (overview + cross-module)
-├── [feature-name]-sub-[module1]-spec.md    # Sub Feature Spec: Module 1
-├── [feature-name]-sub-[module2]-spec.md    # Sub Feature Spec: Module 2
-```
-
-**Master Feature Spec MUST include:**
-- Overall feature overview and goals
-- Cross-module interaction diagram
-- Module list with scope boundaries
-- Cross-module interface contracts
-- Shared data structures
 
 ---
 
@@ -789,36 +308,23 @@ speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/[feature-
 
 | Rule | Description |
 |------|-------------|
-| **No Technology Decisions** | Do NOT specify frameworks, databases, or implementation technologies |
-| **Focus on WHAT not HOW** | Describe what the system does, not how it's technically implemented |
-| **ASCII Wireframes Only** | Use ASCII art for UI prototypes, not specific design tools |
-| **Mermaid Compatibility** | All diagrams must follow mermaid-rule.md guidelines |
-| **Clear Markers** | Always use [EXISTING]/[MODIFIED]/[NEW] to indicate system relationship |
-| **Checkpoint Before Write** | Always get user confirmation at Checkpoint B before writing files |
+| No Technology Decisions | Do NOT specify frameworks, databases, technologies |
+| Focus on WHAT not HOW | Describe what system does, not how it's implemented |
+| ASCII Wireframes Only | Use ASCII art for UI prototypes |
+| Mermaid Compatibility | Follow mermaid-rule.md guidelines |
+| Clear Markers | Use [EXISTING]/[MODIFIED]/[NEW] markers |
 
 # Checklist
 
-- [ ] PRD has been read, all P0 requirements covered
-- [ ] **[Single Feature Mode]** Feature ID and name parameters received
-- [ ] **[Single Feature Mode]** Only related Feature content extracted from PRD
-- [ ] **[Legacy Mode]** All sub PRDs have been read (if master-sub structure)
-- [ ] System overview loaded for context
-- [ ] Related module overviews loaded
-- [ ] **[Cross-module]** Knowledge graph queried for relationship analysis
-- [ ] Function breakdown completed with [EXISTING]/[MODIFIED]/[NEW] markers
-- [ ] **[Single Feature Mode]** 3-8 focused Functions defined
-- [ ] Checkpoint A passed: function breakdown confirmed with user
-- [ ] Output structure determined (single file for Feature mode)
-- [ ] **[API-only]** Frontend design step skipped correctly
-- [ ] **[Page+API]** Frontend design includes ASCII wireframes and interaction flows
-- [ ] **[Multi-platform]** Each frontend platform has separate wireframes and interaction flows
-- [ ] Backend design includes interface list and logic flows
-- [ ] Data model includes new entities and modifications to existing
-- [ ] Business rules and constraints documented
-- [ ] Checkpoint B passed: complete feature spec confirmed with user
-- [ ] **[Legacy Master-Sub]** Master spec includes cross-module overview and contracts
-- [ ] **[Legacy Master-Sub]** Each sub spec covers exactly one module
-- [ ] All Mermaid diagrams follow mermaid-rule.md
-- [ ] No specific technology decisions included
-- [ ] Files written to correct paths with proper naming (`{feature-id}-{feature-name}-feature-spec.md`)
-- [ ] API contract skill called after writing
+- [ ] `.feature-analysis.md` verified
+- [ ] Checkpoint A passed
+- [ ] Output structure determined
+- [ ] **[API-only]** Frontend design skipped
+- [ ] **[Page+API]** ASCII wireframes and flows included
+- [ ] **[Multi-platform]** Per-platform designs
+- [ ] Backend interfaces and logic documented
+- [ ] Data model with entities and modifications
+- [ ] Business rules documented
+- [ ] ISA-95 Stage 4/5/6 thinking applied
+- [ ] `.feature-design-data.md` created
+- [ ] No technology decisions included