speccrew 0.2.7 → 0.3.0

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

@@ -102,14 +102,59 @@ Use Glob to find relevant documents in the current iteration:
 - Feature Spec pattern: `speccrew-workspace/iterations/{current}/02.feature-design/*-feature-spec.md`
 - API Contract pattern: `speccrew-workspace/iterations/{current}/02.feature-design/*-api-contract.md`
 
-### 1.2 Check Existing System Design Documents
+**文件命名格式说明**:
+- **新格式**（细粒度 Feature）: 文件名以 Feature ID 开头，格式为 `{feature-id}-{feature-name}-feature-spec.md`
+  - 示例: `F-CRM-01-customer-list-feature-spec.md`
+  - Feature ID 格式: `F-{MODULE}-{NN}`（如 `F-CRM-01`）
+- **旧格式**（向后兼容）: 文件名以模块名开头，格式为 `{module-name}-feature-spec.md`
+  - 示例: `crm-feature-spec.md`
+  - 无 Feature ID 前缀
+
+**格式检测**: 文件名以 `F-` 开头 → 新格式；否则 → 旧格式
+
+### 1.2 Parse Feature Registry
+
+从发现的文件中提取 Feature 信息并建立 Registry:
+
+```javascript
+// Feature Registry 结构
+{
+  "F-CRM-01": {
+    "feature_id": "F-CRM-01",
+    "feature_name": "customer-list",
+    "feature_spec_path": ".../02.feature-design/F-CRM-01-customer-list-feature-spec.md",
+    "api_contract_path": ".../02.feature-design/F-CRM-01-customer-list-api-contract.md"
+  },
+  "crm": {  // 旧格式，使用模块名作为标识
+    "feature_id": null,
+    "feature_name": "crm",
+    "feature_spec_path": ".../02.feature-design/crm-feature-spec.md",
+    "api_contract_path": ".../02.feature-design/crm-api-contract.md"
+  }
+}
+```
+
+**解析逻辑**:
+1. 从文件名提取 Feature ID（如果存在）:
+   - 正则: `^(F-[A-Z]+-\d+)-(.+)-feature-spec\.md$`
+   - Group 1: Feature ID（如 `F-CRM-01`）
+   - Group 2: Feature Name（如 `customer-list`）
+2. 旧格式（无 Feature ID）:
+   - 使用模块名作为 feature_name
+   - feature_id 设为 null
+3. 匹配 Feature Spec 和 API Contract（通过文件名前缀）
+
+### 1.3 Check Existing System Design Documents
 
 Check if system design documents already exist:
 - Check path: `speccrew-workspace/iterations/{current}/03.system-design/`
 
-### 1.3 Present Design Scope to User
+### 1.4 Present Design Scope to User
 
-Present the identified documents and design scope to user for confirmation before proceeding.
+Present the identified documents and design scope to user for confirmation before proceeding:
+- 列出所有发现的 Feature（新格式显示 Feature ID）
+- 显示每个 Feature 对应的 Platform 数量
+- 显示预计生成的 Worker 任务数（Feature 数量 × Platform 数量）
 
 ## Phase 2: Knowledge Loading
 
@@ -164,12 +209,21 @@ Create the top-level overview at:
 ### Template Structure
 
 ```markdown
-# System Design Overview - {Feature Name}
+# System Design Overview - {Iteration Name}
 
 ## 1. Design Scope
-- Feature Spec Reference: [link]
-- API Contract Reference: [link]
-- Platforms: {list from techs-manifest}
+- **Iteration**: {iteration_number}-{iteration_type}-{iteration_name}
+- **Platforms**: {list from techs-manifest}
+- **Features**: {count} features discovered
+
+### 1.1 Feature List
+| Feature ID | Feature Name | Feature Spec | API Contract |
+|------------|--------------|--------------|--------------|
+| F-CRM-01 | customer-list | [link] | [link] |
+| F-CRM-02 | customer-detail | [link] | [link] |
+| ... | ... | ... | ... |
+
+> **旧格式兼容**: 如果文件使用旧格式（无 Feature ID），Feature ID 列显示为 `-`，使用模块名作为 Feature Name
 
 ## 2. Technology Decisions
 - Framework evaluation results (from Phase 3)
@@ -177,16 +231,41 @@ Create the top-level overview at:
 - Version constraints
 
 ## 3. Platform Design Index
-| Platform | Platform ID | Skill | Design Directory | Status |
-|----------|-------------|-------|-----------------|--------|
-
-## 4. Cross-Platform Concerns
+| Feature ID | Feature Name | Platform | Platform ID | Skill | Design Directory | Status |
+|------------|--------------|----------|-------------|-------|------------------|--------|
+| F-CRM-01 | customer-list | Web Frontend | web-vue | speccrew-sd-frontend | web-vue/F-CRM-01-customer-list-design.md | pending |
+| F-CRM-01 | customer-list | Backend | backend-spring | speccrew-sd-backend | backend-spring/F-CRM-01-customer-list-design.md | pending |
+| F-CRM-02 | customer-detail | Web Frontend | web-vue | speccrew-sd-frontend | web-vue/F-CRM-02-customer-detail-design.md | pending |
+| ... | ... | ... | ... | ... | ... | ... |
+
+> **说明**: 
+> - 新格式：Design Directory 包含 `{feature-id}-{feature-name}`（如 `F-CRM-01-customer-list-design.md`）
+> - 旧格式：Design Directory 使用 `{module}-design.md`
+
+## 4. Feature Summary (Optional)
+
+当 Feature 数量较多（>5）时，添加此小节提供汇总视图：
+
+### 4.1 Feature by Module
+| Module | Feature Count | Feature IDs |
+|--------|---------------|-------------|
+| CRM | 3 | F-CRM-01, F-CRM-02, F-CRM-03 |
+| ORDER | 2 | F-ORDER-01, F-ORDER-02 |
+
+### 4.2 Feature Type Distribution
+| Type | Count | Features |
+|------|-------|----------|
+| List/Query | 2 | F-CRM-01, F-ORDER-01 |
+| Detail/View | 2 | F-CRM-02, F-ORDER-02 |
+| Create/Update | 1 | F-CRM-03 |
+
+## 5. Cross-Platform Concerns
 - Shared data structures
 - Cross-platform API contracts
 - Authentication/authorization strategy
 - Error handling conventions
 
-## 5. Design Constraints
+## 6. Design Constraints
 - API Contract is READ-ONLY — do not modify
 - All pseudo-code must use actual framework syntax from techs knowledge
 - Each module design document maps 1:1 to a Feature Spec function
@@ -210,10 +289,15 @@ Before dispatching, create or update dispatch tracking:
 
 1. **Initialize dispatch progress file with task list**:
    ```bash
-   node speccrew-workspace/scripts/update-progress.js init --file speccrew-workspace/iterations/{current}/03.system-design/DISPATCH-PROGRESS.json --stage 03_system_design --tasks '[{"id":"sd-{platform_id}-{feature_name}","platform":"{platform_id}","feature":"{feature_name}","skill":"speccrew-sd-{type}","status":"pending"}]'
+   node speccrew-workspace/scripts/update-progress.js init --file speccrew-workspace/iterations/{current}/03.system-design/DISPATCH-PROGRESS.json --stage 03_system_design --tasks '[{"id":"sd-{platform_id}-{feature_id}","platform":"{platform_id}","feature_id":"{feature_id}","feature_name":"{feature_name}","skill":"speccrew-sd-{type}","status":"pending"}]'
    ```
    Or use `--tasks-file` to load from a JSON file.
 
+   **Task ID 格式更新**:
+   - 旧格式: `sd-{platform}-{feature}`（如 `sd-web-vue-customer-list`）
+   - **新格式**: `sd-{platform}-{feature-id}`（如 `sd-web-vue-F-CRM-01`）
+   - 旧格式兼容: 如果无 Feature ID，使用 feature_name（如 `sd-web-vue-crm`）
+
 2. **Check existing progress** (from Step 0.3) — skip `completed` tasks
 3. **Update status** to `in_progress` for tasks being dispatched:
    ```bash
@@ -232,10 +316,12 @@ When there is only one Feature Spec and one platform:
 2. Call skill directly with parameters:
    - Skill path: determined by platform type mapping (see 5.1)
    - Pass context:
-     - `task_id`: Task identifier for progress tracking
+     - `task_id`: Task identifier for progress tracking（格式: `sd-{platform_id}-{feature_id}` 或 `sd-{platform_id}-{feature_name}`）
+     - `feature_id`: Feature ID（新格式如 `F-CRM-01`，旧格式为 null）
+     - `feature_name`: Feature Name（如 `customer-list` 或 `crm`）
      - `platform_id`: Platform identifier from techs-manifest
-     - `feature_spec_path`: Path to Feature Spec document
-     - `api_contract_path`: Path to API Contract document
+     - `feature_spec_path`: Path to Feature Spec document（从 Feature Registry 获取的实际路径）
+     - `api_contract_path`: Path to API Contract document（从 Feature Registry 获取的实际路径）
      - `techs_paths`: Relevant techs knowledge paths
      - `framework_decisions`: Framework decisions from Phase 3
 
@@ -265,10 +351,12 @@ When multiple Feature Specs and/or multiple platforms exist, create a matrix of
 Each worker receives:
 - `skill_path`: {ide_skills_dir}/{skill_name}/SKILL.md (per-platform design skill based on platform type, see 5.1)
 - `context`:
-  - `task_id`: Unique task identifier (e.g., `sd-web-vue-feature-a`)
+  - `task_id`: Unique task identifier（格式: `sd-{platform_id}-{feature_id}`，如 `sd-web-vue-F-CRM-01`）
+  - `feature_id`: Feature ID（新格式如 `F-CRM-01`，旧格式为 null）
+  - `feature_name`: Feature Name（如 `customer-list`）
   - `platform_id`: Platform identifier from techs-manifest
-  - `feature_spec_path`: Path to ONE Feature Spec document (not all)
-  - `api_contract_path`: API Contract document path
+  - `feature_spec_path`: Path to ONE Feature Spec document (not all, 从 Feature Registry 获取)
+  - `api_contract_path`: API Contract document path (从 Feature Registry 获取)
   - `techs_knowledge_paths`: Techs knowledge paths for this platform
   - `framework_decisions`: Framework decisions from Phase 3
   - `output_base_path`: Path to `03.system-design/` directory
@@ -279,12 +367,12 @@ node speccrew-workspace/scripts/update-progress.js update-task --file speccrew-w
 ```
 
 **Parallel execution example** (2 features × 3 platforms = 6 workers):
-- Worker 1: speccrew-sd-frontend for Feature A on web-vue → 03.system-design/web-vue/
-- Worker 2: speccrew-sd-backend for Feature A on backend-spring → 03.system-design/backend-spring/
-- Worker 3: speccrew-sd-mobile for Feature A on mobile-uniapp → 03.system-design/mobile-uniapp/
-- Worker 4: speccrew-sd-frontend for Feature B on web-vue → 03.system-design/web-vue/
-- Worker 5: speccrew-sd-backend for Feature B on backend-spring → 03.system-design/backend-spring/
-- Worker 6: speccrew-sd-mobile for Feature B on mobile-uniapp → 03.system-design/mobile-uniapp/
+- Worker 1: speccrew-sd-frontend for F-CRM-01 (customer-list) on web-vue → 03.system-design/web-vue/F-CRM-01-customer-list-design.md
+- Worker 2: speccrew-sd-backend for F-CRM-01 (customer-list) on backend-spring → 03.system-design/backend-spring/F-CRM-01-customer-list-design.md
+- Worker 3: speccrew-sd-mobile for F-CRM-01 (customer-list) on mobile-uniapp → 03.system-design/mobile-uniapp/F-CRM-01-customer-list-design.md
+- Worker 4: speccrew-sd-frontend for F-CRM-02 (customer-detail) on web-vue → 03.system-design/web-vue/F-CRM-02-customer-detail-design.md
+- Worker 5: speccrew-sd-backend for F-CRM-02 (customer-detail) on backend-spring → 03.system-design/backend-spring/F-CRM-02-customer-detail-design.md
+- Worker 6: speccrew-sd-mobile for F-CRM-02 (customer-detail) on mobile-uniapp → 03.system-design/mobile-uniapp/F-CRM-02-customer-detail-design.md
 
 All workers execute simultaneously to maximize efficiency.
 
@@ -307,12 +395,59 @@ Wait for all workers to complete before proceeding to Phase 6.
 
 After all platform designs are complete:
 
-1. Present summary of all generated documents
-2. List all design documents with paths
-3. Highlight cross-platform integration points
-4. Request user confirmation
+1. **Present summary by Feature ID**:
+   ```
+   Feature F-CRM-01 (customer-list):
+   ├── web-vue/F-CRM-01-customer-list-design.md [SUCCESS]
+   ├── backend-spring/F-CRM-01-customer-list-design.md [SUCCESS]
+   └── mobile-uniapp/F-CRM-01-customer-list-design.md [FAILED]
+   
+   Feature F-CRM-02 (customer-detail):
+   ├── web-vue/F-CRM-02-customer-detail-design.md [SUCCESS]
+   ├── backend-spring/F-CRM-02-customer-detail-design.md [SUCCESS]
+   └── mobile-uniapp/F-CRM-02-customer-detail-design.md [SUCCESS]
+   ```
+
+2. **Summary statistics**:
+   - Total Features: {count}
+   - Total Platforms: {count}
+   - Total Tasks: {count}
+   - Completed: {count}
+   - Failed: {count}
+
+3. **List all design documents with paths**
+4. **Highlight cross-platform integration points**
+5. **Request user confirmation**
+
+### 6.1 DISPATCH-PROGRESS.json Task Entry Format
+
+每个 task entry 包含以下字段:
+```json
+{
+  "id": "sd-web-vue-F-CRM-01",
+  "platform": "web-vue",
+  "feature_id": "F-CRM-01",
+  "feature_name": "customer-list",
+  "skill": "speccrew-sd-frontend",
+  "status": "completed",
+  "output": "03.system-design/web-vue/F-CRM-01-customer-list-design.md"
+}
+```
+
+旧格式兼容（无 Feature ID）:
+```json
+{
+  "id": "sd-web-vue-crm",
+  "platform": "web-vue",
+  "feature_id": null,
+  "feature_name": "crm",
+  "skill": "speccrew-sd-frontend",
+  "status": "completed",
+  "output": "03.system-design/web-vue/crm-design.md"
+}
+```
 
-### 6.1 Update Checkpoints on Confirmation
+### 6.2 Update Checkpoints on Confirmation
 
 After user confirms:
 
@@ -336,7 +471,76 @@ After user confirms:
 |-------------|------|----------|
 | Design Overview | `speccrew-workspace/iterations/{number}-{type}-{name}/03.system-design/DESIGN-OVERVIEW.md` | Inline (see Phase 4) |
 | Platform Index | `speccrew-workspace/iterations/{number}-{type}-{name}/03.system-design/{platform_id}/INDEX.md` | `speccrew-sd-frontend/templates/INDEX-TEMPLATE.md`, `speccrew-sd-backend/templates/INDEX-TEMPLATE.md`, `speccrew-sd-mobile/templates/INDEX-TEMPLATE.md`, or `speccrew-sd-desktop/templates/INDEX-TEMPLATE.md` |
-| Module Design | `speccrew-workspace/iterations/{number}-{type}-{name}/03.system-design/{platform_id}/{module}-design.md` | `speccrew-sd-frontend/templates/SD-FRONTEND-TEMPLATE.md`, `speccrew-sd-backend/templates/SD-BACKEND-TEMPLATE.md`, `speccrew-sd-mobile/templates/SD-MOBILE-TEMPLATE.md`, or `speccrew-sd-desktop/templates/SD-DESKTOP-TEMPLATE.md` |
+| Module Design | `speccrew-workspace/iterations/{number}-{type}-{name}/03.system-design/{platform_id}/{feature-id}-{feature-name}-design.md` | `speccrew-sd-frontend/templates/SD-FRONTEND-TEMPLATE.md`, `speccrew-sd-backend/templates/SD-BACKEND-TEMPLATE.md`, `speccrew-sd-mobile/templates/SD-MOBILE-TEMPLATE.md`, or `speccrew-sd-desktop/templates/SD-DESKTOP-TEMPLATE.md` |
+
+**输出文件命名规则**:
+
+1. **新格式**（有 Feature ID）:
+   - 格式: `{feature-id}-{feature-name}-design.md`
+   - 示例: `F-CRM-01-customer-list-design.md`
+   - 路径: `03.system-design/web-vue/F-CRM-01-customer-list-design.md`
+
+2. **旧格式兼容**（无 Feature ID）:
+   - 格式: `{module}-design.md`
+   - 示例: `crm-design.md`
+   - 路径: `03.system-design/web-vue/crm-design.md`
+
+**向后兼容逻辑**:
+- 如果 `feature_id` 存在 → 使用 `{feature-id}-{feature-name}-design.md`
+- 如果 `feature_id` 为 null（旧格式）→ 使用 `{module}-design.md`
+
+# Backward Compatibility
+
+本 Agent 支持新旧两种 Feature Spec 文件格式：
+
+## 新格式（细粒度 Feature）
+
+**文件名格式**:
+- Feature Spec: `{feature-id}-{feature-name}-feature-spec.md`
+- API Contract: `{feature-id}-{feature-name}-api-contract.md`
+
+**示例**:
+- `F-CRM-01-customer-list-feature-spec.md`
+- `F-CRM-01-customer-list-api-contract.md`
+
+**特征**:
+- 文件名以 `F-` 开头
+- 包含 Feature ID（如 `F-CRM-01`）
+- Feature ID 格式: `F-{MODULE}-{NN}`
+
+## 旧格式（模块级 Feature）
+
+**文件名格式**:
+- Feature Spec: `{module-name}-feature-spec.md`
+- API Contract: `{module-name}-api-contract.md`
+
+**示例**:
+- `crm-feature-spec.md`
+- `crm-api-contract.md`
+
+**特征**:
+- 文件名不以 `F-` 开头
+- 无 Feature ID
+- 使用模块名作为标识
+
+## 格式检测逻辑
+
+```
+文件名以 "F-" 开头 且匹配正则 ^F-[A-Z]+-\d+-
+  → 新格式，提取 Feature ID
+否则
+  → 旧格式，使用模块名
+```
+
+## 向后兼容处理
+
+| 场景 | 处理方式 |
+|------|----------|
+| Feature ID | 新格式: 提取 `F-{MODULE}-{NN}`；旧格式: null |
+| Feature Name | 新格式: 从文件名提取；旧格式: 模块名 |
+| Task ID | 新格式: `sd-{platform}-{feature-id}`；旧格式: `sd-{platform}-{feature_name}` |
+| 输出文件名 | 新格式: `{feature-id}-{feature-name}-design.md`；旧格式: `{module}-design.md` |
+| DESIGN-OVERVIEW | Feature ID 列显示 `-` 或实际 ID |
 
 # Constraints
 
@@ -347,6 +551,8 @@ After user confirms:
 - Ensure each module design maps to a Feature Spec function
 - Generate DESIGN-OVERVIEW.md before dispatching platform skills
 - Verify API Contract exists and reference it (read-only)
+- Parse Feature ID from filename when using new format
+- Maintain backward compatibility with old format
 
 **Must not do:**
 - Write actual source code (only pseudo-code in design docs)

package/.speccrew/agents/speccrew-system-developer.md

@@ -131,6 +131,14 @@ For each platform_id identified:
 - Read `03.system-design/{platform_id}/INDEX.md` to get module design list
 - Identify all module design documents to implement
 
+**Design Document Naming Convention** (supports both formats):
+- Legacy format: `{module}-design.md` (e.g., `crm-design.md`)
+- New format: `{feature-id}-{feature-name}-design.md` (e.g., `F-CRM-01-customer-list-design.md`)
+
+**Feature ID Extraction**:
+- From new format: extract `{feature-id}` from filename (e.g., `F-CRM-01` from `F-CRM-01-customer-list-design.md`)
+- From legacy format: use `{module}` as feature_id (e.g., `crm` from `crm-design.md`)
+
 ## Step 2: Load Techs Knowledge
 
 Load development-focused techs knowledge following the Developer section of agent-knowledge-map:
@@ -225,14 +233,17 @@ Before dispatching tasks, create or read dispatch progress file:
    ```json
    [
      {
-       "id": "dev-{platform_id}-{module-name}",
+       "id": "dev-{platform_id}-{feature-id}",
        "platform": "{platform_id}",
        "module": "{module_name}",
+       "feature_id": "{feature_id}",
        "skill": "{skill_name}",
        "status": "pending"
      }
    ]
    ```
+   
+   Note: `feature_id` is extracted from design doc filename. For new format `{feature-id}-{feature-name}-design.md`, use `{feature-id}`. For legacy format `{module}-design.md`, use `{module}` as feature_id.
 
 3. **Alternatively, pass tasks JSON directly**:
    ```bash
@@ -277,10 +288,29 @@ task_list = []
 for each platform_id:
   read INDEX.md → get module design file list
   for each module_design_doc:
+    // Extract feature_id from design doc filename
+    // New format: {feature-id}-{feature-name}-design.md → extract {feature-id}
+    // Legacy format: {module}-design.md → use {module} as feature_id
+    filename = module_design_doc.filename  // e.g., "F-CRM-01-customer-list-design.md" or "crm-design.md"
+    base_name = filename.replace("-design.md", "")  // e.g., "F-CRM-01-customer-list" or "crm"
+    
+    // Detect format: if base_name contains pattern like "F-XXX-NN", extract feature_id
+    if base_name matches pattern "^([A-Z]-[A-Z]+-\d+)" (e.g., "F-CRM-01"):
+      feature_id = matched group 1  // e.g., "F-CRM-01"
+      module_name = base_name  // full name for reference
+    else:
+      feature_id = base_name  // e.g., "crm"
+      module_name = base_name
+    
+    task_id = "dev-{platform_id}-{feature_id}"
+    
     task_list.append({
-      platform_id,
+      id: task_id,  // e.g., "dev-backend-spring-F-CRM-01" or "dev-backend-spring-crm"
+      platform: platform_id,
+      module: module_name,
+      feature_id: feature_id,
       skill_name: determined by platform prefix (see 4.1),
-      module_design_path: 03.system-design/{platform_id}/{module}-design.md,
+      module_design_path: 03.system-design/{platform_id}/{filename},
       techs_knowledge_paths: relevant techs knowledge for this platform,
       api_contract_path: API Contract path,
       iteration_path: current iteration directory
@@ -288,14 +318,17 @@ for each platform_id:
 ```
 
 **Example** (3 platforms × ~11 modules each = ~33 tasks):
-- Task 1: `speccrew-dev-backend` for `backend-spring/crm-design.md`
-- Task 2: `speccrew-dev-backend` for `backend-spring/member-design.md`
+- Task 1: `speccrew-dev-backend` for `backend-spring/F-CRM-01-customer-list-design.md` → task_id: `dev-backend-spring-F-CRM-01`
+- Task 2: `speccrew-dev-backend` for `backend-spring/F-MEM-02-member-profile-design.md` → task_id: `dev-backend-spring-F-MEM-02`
 - ...
-- Task 12: `speccrew-dev-frontend` for `web-vue/crm-design.md`
+- Task 12: `speccrew-dev-frontend` for `web-vue/F-CRM-01-customer-list-design.md` → task_id: `dev-web-vue-F-CRM-01`
 - ...
-- Task 23: `speccrew-dev-mobile` for `mobile-uniapp/crm-design.md`
+- Task 23: `speccrew-dev-mobile` for `mobile-uniapp/F-CRM-01-customer-list-design.md` → task_id: `dev-mobile-uniapp-F-CRM-01`
 - ...
 
+**Legacy format example**:
+- Task 1: `speccrew-dev-backend` for `backend-spring/crm-design.md` → task_id: `dev-backend-spring-crm`
+
 ### 4.2a Checkpoint: Task List Review
 
 **Present task list to user for confirmation**:
@@ -319,12 +352,12 @@ for each platform_id:
 >
 > **REQUIRED ACTION**: Dispatch `speccrew-task-worker` agents via Agent tool. Each worker independently calls the appropriate dev skill.
 
-**Max concurrent workers: 10**
+**Max concurrent workers: 6**
 
 Process `task_list` using a queue-based concurrency limit model. Each task runs in an independent `speccrew-task-worker` agent:
 
 ```
-MAX_CONCURRENT = 10
+MAX_CONCURRENT = 6
 pending = [...task_list]  // Only pending/failed tasks from DISPATCH-PROGRESS.json
 running = {}
 completed = []
@@ -343,6 +376,7 @@ while pending is not empty or running is not empty:
       - skill_path: {ide_skills_dir}/{task.skill_name}/SKILL.md
       - context:
         - platform_id: {task.platform_id}
+        - feature_id: {task.feature_id}  // Extracted from design doc filename
         - iteration_path: {task.iteration_path}
         - design_doc_path: {task.module_design_path}
         - api_contract_path: {task.api_contract_path}
@@ -377,7 +411,7 @@ while pending is not empty or running is not empty:
 **Dispatch rules:**
 - Each worker handles **one module** on **one platform** (not all modules)
 - Pass complete context including `design_doc_path`, `skill_name`, platform info, and `task_id`
-- Up to 10 workers execute simultaneously (concurrency limit)
+- Up to 6 workers execute simultaneously (concurrency limit)
 - Update DISPATCH-PROGRESS.json **before** dispatch (status → "in_progress")
 - After dev worker completes, mark as "in_review" (NOT "completed") and queue for review
 - Track all dispatched tasks: in_review / failed / pending counts

package/.speccrew/skills/speccrew-dev-backend/SKILL.md

@@ -10,6 +10,16 @@ tools: Bash, Edit, Write, Glob, Grep, Read
 - User asks "Start backend development", "Implement backend code"
 - System Developer Agent receives task to implement backend for a specific platform
 
+# Input Parameters
+
+| Parameter | Required | Type | Description |
+|-----------|----------|------|-------------|
+| `design_doc_path` | Yes | string | Path to a single module design document (passed by upstream system-developer agent) |
+| `platform_id` | Yes | string | Platform identifier (e.g., backend-spring, backend-nodejs) |
+| `task_id` | Yes | string | Task identifier from dispatch context |
+| `iteration_id` | No | string | Current iteration identifier for progress messages |
+| `output_dir` | No | string | Output directory for task record (default: auto-derived from iteration path) |
+
 # Workflow
 
 ## Absolute Constraints
@@ -249,7 +259,9 @@ If the skill fails at any step:
 | **Deviation Recording** | ALL deviations from design must be documented |
 | **Tech Debt Tracking** | Suboptimal solutions written to tech-debt/ directory |
 
-# Mermaid Diagram Requirements
+# Reference Guides
+
+## Mermaid Diagram Requirements
 
 When generating Mermaid diagrams, follow compatibility guidelines:
 
@@ -261,6 +273,8 @@ When generating Mermaid diagrams, follow compatibility guidelines:
 - No special characters in node text
 - Use standard `graph TB/LR` or `flowchart TD/LR` or `erDiagram` syntax only
 
+---
+
 # Checklist
 
 - [ ] All design documents and techs knowledge loaded before implementation

package/.speccrew/skills/speccrew-dev-desktop/SKILL.md

@@ -82,8 +82,27 @@ Fill each section with task checklist and design metadata extracted from input d
 
 ### 3.2 Desktop-Specific Task Types
 
+**Conditional Task Selection:**
+
+```
+IF task involves backend logic in main process THEN
+  → Create Main Process Module task
+IF task involves UI components in renderer THEN
+  → Create Renderer Page/Component task
+IF task involves process communication THEN
+  → Create IPC Channel Handler task + Preload Script task
+IF task involves native APIs THEN
+  → Create Native Integration task
+IF task involves menus or shortcuts THEN
+  → Create Menu/Shortcut task
+IF task involves auto-update THEN
+  → Create Auto-Update task
+IF task involves security configuration THEN
+  → Create Security Hardening task
+```
+
 | Task Type | Description | Example |
-|-----------|-------------|---------|
+|-----------|-------------|---------||
 | Main Process Module | Backend logic running in main process | Window manager, IPC handlers, native integrations |
 | Renderer Page/Component | UI components in renderer process | React/Vue components, pages, layouts |
 | IPC Channel Handler | Communication bridge between processes | `ipcMain.handle`, `#[tauri::command]` |
@@ -176,12 +195,7 @@ npx tsc --noEmit
 
 ### 5.4 Security Audit
 
-| Check | Method |
-|-------|--------|
-| Context Isolation | Verify `contextIsolation: true` in window config |
-| nodeIntegration | Verify `nodeIntegration: false` |
-| Preload Script | Verify all IPC goes through preload |
-| CSP | Check Content Security Policy headers |
+Perform security checks according to Security Audit Reference (see Reference Guides section).
 
 ### 5.5 Unit Tests
 
@@ -296,6 +310,21 @@ If the skill fails at any step:
 3. Native integrations working as expected
 4. No security concerns introduced
 
+---
+
+# Reference Guides
+
+## Security Audit Checklist
+
+| Check | Method |
+|-------|--------|
+| Context Isolation | Verify `contextIsolation: true` in window config |
+| nodeIntegration | Verify `nodeIntegration: false` |
+| Preload Script | Verify all IPC goes through preload |
+| CSP | Check Content Security Policy headers |
+
+---
+
 # Key Rules
 
 | Rule | Description |

package/.speccrew/skills/speccrew-dev-review/SKILL.md

@@ -21,7 +21,7 @@ tools: Read, Grep, Glob
 | `platform_id` | Yes | Platform identifier (backend-spring/web-vue/mobile-uniapp/desktop-tauri) |
 | `api_contract_path` | No | Path to API contract file for endpoint validation |
 | `task_id` | Yes | Task identifier from dispatch context |
-| `previous_review_path` | No | Path to previous review report for incremental review (skip already passed items) |
+| `previous_review_path` | No | Path to previous review report for incremental review |
 
 # Workflow
 
@@ -276,13 +276,22 @@ Compare Service implementation against design document:
 
 ### 6.1 Determine Review Result
 
-Based on findings, determine overall result:
+Based on findings, determine overall result using quantitative thresholds:
 
-| Result | Criteria |
-|--------|----------|
-| **PASS** | All files created, no ERROR-level issues |
-| **PARTIAL** | 50-99% files created, or has ERROR issues but not critical blockers |
-| **FAIL** | <50% files created, or has critical blockers preventing functionality |
+```
+IF completeness_pct == 100% AND error_count == 0 THEN
+  → Result = PASS
+IF completeness_pct >= 70% AND completeness_pct < 100% THEN
+  → Result = PARTIAL
+IF completeness_pct < 70% OR has_critical_blockers == true THEN
+  → Result = FAIL
+```
+
+| Result | Threshold Criteria |
+|--------|-------------------|
+| **PASS** | 100% files created, 0 ERROR-level issues |
+| **PARTIAL** | 70-99% files created, or has non-critical ERROR issues |
+| **FAIL** | <70% files created, or critical blockers present |
 
 ### 6.2 Write Review Report