speccrew 0.2.5 → 0.2.7

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

@@ -75,6 +75,22 @@ If WORKFLOW-PROGRESS.json does not exist:
 
 ---
 
+## Phase 0.5: IDE Directory Detection
+
+Before dispatching workers, detect the IDE directory for skill path resolution:
+
+1. **Check IDE directories in priority order**:
+   - `.qoder/` → `.cursor/` → `.claude/` → `.speccrew/`
+   
+2. **Use the first existing directory**:
+   - Set `ide_dir = detected IDE directory` (e.g., `.qoder`)
+   - Set `ide_skills_dir = {ide_dir}/skills`
+
+3. **Verify skills directory exists**:
+   - If `{ide_skills_dir}` does not exist, report error and stop
+
+---
+
 ## Phase 1: Preparation
 
 When user requests to start system design (and Phase 0 gates are passed):
@@ -247,7 +263,7 @@ When multiple Feature Specs and/or multiple platforms exist, create a matrix of
 | Feature Spec B | Worker 4 | Worker 5 | Worker 6 |
 
 Each worker receives:
-- `skill_name`: Per-platform design skill based on platform type (see 5.1)
+- `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`)
   - `platform_id`: Platform identifier from techs-manifest

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

@@ -89,6 +89,22 @@ If WORKFLOW-PROGRESS.json does not exist:
 - Do not block execution due to missing progress files
 - Log informational message: "Progress tracking not available (WORKFLOW-PROGRESS.json not found). Running in compatibility mode."
 
+## Phase 0.5: IDE Directory Detection
+
+Before dispatching workers, detect the IDE directory for skill path resolution:
+
+1. **Check IDE directories in priority order**:
+   - `.qoder/` → `.cursor/` → `.claude/` → `.speccrew/`
+   
+2. **Use the first existing directory**:
+   - Set `ide_dir = detected IDE directory` (e.g., `.qoder`)
+   - Set `ide_skills_dir = {ide_dir}/skills`
+
+3. **Verify skills directory exists**:
+   - If `{ide_skills_dir}` does not exist, report error and stop
+
+---
+
 ## Step 1: Read System Design
 
 When user requests to start development:
@@ -179,6 +195,16 @@ If any pre-check fails:
 
 ## Step 4: Dispatch Per-Module Dev Skills
 
+#### ⚠️ Stage 4 Directory Constraint
+
+All development outputs MUST go under `iterations/{iter}/04.development/`.
+- Task records: `04.development/{platform_id}/{module}-task.md`
+- Review reports: `04.development/{platform_id}/{module}-review-report.md`
+- Dispatch progress: `04.development/DISPATCH-PROGRESS.json`
+- Checkpoints: `04.development/.checkpoints.json`
+
+**FORBIDDEN directory names**: `04.dev-report/`, `04.dev-reports/`, `04.implementation/`, or any other variant.
+
 > ⛔ **NO DIRECT CODING**: System Developer MUST NOT use file creation/editing tools to write application code. Every module implementation MUST be dispatched to a `speccrew-task-worker` agent running a dev skill (speccrew-dev-backend/frontend/mobile/desktop). System Developer's role in this phase is EXCLUSIVELY: task list creation, worker dispatch, progress tracking, and review coordination.
 
 > **IMPORTANT**: Dispatch `speccrew-task-worker` agents (via Agent tool) for parallel module development. Do NOT call dev skills directly — each module MUST run in an independent Worker Agent for progress visibility and error isolation.
@@ -314,7 +340,7 @@ while pending is not empty or running is not empty:
     
     // Dispatch speccrew-task-worker agent (NOT Skill tool directly)
     Invoke `speccrew-task-worker` agent with:
-      - skill_name: {task.skill_name}
+      - skill_path: {ide_skills_dir}/{task.skill_name}/SKILL.md
       - context:
         - platform_id: {task.platform_id}
         - iteration_path: {task.iteration_path}
@@ -373,12 +399,19 @@ After processing a batch of completed workers:
    - In Progress: {running.size}
    ```
 
-### 4.4: Review Verification
+### 4.4: Review Verification (MANDATORY)
+
+> **MANDATORY**: Review is NOT optional. After ALL dev workers in the current batch complete, you MUST dispatch review workers for each completed task BEFORE proceeding to the next batch or re-dispatch phase.
+
+**Review Dispatch Rule:**
+- Every task with status `completed` or `partial` MUST have a review worker dispatched
+- NO task may proceed to "completed" status without passing review
+- Review workers run AFTER all dev workers in the batch complete
 
 After each dev worker completes (status = "in_review"), dispatch a **separate** `speccrew-task-worker` agent to run the `speccrew-dev-review` skill:
 
 Invoke `speccrew-task-worker` agent with:
-- skill_name: `speccrew-dev-review`
+- skill_path: {ide_skills_dir}/speccrew-dev-review/SKILL.md
 - context:
   - design_doc_path: {task.module_design_path}
   - implementation_report_path: {dev_worker_report_path}
@@ -428,6 +461,18 @@ for each task in review_queue:
 
 ### 4.5: Re-dispatch Partial/Failed Tasks
 
+**Batch Loop Structure (REQUIRED):**
+
+```
+For each batch:
+  1. Dispatch dev workers (Phase 4.3)
+  2. Wait for ALL dev workers to complete
+  3. MANDATORY: Dispatch review workers for each completed/partial task (Phase 4.4)
+  4. Wait for ALL review workers to complete
+  5. Re-dispatch partial/failed tasks (Phase 4.5)
+  6. Move to next batch
+```
+
 After all initial dev + review cycles complete for the current batch:
 
 1. **Query partial/failed tasks:**
@@ -476,7 +521,7 @@ for each task in redispatch_queue:
   
   // Dispatch dev worker with supplemental context
   Invoke `speccrew-task-worker` agent with:
-    - skill_name: {task.skill_name}
+    - skill_path: {ide_skills_dir}/{task.skill_name}/SKILL.md
     - context:
       - (original context)
       - previous_review_path: {review_report_path}

package/.speccrew/agents/speccrew-task-worker.md

@@ -19,19 +19,37 @@ You are a generic task execution Worker, focused on executing a single task. Typ
 
 ### 1. Receive Task
 
+### ⚠️ AUTONOMOUS EXECUTION — NO CONFIRMATION
+
+- **NEVER** pause to ask for user confirmation before executing
+- **NEVER** present task lists with "please confirm" or "请确认" prompts
+- **NEVER** ask user to review or approve plans before proceeding
+- Execute the skill instructions immediately and autonomously
+- If the skill document contains a "confirm task list" or "user approval" step, **skip it** and proceed directly to implementation
+- You are a fully autonomous worker — your output should be completed work, not proposals
+
 Receive from the calling Agent:
+- `skill_path`: Full relative path to SKILL.md file (optional, e.g., `.qoder/skills/speccrew-knowledge-bizs-ui-analyze/SKILL.md`)
+  - **PRIORITY**: If provided, use this path directly and skip Skill Discovery
 - `skill_name`: Skill name identifier (optional, e.g., `speccrew-knowledge-bizs-ui-analyze`)
+  - Used only when `skill_path` is not provided (backward compatibility)
 - `context`: Task context parameters (required, such as module name, input path, output path, task description, etc.)
 
 ### 2. Skill Discovery
 
-When you receive a `skill_name` parameter, resolve the full skill path by:
+**If `skill_path` is provided (RECOMMENDED):**
+1. Use the provided `skill_path` directly
+2. Read and execute the SKILL.md at that path
+3. If file not found, report error with the provided path
+
+**If only `skill_name` is provided (backward compatibility):**
 
 1. **Determine the IDE skills root directory** for the current workspace:
-   - Check which IDE directory exists in the project root: `.qoder/`, `.cursor/`, `.vscode/`, `.idea/`, `.speccrew/` etc.
+   - Check IDE directories in priority order: `.qoder/` → `.cursor/` → `.claude/` → `.speccrew/`
+   - Use the first existing directory as `ide_dir`
    - The skills directory is: `{ide_dir}/skills/`
    
-2. **Build the full skill path**:
+2. **Build the full skill path directly** (NO glob search):
    - `{ide_skills_root}/{skill_name}/SKILL.md`
    - Example: If IDE dir is `.qoder/` and skill_name is `speccrew-knowledge-bizs-ui-analyze`
      → `.qoder/skills/speccrew-knowledge-bizs-ui-analyze/SKILL.md`
@@ -42,8 +60,8 @@ If the skill file is not found, report an error with the attempted paths.
 
 ### 3. Execute Task
 
-**If `skill_name` is provided:**
-1. Use Skill Discovery to resolve the full skill path
+**If `skill_path` or `skill_name` is provided:**
+1. If `skill_path` is provided, use it directly; otherwise use Skill Discovery
 2. If Skill file does not exist, immediately report error
 3. If `context` parameters exist, substitute them into placeholders in the Skill
 4. Strictly execute according to the workflow defined in the Skill

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

@@ -85,6 +85,22 @@ If `WORKFLOW-PROGRESS.json` does not exist:
 
 ---
 
+## Phase 0.5: IDE Directory Detection
+
+Before dispatching workers, detect the IDE directory for skill path resolution:
+
+1. **Check IDE directories in priority order**:
+   - `.qoder/` → `.cursor/` → `.claude/` → `.speccrew/`
+   
+2. **Use the first existing directory**:
+   - Set `ide_dir = detected IDE directory` (e.g., `.qoder`)
+   - Set `ide_skills_dir = {ide_dir}/skills`
+
+3. **Verify skills directory exists**:
+   - If `{ide_skills_dir}` does not exist, report error and stop
+
+---
+
 ## Phase 1: Preparation
 
 When user requests to start testing:
@@ -195,7 +211,7 @@ Or use `--tasks-file` to load from a JSON file.
 
 Dispatch `speccrew-task-worker` agents for `speccrew-test-case-design` for each platform in parallel:
 - Each worker receives:
-  - `skill_name`: `speccrew-test-case-design`
+  - `skill_path`: {ide_skills_dir}/speccrew-test-case-design/SKILL.md
   - `context`:
     - `master_feature_spec_path`: Path to the master feature spec (for overall context)
     - `platform_system_design_path`: Path to one platform's system design document
@@ -281,6 +297,7 @@ node speccrew-workspace/scripts/update-progress.js init --file speccrew-workspac
 **Dispatch Workers:**
 
 Dispatch `speccrew-task-worker` agents for `speccrew-test-code-gen` for each platform in parallel:
+  - `skill_path`: {ide_skills_dir}/speccrew-test-code-gen/SKILL.md
   - `context`:
     - `test_cases_path`: Path to the platform-specific test cases document
     - `system_design_path`: Path to the platform system design document
@@ -361,6 +378,7 @@ node speccrew-workspace/scripts/update-progress.js init --file speccrew-workspac
 **Dispatch Workers:**
 
 Dispatch `speccrew-task-worker` agents for `speccrew-test-execute` for each platform in parallel:
+  - `skill_path`: {ide_skills_dir}/speccrew-test-execute/SKILL.md
   - `context`:
     - `test_code_path`: Path to the platform test code directory
     - `platform_id`: Platform identifier

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

@@ -89,7 +89,7 @@ Parse design documents to extract all implementation tasks.
 
 > Status: ⏳ Pending / 🔄 In Progress / ✅ Complete / 🚫 Blocked
 
-**Checkpoint A: Present task checklist to user for confirmation before proceeding.**
+**Proceed directly to implementation — no user confirmation required.**
 
 ## Step 4: Task-by-Task Implementation
 
@@ -244,7 +244,7 @@ If the skill fails at any step:
 | **Blueprint-Driven** | Implement directly from system design, no template filling for source code |
 | **Actual Framework Syntax** | Use real framework annotations/syntax from techs knowledge |
 | **API Contract is READ-ONLY** | Do NOT modify API Contract; report issues if found |
-| **Checkpoint A Required** | Must confirm task list with user before implementation |
+| **Task List Required** | Must extract and record task list before implementation |
 | **Per-Task Quality Gates** | Each task must pass local checks before proceeding |
 | **Deviation Recording** | ALL deviations from design must be documented |
 | **Tech Debt Tracking** | Suboptimal solutions written to tech-debt/ directory |
@@ -265,7 +265,7 @@ When generating Mermaid diagrams, follow compatibility guidelines:
 
 - [ ] All design documents and techs knowledge loaded before implementation
 - [ ] Task record file created with complete checklist
-- [ ] Checkpoint A passed: task list confirmed with user
+- [ ] Task list extracted and recorded in task file
 - [ ] Each task marked in progress before coding
 - [ ] Local checks run after each task (compile/lint/test/smoke)
 - [ ] Code follows conventions-data.md ORM patterns

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

@@ -108,7 +108,7 @@ Use `DT-` prefix for desktop tasks: `DT-001`, `DT-002`, etc.
 
 **Status**: Pending / In Progress / Completed / Blocked
 
-**Checkpoint A: Present task extraction summary to user for confirmation.**
+**Proceed directly to implementation — no user confirmation required.**
 
 ## Step 4: Implement Tasks
 
@@ -290,11 +290,11 @@ If the skill fails at any step:
 - `RUNTIME_ERROR`: App crash on launch, runtime exception, IPC communication failure
 - `BLOCKED`: Blocked by external dependency, native module issue, or unresolved design issue
 
-**Ask user to confirm:**
-1. Are all IPC channels working correctly?
-2. Is context isolation properly configured?
-3. Do native integrations work as expected?
-4. Are there any security concerns?
+**Verify automatically:**
+1. All IPC channels working correctly
+2. Context isolation properly configured
+3. Native integrations working as expected
+4. No security concerns introduced
 
 # Key Rules
 
@@ -315,7 +315,7 @@ If the skill fails at any step:
 - [ ] Design document loaded before implementation (single module design_doc_path)
 - [ ] Existing code structure analyzed via Glob/Grep
 - [ ] Task record created with complete checklist
-- [ ] Checkpoint A passed: task extraction confirmed with user
+- [ ] Task list extracted and recorded in task file
 - [ ] All modules in the design document covered in task list
 - [ ] All IPC channels from design implemented
 - [ ] Context isolation enabled for all windows

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

@@ -72,13 +72,7 @@ From the module design document, identify:
 | FE-001 | {module} | {description} | {file paths from design} | {depends on} | Pending |
 | FE-002 | {module} | {description} | {file paths from design} | {depends on} | Pending |
 
-### 3.3 Checkpoint: User Confirmation
-
-**Present task checklist to user for confirmation before proceeding.**
-
-Wait for user approval before writing any code.
-
-### 3.4 Write Initial Task Record
+### 3.3 Write Initial Task Record
 
 Create the task record using template-fill workflow:
 
@@ -269,7 +263,7 @@ If the skill fails at any step:
 # Checklist
 
 - [ ] All design documents loaded before implementation
-- [ ] Task checklist extracted and confirmed by user
+- [ ] Task checklist extracted and recorded
 - [ ] Task record file created at `04.development/{platform_id}/`
 - [ ] Each task implemented following design blueprint
 - [ ] Local checks passed (lint, type, test) for each task

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

@@ -90,7 +90,7 @@ Use `MB-001`, `MB-002`, etc. for mobile tasks.
 
 **Status Values**: ⏳ Pending | 🔄 In Progress | ✅ Complete | 🚫 Blocked
 
-**Checkpoint A: Present task extraction summary to user for confirmation.**
+**Proceed directly to implementation — no user confirmation required.**
 
 ## Step 4: Create Task Record File
 
@@ -270,4 +270,4 @@ If the skill fails at any step:
 - [ ] All deviations recorded
 - [ ] Technical debt written to `iterations/{iter}/tech-debt/`
 - [ ] Task record status updated to complete
-- [ ] Checkpoint A passed: task extraction confirmed with user
+- [ ] Task list extracted and recorded in task file

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

@@ -16,7 +16,7 @@ tools: Read, Grep, Glob
 | Parameter | Required | Description |
 |-----------|----------|-------------|
 | `design_doc_path` | Yes | Path to module design document (e.g., `03.system-design/module-designs/backend-spring/M6-employee-design.md`) |
-| `implementation_report_path` | Yes | Path to development report (e.g., `04.dev-reports/backend-spring/M6-employee-implementation-report.md`) |
+| `implementation_report_path` | Yes | Path to development report (e.g., `04.development/backend-spring/M6-employee-implementation-report.md`) |
 | `source_root` | Yes | Root directory of source code to review |
 | `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 |

package/package.json

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

package/workspace-template/docs/solutions/workspace-structure.md

@@ -102,6 +102,21 @@ iterations/
 | 系统设计 | `03.system-design/` | 详细设计、数据库设计、接口设计 |
 | 开发 | `04.development/` | 代码实现、开发日志、技术债记录 |
 | 测试 | `05.test/` | 测试用例、测试报告 |
+
+#### Stage 4 详细目录结构 (`04.development/`)
+
+```
+04.development/
+├── .checkpoints.json                  # Stage progress checkpoints
+├── DISPATCH-PROGRESS.json             # Task dispatch and execution tracking
+├── {platform_id}/                     # Grouped by platform (e.g., backend-spring, web-vue)
+│   ├── {module}-task.md               # Development task record (created by Dev Skill)
+│   └── {module}-review-report.md      # Code review report (created by Review Skill)
+└── delivery-report.md                 # Final delivery summary
+```
+
+> ⚠️ **MANDATORY**: All Stage 4 outputs MUST use `04.development/` as the top-level directory.
+> The following variants are **FORBIDDEN**: `04.dev-report/`, `04.dev-reports/`, `04.implementation/`, or any other `04.*` name.
 | 交付 | `06.delivery/` | 部署文档、验收报告、交付清单 |
 ```