speccrew 0.6.26 → 0.6.27

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

@@ -22,9 +22,9 @@ Phase 0: Stage Gate
 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 2: Load Feature List
+  └── Read .prd-feature-list.json → Verify structure
+  └── Write .checkpoints.json → HARD STOP (user confirms Feature List)
         ↓
 Phase 3: Feature Design — Two-Stage Pipeline
   └── 3a: Analyze (fd-feature-analyze)
@@ -51,7 +51,8 @@ Phase 4: API Contract Generation
 | Phase | Rule | Description |
 |-------|------|-------------|
 | Phase 0 | STAGE GATE | PRD must be confirmed before starting. If not → STOP |
-| Phase 2 | HARD STOP | Feature Registry must be confirmed by user before Phase 3 |
+| Phase 2 | HARD STOP | Feature List must be confirmed by user before Phase 3 |
+| Phase 2 | FILE REQUIRED | `.prd-feature-list.json` must exist. If missing → STOP |
 | Phase 3a | SKILL-ONLY | Analyze workers MUST use speccrew-fd-feature-analyze skill. Agent MUST NOT perform function decomposition itself |
 | Phase 3b | SKILL-ONLY | Design & Generate workers MUST use speccrew-fd-feature-design skill. Agent MUST NOT design features or write Feature Spec documents itself |
 | Phase 3c | HARD STOP (multi) | For 2+ Features: Agent MUST present batch summary and wait for user confirmation after Feature Specs are generated |
@@ -59,7 +60,7 @@ Phase 4: API Contract Generation
 | Phase 4 | HARD STOP | Joint Confirmation must be confirmed by user before finalizing |
 | ALL | ABORT ON FAILURE | If any skill invocation fails → STOP and report. Do NOT attempt to generate content manually as fallback |
 | ALL | SCRIPT ENFORCEMENT | All .checkpoints.json and WORKFLOW-PROGRESS.json updates via update-progress.js script. Manual JSON creation FORBIDDEN |
-| ALL | NAME LOCK | After Phase 2 Feature Registry is confirmed, feature_name is immutable. All Skills MUST use the exact parameter value for output filenames. Name translation or substitution is FORBIDDEN |
+| ALL | NAME LOCK | After Phase 2 Feature List is confirmed, feature_name is immutable. All Skills MUST use the exact parameter value for output filenames. Name translation or substitution is FORBIDDEN |
 
 ## MANDATORY WORKER ENFORCEMENT
 
@@ -131,7 +132,7 @@ This agent MUST execute tasks continuously without unnecessary interruptions.
 1. **Skill Invocation Failure**: Any skill call returns error → STOP. Do NOT generate content manually.
 2. **Script Execution Failure**: `node ... update-progress.js` fails → STOP. Do NOT manually create/edit JSON files.
 3. **Missing Intermediate Artifacts**: `.feature-analysis.md` missing before Phase 3b → STOP.
-4. **User Rejection**: User rejects Feature Registry, batch design summary, or Joint Confirmation → STOP, ask for specific revision requirements.
+4. **User Rejection**: User rejects Feature List, batch design summary, or Joint Confirmation → STOP, ask for specific revision requirements.
 5. **Worker Batch Failure**: If >50% workers in a batch fail → STOP entire batch, report to user.
 
 ## TIMESTAMP INTEGRITY
@@ -261,15 +262,13 @@ Check if feature specification documents already exist in the current iteration:
 - If feature specification documents already exist → Ask user whether to overwrite or create a new version
 - If no feature specification documents exist → Proceed directly to design phase
 
-## Phase 2: Feature Registry Initialization
+## Phase 2: Load Feature List
 
 > 🛑 **ORCHESTRATOR RULES — Phase 2**
-> - ❌ DO NOT read PRD files directly — dispatch Worker
+> - ❌ DO NOT read PRD files directly
 > - ❌ DO NOT parse Feature Breakdown tables yourself
-> - ❌ DO NOT read techs-manifest.json directly
-> - ❌ DO NOT build Feature Registry manually
-> - ✅ ONLY dispatch Worker with `speccrew-fd-feature-registry-init` skill
-> - ✅ ONLY read `.feature-registry.json` after Worker completes
+> - ✅ ONLY read `.prd-feature-list.json` generated by PM Agent
+> - ✅ Verify file structure and content completeness
 > - ✅ ONLY present summary and collect user confirmation
 
 ### Step 1: Confirm PRD Path
@@ -277,63 +276,85 @@ Check if feature specification documents already exist in the current iteration:
 Confirm the PRD directory path with user. The PRD directory should contain:
 - Master PRD (`*-master-prd.md`)
 - Sub-PRD files (`*-sub-*.md`)
+- Feature list (`.prd-feature-list.json`)
 
 Default path: `{iteration_path}/01.product-requirement`
 
-### Step 2: Dispatch Feature Registry Worker
+### Step 2: Read Feature List
 
-Dispatch a Worker to execute `speccrew-fd-feature-registry-init` skill:
+Read `.prd-feature-list.json` from the PRD directory:
 
+```bash
+Get-Content "{iteration_path}/01.product-requirement/.prd-feature-list.json" | ConvertFrom-Json
 ```
-Worker dispatch parameters:
-- skill: speccrew-fd-feature-registry-init
-- prd_dir: {iteration_path}/01.product-requirement
-- workspace_path: {workspace_path}
-- language: {language}
+
+**If file does not exist:**
+
 ```
+❌ ERROR: Feature list file not found
+├── Expected path: {iteration_path}/01.product-requirement/.prd-feature-list.json
+└── This file should be generated by PM Agent during Sub-PRD dispatch
 
-Worker will:
-- Read all PRD files and techs-manifest.json
-- Extract Feature Breakdown from each Sub-PRD Section 3.4
-- Generate `.feature-registry.json`
-- Return summary statistics
+🛑 HARD STOP
+Please ensure PRD phase completed successfully before starting Feature Design.
+```
 
-### Step 3: Verify Feature Registry
+**Verify file structure:**
+- File exists and is valid JSON
+- Contains `modules` array
+- Each module has:
+  - `module_id`: Unique identifier
+  - `module_name`: Display name
+  - `features`: Array of feature objects
+- Each feature has:
+  - `feature_id`: Feature identifier (e.g., `F-CRM-01`)
+  - `feature_name`: Feature name
+  - `feature_type`: `Page+API` or `API-only`
+  - `dependencies`: Array of prerequisite Feature IDs
 
-After Worker completes:
-1. Read `{prd_dir}/.feature-registry.json` — verify it exists and contains valid data
-2. Extract the following for each Feature:
-   - `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
-   - `Source PRD`: The Sub-PRD filename this feature was extracted from
-   - `Dependencies`: List of prerequisite Feature IDs (if any)
+### Step 3: Extract Feature Statistics
 
-3. **Write Feature Registry to `.checkpoints.json`**:
+From the feature list, extract:
 
-   ```bash
-   node {update_progress_script} write-checkpoint \
-     --file {iterations_dir}/{iteration}/02.feature-design/.checkpoints.json \
-     --stage 02_feature_design \
-     --checkpoint function_decomposition \
-     --data '{"features": [...], "total_features": N, "total_modules": M}'
-   ```
+```
+📊 Feature List Summary
+├── Total Modules: {module_count}
+├── Total Features: {total_feature_count}
+├── Features by Type:
+│   ├── Page+API: {page_api_count}
+│   └── API-only: {api_only_count}
+└── Features by Module:
+    ├── {module_1}: {count} features
+    ├── {module_2}: {count} features
+    └── ...
+```
+
+### Step 4: Write Checkpoint
+
+Write feature statistics to `.checkpoints.json`:
+
+```bash
+node {update_progress_script} write-checkpoint `
+  --file {iterations_dir}/{iteration}/02.feature-design/.checkpoints.json `
+  --stage 02_feature_design `
+  --checkpoint function_decomposition `
+  --data '{"features": [...], "total_features": N, "total_modules": M}'
+```
 
-   **Feature status values:**
-   - `pending`: Not started
-   - `in_progress`: Worker dispatched
-   - `completed`: Worker finished successfully
-   - `failed`: Worker failed (needs retry)
-   - `confirmed`: User confirmed the output
+**Feature status values:**
+- `pending`: Not started
+- `in_progress`: Worker dispatched
+- `completed`: Worker finished successfully
+- `failed`: Worker failed (needs retry)
+- `confirmed`: User confirmed the output
 
-   **After each worker completes**, update the corresponding feature's status:
-   - Feature Spec worker done → set `feature_spec_status` = `completed`
-   - API Contract worker done → set `api_contract_status` = `completed`
+**After each worker completes**, update the corresponding feature's status:
+- Feature Spec worker done → set `feature_spec_status` = `completed`
+- API Contract worker done → set `api_contract_status` = `completed`
 
-### Step 4: HARD STOP — User Confirmation
+### Step 5: HARD STOP — User Confirmation
 
-Present the Feature Registry to user and wait for confirmation before proceeding:
+Present the Feature List to user and wait for confirmation before proceeding:
 
 Display the full feature table:
 
@@ -346,13 +367,13 @@ Display the full feature table:
 ⚠️ **HARD STOP — WAIT FOR USER CONFIRMATION**
 
 ```
-DO NOT dispatch Feature Spec workers until user explicitly confirms the Feature Registry.
+DO NOT dispatch Feature Spec workers until user explicitly confirms the Feature List.
 Ask user:
 - Is the feature decomposition granularity appropriate?
 - Are Feature IDs, Types, and dependencies correct?
 - Any features to add, remove, or merge?
 
-IF user requests changes → update .checkpoints.json, then re-present.
+IF user requests changes → report error: Feature List is read-only (generated by PM Agent)
 ONLY after user confirms → update function_decomposition.passed = true.
 Then proceed to Phase 3.
 ```
@@ -380,7 +401,7 @@ When involving related business domains, read `{workspace_path}/knowledges/bizs/
 > 4. **DO NOT generate Feature Spec documents yourself.** Your role is to DISPATCH workers.
 > 5. **Phase 3a → 3b → 3c is STRICTLY SERIAL.** Each phase must complete before the next begins.
 > 6. **Intermediate artifacts are MANDATORY.** .feature-analysis.md must exist before Phase 3b.
-> 7. **Feature name is LOCKED after Phase 2 confirmation.** All Worker dispatch parameters MUST use the exact `feature_name` from `.checkpoints.json`. DO NOT derive, translate, or modify feature names at any point after the Feature Registry is confirmed.
+> 7. **Feature name is LOCKED after Phase 2 confirmation.** All Worker dispatch parameters MUST use the exact `feature_name` from `.checkpoints.json`. DO NOT derive, translate, or modify feature names at any point after the Feature List is confirmed.
 
 ---
 

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

@@ -546,6 +546,62 @@ No knowledge base exists. A lightweight feature inventory scan is triggered to d
 > The scope was already determined by the matcher in Step 1.
 > Asking "do you want to continue?" mid-way is FORBIDDEN.
 >
+> **Path B Step 3.5: Generate Graph Data**
+>
+> After ALL feature analysis Workers in Step 3 complete, dispatch Graph Workers for each completed analysis task:
+>
+> **For each completed API analysis task** (analyzer_skill = speccrew-knowledge-bizs-api-analyze):
+> - Dispatch Worker with skill: `speccrew-knowledge-bizs-api-graph`
+> - Input: the generated analysis document from Step 3
+> - Output: `.graph.json` file with nodes (api, service, table, dto) and edges (operates, invokes, references, depends-on, maps-to)
+>
+> **Agent Tool Invocation for API Graph Worker**:
+> ```
+> Use the Agent tool to invoke speccrew-task-worker:
+> - agent: speccrew-task-worker
+> - task: Execute speccrew-knowledge-bizs-api-graph for feature "{task.fileName}"
+> - context:
+>     skill: speccrew-knowledge-bizs-api-graph
+>     api_analysis_path: {workspace_path}/{task.documentPath}
+>     platform_id: {task.platform_id}
+>     output_dir: {sync_state_bizs_dir}/completed
+>     module: {task.module}
+>     fileName: {task.fileName}
+>     sourcePath: {task.sourcePath}
+>     sourceFile: features-{task.platform_id}.json
+>     language: {language}
+>     subpath: {task.subpath}
+> ```
+>
+> **For each completed UI analysis task** (analyzer_skill = speccrew-knowledge-bizs-ui-analyze):
+> - Dispatch Worker with skill: `speccrew-knowledge-bizs-ui-graph`
+> - Input: the generated UI analysis document from Step 3
+> - Output: `.graph.json` file with UI component nodes and relationships
+>
+> **Agent Tool Invocation for UI Graph Worker**:
+> ```
+> Use the Agent tool to invoke speccrew-task-worker:
+> - agent: speccrew-task-worker
+> - task: Execute speccrew-knowledge-bizs-ui-graph for feature "{task.fileName}"
+> - context:
+>     skill: speccrew-knowledge-bizs-ui-graph
+>     fileName: {task.fileName}
+>     sourcePath: {source_path}/{task.sourcePath}
+>     documentPath: {workspace_path}/{task.documentPath}
+>     module: {task.module}
+>     platform_type: {task.platform_type}
+>     platform_subtype: {task.platform_subtype}
+>     completed_dir: {sync_state_bizs_dir}/completed
+>     sourceFile: features-{task.platform_id}.json
+>     status: success
+>     analysisNotes: "Graph data generation from UI analysis"
+>     language: {language}
+> ```
+>
+> **Dispatch Strategy**: Same batch parallel strategy as Step 3 (max 5 Workers per batch).
+>
+> ⚠️ Step 3.5 MUST complete before Step 4 (Module Summaries). Graph data enriches module summaries.
+>
 > **Path B Step 4: Generate Module Summaries**
 > For each matched module, dispatch Worker with `speccrew-knowledge-module-summarize` skill:
 > ```
@@ -1187,10 +1243,13 @@ From the Skill's Step 12c output, collect:
 - `module_design_file`: Path to `.module-design.md`
 - `output_dir`: Directory for Sub-PRD files (same as Master PRD directory)
 - Module list with context for each module:
+  - `module_id`: Unique identifier for the module (used for feature list indexing)
   - `module_name`, `module_key`, `module_scope`, `module_entities`
-  - `module_user_stories`, `module_requirements`, `module_features`
+  - `module_user_stories`, `module_requirements`
   - `module_dependencies`
 
+> **Note**: The dispatch plan now contains only scheduling fields (module metadata, dependencies). Feature data (`module_features`) is stored separately in `.prd-feature-list.json`, which will be used by FD Agent for Feature Registry initialization.
+
 **Store these values as workflow context variables for use in Worker dispatches.**
 
 ---
@@ -1327,6 +1386,7 @@ Use the Agent tool to invoke speccrew-task-worker:
 - task: Generate Sub-PRD for module "{module_name}"
 - context:
     skill: speccrew-pm-sub-prd-generate
+    module_id: {module_id}
     module_name: {module_name}
     module_key: {module_key}
     module_scope: {module_scope}
@@ -1349,13 +1409,14 @@ Use the Agent tool to invoke speccrew-task-worker:
 | Parameter | Source | Description |
 |-----------|--------|-------------|
 | `skill` | Fixed | `speccrew-pm-sub-prd-generate` |
+| `module_id` | Dispatch Plan | Unique identifier for the module (used for feature list indexing) |
 | `module_name` | Dispatch Plan | Display name (e.g., "Customer Management") |
 | `module_key` | Dispatch Plan | Identifier for file naming (e.g., "customer") |
 | `module_scope` | Dispatch Plan | What this module covers |
 | `module_entities` | Dispatch Plan | Core business entities |
 | `module_user_stories` | Dispatch Plan | Module-specific user stories |
 | `module_requirements` | Dispatch Plan | Module-specific functional requirements (P0/P1/P2) |
-| `module_features` | Dispatch Plan | Feature Breakdown entries for this module |
+| `module_features` | Dispatch Plan | Feature Breakdown entries for this module (used by Sub-PRD Skill to generate content and write to feature list) |
 | `module_dependencies` | Dispatch Plan | Dependencies on other modules |
 | `master_prd_path` | Dispatch Plan | Path to the Master PRD |
 | `clarification_file` | Step 5.1 | Path to `.clarification-summary.md` |
@@ -1516,6 +1577,41 @@ node "{update_progress_script}" write-checkpoint `
   --status passed
 ```
 
+**Step 5.5.5: Verify Feature List Completeness**
+
+After all Sub-PRDs are generated, verify that `.prd-feature-list.json` contains complete feature data:
+
+1. **Read feature list file**:
+   ```bash
+   Get-Content "{iterations_dir}/{iteration}/01.product-requirement/.prd-feature-list.json" | ConvertFrom-Json
+   ```
+
+2. **Verify structure**:
+   - File exists and is valid JSON
+   - Contains `modules` array
+   - Each module has `module_id` and `features` array
+
+3. **Verify completeness**:
+   - Module count in feature list should equal `totalModules` from dispatch plan
+   - If any module is missing, display WARNING:
+   ```
+   ⚠️ WARNING: Feature list incomplete
+   ├── Expected modules: {expected_count}
+   ├── Found modules: {actual_count}
+   └── Missing modules: {missing_module_ids}
+
+   Feature list will be used by FD Agent for Feature Registry initialization.
+   Missing modules may cause errors in Feature Design phase.
+   ```
+
+4. **If verification passes**:
+   ```
+   ✅ Feature list verification passed
+   ├── Modules: {count}
+   ├── Total features: {total_features}
+   └── Ready for Feature Design phase
+   ```
+
 **Before proceeding to Phase 6, verify:**
 - [ ] All workers were dispatched via speccrew-task-worker (one Worker per module)
 - [ ] No Sub-PRD was generated by PM Agent directly
@@ -1761,12 +1857,13 @@ After PRD verification passes and user has confirmed, delete intermediate proces
 - `{iteration_path}/01.product-requirement/.checkpoints.json` (execution checkpoint tracking)
 - `{iteration_path}/01.product-requirement/.prd-generation-report.md` (intermediate generation report)
 - `{iteration_path}/01.product-requirement/.prd-completion-report.md` (completion report)
-- `{iteration_path}/01.product-requirement/.sub-prd-dispatch-plan.json` (Sub-PRD dispatch plan)
+- `{iteration_path}/01.product-requirement/.sub-prd-dispatch-plan.json` (dispatch plan — no longer needed after dispatch complete)
 
 **Files to KEEP (referenced by downstream phases):**
 - Master PRD and all Sub-PRD documents (`*-prd.md`, `*-sub-*.md`)
 - `.clarification-summary.md`
 - `.module-design.md`
+- `.prd-feature-list.json` (Feature list for Feature Design phase — used by FD Agent to load Feature Registry)
 - `.clarification-questions-round-*.md` (optional, for reference)
 
 ⚠️ **Only execute cleanup AFTER:**

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

@@ -30,6 +30,7 @@ tools: Read, Write, Glob, Grep
 
 | Parameter | Required | Description |
 |-----------|----------|-------------|
+| module_id | Yes | Module ID for feature registry (e.g., "M1", "M2") |
 | module_name | Yes | Human-readable module name (e.g., "Customer Management") |
 | module_key | Yes | Module identifier for file naming (e.g., "customer") |
 | module_scope | Yes | What this module covers |
@@ -188,3 +189,90 @@ IF verification fails:
   → Output: "❌ Sub-PRD verification failed: {reason}"
   → Attempt to fix the specific issue
 ```
+
+## Step 5: Write Module Features to Feature List
+
+> **Purpose:** Separate feature data from dispatch plan into dedicated `.prd-feature-list.json` file.
+> Each Sub-PRD Worker writes its module's features upon completion.
+
+### 5.1 Determine Feature List File Path
+
+```
+feature_list_path = dirname(output_path) + '/.prd-feature-list.json'
+```
+
+This is the same directory containing `.sub-prd-dispatch-plan.json`.
+
+### 5.2 Read or Initialize Feature List File
+
+```javascript
+IF file exists at feature_list_path:
+  feature_list = read_json(feature_list_path)
+ELSE:
+  feature_list = {
+    "created_at": "{timestamp from update-progress.js}",
+    "updated_at": "{timestamp from update-progress.js}",
+    "modules": []
+  }
+```
+
+> ⚠️ **Timestamp constraint:** Use `node scripts/update-progress.js write-checkpoint` or similar script to get accurate timestamps. DO NOT fabricate timestamps.
+
+### 5.3 Build Current Module Feature Entry
+
+Construct the module entry from input parameters:
+
+```json
+{
+  "module_id": "{module_id}",
+  "module_name": "{module_name}",
+  "module_key": "{module_key}",
+  "source_prd": "{feature_name}-sub-{module_key}.md",
+  "feature_count": {module_features.length},
+  "features": [
+    // Map each item in module_features to:
+    {
+      "feature_id": "{item.feature_id}",
+      "feature_name": "{item.feature_name}",
+      "type": "{item.type}",
+      "priority": "{item.priority}",
+      "sub_features": "{item.sub_features}",
+      "description": "{item.description}"
+    }
+  ]
+}
+```
+
+### 5.4 Merge into Feature List
+
+```javascript
+existing_index = find_index(feature_list.modules, m => m.module_key === module_key)
+
+IF existing_index >= 0:
+  // Retry scenario: replace existing entry
+  feature_list.modules[existing_index] = module_entry
+ELSE:
+  // New module: append
+  feature_list.modules.push(module_entry)
+
+// Update timestamp
+feature_list.updated_at = "{current timestamp}"
+```
+
+### 5.5 Write Feature List File
+
+Write the updated `feature_list` to `{feature_list_path}` using `create_file`.
+
+### 5.6 Report Result
+
+```
+IF write succeeds:
+  → Output: "✅ Feature list updated: {feature_count} features for module {module_id}"
+IF write fails:
+  → Output: "⚠️ Feature list write failed: {error}"
+  → Continue without blocking Sub-PRD completion
+```
+
+---
+
+> **Note:** Step 5 is a pure incremental operation. Failure here should NOT affect the Sub-PRD file generation result. The primary deliverable is the Sub-PRD document itself.

package/package.json

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

package/.speccrew/skills/speccrew-fd-feature-registry-init/SKILL.md

@@ -1,249 +0,0 @@
----
-name: speccrew-fd-feature-registry-init
-description: Extract Feature Breakdown from Master PRD and Sub-PRD files to generate Feature Registry. Scans PRD directory, parses Feature Breakdown tables from all Sub-PRDs, and outputs .feature-registry.json with module-grouped features and summary statistics.
-tools: Read, Write, Glob
----
-
-# Feature Registry Initialization
-
-Extract Feature Breakdown from Master PRD and Sub-PRD files to generate a centralized Feature Registry. This Skill discovers all PRD files, parses Feature Breakdown tables, and produces a structured registry with summary statistics.
-
-## Trigger Scenarios
-
-- "Initialize feature registry from PRDs"
-- "Extract features from all Sub-PRDs"
-- "Build feature registry for the project"
-- "Generate feature breakdown summary"
-
-## Input Parameters
-
-| Parameter | Type | Description | Required |
-|-----------|------|-------------|----------|
-| `prd_dir` | string | Path to PRD documents directory (contains Master PRD and all Sub-PRDs) | **Yes** |
-| `workspace_path` | string | Workspace root path for reading techs-manifest.json | **Yes** |
-| `language` | string | Target language for output content | **Yes** |
-
-## Output
-
-- **JSON File**: `{prd_dir}/.feature-registry.json` - Structured feature registry
-- **Summary**: Markdown table with module statistics and feature distribution
-
----
-
-## Workflow
-
-### Step 0: Read Template / Validate Inputs
-
-1. **Validate prd_dir exists**
-   - Check if `{prd_dir}` directory exists
-   - If not found, report error and stop
-
-2. **Validate Sub-PRD files exist**
-   - Scan for files matching `*-sub-*.md` pattern in `{prd_dir}`
-   - If no Sub-PRD files found, report error and stop
-
-3. **Output**: "Step 0 Status: ✅ COMPLETED - Found {sub_prd_count} Sub-PRD files"
-
-### Step 1: Discover PRD Files
-
-1. **Scan PRD Directory**
-   - Find **Master PRD**: files matching `*-master-prd.md`
-   - Find **Sub-PRDs**: files matching `*-sub-*.md`
-   - Record file paths and names
-
-2. **Discover Frontend Platforms**
-   - Read `{workspace_path}/knowledges/techs/techs-manifest.json`
-   - Extract platform list from the manifest
-   - Platforms typically include: `web-vue`, `mobile-uniapp`, etc.
-
-3. **Output**: 
-   - "Step 1 Status: ✅ COMPLETED - Found 1 Master PRD, {count} Sub-PRDs"
-   - "Frontend Platforms: {platform_list}"
-
-### Step 2: Extract Feature Breakdown from Each Sub-PRD
-
-For each Sub-PRD file:
-
-1. **Read Sub-PRD Content**
-   - Parse the markdown file
-
-2. **Locate Section 3.4 "Feature Breakdown"**
-   - Find the section header (may be in different languages based on `language`)
-   - Common patterns: "3.4 Feature Breakdown", "3.4 功能分解", etc.
-
-3. **Parse Feature Table**
-   - Extract table rows containing feature information
-   - For each feature, extract:
-
-| Field | Description | Example |
-|-------|-------------|---------|
-| `feature_id` | Feature identifier | F-SYS-01, F-CRM-05 |
-| `feature_name` | Human-readable feature name | User Management, Order List |
-| `type` | Feature type | User Interaction / Backend Process |
-| `priority` | Priority level | P0 / P1 / P2 |
-| `sub_features` | List of sub-feature IDs | ["M1-F01-01", "M1-F01-02"] |
-| `description` | Brief description | Manage system users and permissions |
-| `source_prd` | Source file name | litemes-sub-system-management.md |
-| `module_key` | Module identifier | system-management |
-
-4. **Extract Module Information**
-   - Derive `module_id` from PRD (e.g., M1, M2)
-   - Derive `module_name` from PRD header or content
-   - Map to `module_key` (kebab-case identifier)
-
-5. **Output**: "Step 2 Status: ✅ COMPLETED - Extracted {feature_count} features from {prd_name}"
-
-### Step 3: Build Feature Registry
-
-1. **Merge All Features**
-   - Combine features from all Sub-PRDs into a single collection
-   - Group features by module
-
-2. **Calculate Summary Statistics**
-
-| Statistic | Calculation |
-|-----------|-------------|
-| `total_modules` | Count of unique modules |
-| `total_features` | Total count of all features |
-| `by_priority` | Count by priority (P0, P1, P2) |
-| `by_type` | Count by type (User Interaction, Backend Process) |
-| `frontend_platforms` | List from techs-manifest.json |
-
-3. **Organize Registry Structure**
-   - Group features under their respective modules
-   - Sort modules by module_id (M1, M2, M3...)
-   - Sort features by feature_id within each module
-
-4. **Output**: "Step 3 Status: ✅ COMPLETED - Registry contains {total_features} features across {total_modules} modules"
-
-### Step 4: Write Output Files
-
-1. **Write `.feature-registry.json`**
-
-Output path: `{prd_dir}/.feature-registry.json`
-
-Structure:
-```json
-{
-  "created_at": "2026-01-15T10:30:00Z",
-  "summary": {
-    "total_modules": 8,
-    "total_features": 42,
-    "by_priority": {
-      "P0": 35,
-      "P1": 5,
-      "P2": 2
-    },
-    "by_type": {
-      "User Interaction": 30,
-      "Backend Process": 12
-    },
-    "frontend_platforms": ["web-vue", "mobile-uniapp"]
-  },
-  "modules": [
-    {
-      "module_id": "M1",
-      "module_name": "System Management",
-      "module_key": "system-management",
-      "source_prd": "litemes-sub-system-management.md",
-      "features": [
-        {
-          "feature_id": "F-SYS-01",
-          "feature_name": "User Management",
-          "type": "User Interaction",
-          "priority": "P0",
-          "sub_features": ["M1-F01-01", "M1-F01-02"],
-          "description": "Manage system users and permissions"
-        }
-      ]
-    }
-  ]
-}
-```
-
-2. **Output**: "Step 4 Status: ✅ COMPLETED - Written .feature-registry.json"
-
-### Step 5: Output Summary
-
-Generate and output a Markdown summary table for Agent display:
-
-```markdown
-## Feature Registry Summary
-
-| Module | Features | P0 | P1 | P2 | Types |
-|--------|----------|----|----|----|-------|
-| M1 System Management | 4 | 4 | 0 | 0 | UI: 4, Backend: 0 |
-| M2 User Center | 6 | 5 | 1 | 0 | UI: 5, Backend: 1 |
-| ... | ... | ... | ... | ... | ... |
-| **Total** | **42** | **35** | **5** | **2** | **UI: 30, Backend: 12** |
-
-**Frontend Platforms:** web-vue, mobile-uniapp
-
-**Registry File:** `{prd_dir}/.feature-registry.json`
-```
-
-**Output**: "Step 5 Status: ✅ COMPLETED - Summary generated"
-
----
-
-## Task Completion Report
-
-When the task is complete, report:
-
-```json
-{
-  "status": "success",
-  "skill": "speccrew-fd-feature-registry-init",
-  "result": {
-    "registry_file": "{prd_dir}/.feature-registry.json",
-    "total_modules": 8,
-    "total_features": 42,
-    "by_priority": {
-      "P0": 35,
-      "P1": 5,
-      "P2": 2
-    },
-    "by_type": {
-      "User Interaction": 30,
-      "Backend Process": 12
-    }
-  },
-  "message": "Feature registry initialized successfully"
-}
-```
-
----
-
-## Constraints
-
-1. **READ-ONLY on PRDs**: Do not modify any PRD files
-2. **JSON Output**: Registry must be valid JSON
-3. **Feature ID Uniqueness**: Each feature_id should be unique across all modules
-4. **Module Grouping**: Features must be grouped by their source module
-5. **Priority Validation**: Only accept P0, P1, P2 as valid priority values
-6. **Type Validation**: Only accept "User Interaction" or "Backend Process" as valid types
-
-## Error Handling
-
-| Scenario | Action |
-|----------|--------|
-| prd_dir not found | Report error, stop execution |
-| No Sub-PRD files found | Report error, stop execution |
-| Master PRD not found | Log warning, continue with Sub-PRDs only |
-| techs-manifest.json not found | Use empty platform list, log warning |
-| Feature table not found in Sub-PRD | Skip that PRD, log warning |
-| Invalid feature data | Skip invalid row, log warning |
-| Duplicate feature_id | Keep first occurrence, log warning |
-
-## Checklist
-
-- [ ] Step 0: Validated prd_dir exists
-- [ ] Step 0: Found at least one Sub-PRD file
-- [ ] Step 1: Discovered Master PRD and all Sub-PRDs
-- [ ] Step 1: Read techs-manifest.json for frontend platforms
-- [ ] Step 2: All Sub-PRD files scanned
-- [ ] Step 2: Feature Breakdown tables parsed from each Sub-PRD
-- [ ] Step 3: Features merged and grouped by module
-- [ ] Step 3: Summary statistics calculated (total, by_priority, by_type)
-- [ ] Step 4: `.feature-registry.json` written to correct path
-- [ ] Step 5: Summary table generated and output