speccrew 0.2.7 → 0.3.1

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

@@ -24,10 +24,15 @@ tools: Read, Write, Glob, Grep
 
 ## Step 1: Read Inputs
 
+**Input Parameters** (from agent context):
+- `feature_id` (optional): Feature identifier, e.g., `F-CRM-01`. If provided, use new naming format.
+- `feature_name`: Feature name, e.g., `customer-list`.
+- `platform_id`: Target platform, e.g., `frontend-vue`, `frontend-react`.
+
 Read in order:
 
-1. **Feature Spec document(s)**: `speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/[feature-name]-feature-spec.md`
-2. **API Contract**: `speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/[feature-name]-api-contract.md`
+1. **Feature Spec document(s)**: `speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/{feature-id}-{feature-name}-feature-spec.md`
+2. **API Contract**: `speccrew-workspace/iterations/{number}-{type}-{name}/02.feature-design/{feature-id}-{feature-name}-api-contract.md`
 3. **Frontend techs knowledge** (paths from agent context):
    - `speccrew-workspace/knowledges/techs/{platform_id}/tech-stack.md`
    - `speccrew-workspace/knowledges/techs/{platform_id}/architecture.md`
@@ -56,6 +61,8 @@ Document findings for reference in later steps.
 
 Parse Feature Spec to identify all functions (Section 2.N pattern).
 
+> **Note**: With the new fine-grained Feature Spec format, each Feature Spec typically contains **3-8 functions** (previously 10-20). The extraction logic remains the same, but the scope is more focused.
+
 For each function, extract:
 
 | Aspect | Content to Extract |
@@ -89,7 +96,10 @@ Read `SD-FRONTEND-TEMPLATE.md` for document structure.
 2. **Replace top-level placeholders** with known variables:
    - Module name, feature name, platform ID, etc.
 3. **Create the document file** using `create_file`:
-   - Target path: `speccrew-workspace/iterations/{number}-{type}-{name}/03.system-design/{platform_id}/{module}-design.md`
+   - **Target path pattern**:
+     - With `feature_id`: `speccrew-workspace/iterations/{number}-{type}-{name}/03.system-design/{platform_id}/{feature-id}-{feature-name}-design.md`
+       - Example: `03.system-design/frontend-vue/F-CRM-01-customer-list-design.md`
+     - Without `feature_id` (backward compatibility): `speccrew-workspace/iterations/{number}-{type}-{name}/03.system-design/{platform_id}/{module}-design.md`
    - Content: Template with top-level placeholders replaced
 4. **Verify**: Document should have complete section structure ready for filling
 
@@ -161,6 +171,15 @@ Read `INDEX-TEMPLATE.md` for document structure.
 
 Create table with links to each module design document.
 
+| Column | Content |
+|--------|---------|
+| **ID** | Use `feature_id` if available (e.g., `F-CRM-01`), otherwise use module name |
+| **Name** | Feature or module name |
+| **Document** | Link to design file (e.g., `F-CRM-01-customer-list-design.md`) |
+| **Status** | `[NEW]`, `[MODIFIED]`, or `[EXISTING]` |
+
+Example row with `feature_id`: `| F-CRM-01 | Customer List | F-CRM-01-customer-list-design.md | NEW |`
+
 ### 5.4 Verify Output
 
 Verify the completed INDEX.md:
@@ -207,11 +226,11 @@ After completing all steps, output a structured completion report for the System
 - **Status**: SUCCESS
 - **Task ID**: {task_id from context}
 - **Platform**: {platform_id}
+- **Feature ID**: {feature_id}
 - **Feature**: {feature_name}
 - **Output Files**:
   - speccrew-workspace/iterations/{iter}/03.system-design/{platform_id}/INDEX.md
-  - speccrew-workspace/iterations/{iter}/03.system-design/{platform_id}/{module1}-design.md
-  - speccrew-workspace/iterations/{iter}/03.system-design/{platform_id}/{module2}-design.md
+  - speccrew-workspace/iterations/{iter}/03.system-design/{platform_id}/{feature-id}-{feature-name}-design.md (or {module}-design.md if no feature_id)
 - **Summary**: Frontend system design completed for {feature_name} on {platform_id} with {count} module designs
 ```
 
@@ -222,6 +241,7 @@ After completing all steps, output a structured completion report for the System
 - **Status**: FAILED
 - **Task ID**: {task_id from context}
 - **Platform**: {platform_id}
+- **Feature ID**: {feature_id}
 - **Feature**: {feature_name}
 - **Output Files**: []
 - **Error**: {description of what went wrong}

package/.speccrew/skills/speccrew-test-case-design/SKILL.md

@@ -98,6 +98,13 @@ speccrew-workspace/knowledges/techs/{platform_id}/conventions-system-test.md
 | Test Data Management | Fixtures, seeding, mock strategies |
 | API Contract Testing | Contract testing conventions if applicable |
 
+**Fallback Handling:**
+
+IF `conventions-system-test.md` not found:
+1. Use default analysis dimensions defined in Step 4
+2. Proceed without platform-specific testing conventions
+3. Log a note: "Testing conventions file not found, using default analysis dimensions"
+
 ## Step 4: Analyze Test Dimensions
 
 Systematically analyze test dimensions to ensure comprehensive coverage:
@@ -206,6 +213,16 @@ Each test case contains:
 | P2-Medium | Standard functionality, moderate impact | Edge cases, secondary flows |
 | P3-Low | Minor functionality, low impact | UI polish, rare edge cases |
 
+**Priority Mapping from Feature Spec to Test Cases:**
+
+| Feature Spec Priority | Test Case Priority | Mapping Rationale |
+|-----------------------|-------------------|------------------|
+| P0 (Critical) | P0 (Critical) | Core functionality must have critical test coverage |
+| P1 (Important) | P1 (High) | Important features need high-priority test validation |
+| P2 (Standard) | P2 (Medium) | Standard features receive medium-priority testing |
+| P3 (Minor) | P3 (Low) | Minor features receive low-priority testing |
+| Unspecified | P2 (Medium) | Default to medium priority if not specified |
+
 ## Step 6: Coverage Self-Check
 
 ### 6.1 Acceptance Criteria Coverage

package/.speccrew/skills/speccrew-test-code-gen/SKILL.md

@@ -50,7 +50,7 @@ Load platform testing conventions to understand the target test framework:
 speccrew-workspace/knowledges/techs/{platform_id}/conventions-system-test.md
 ```
 
-### 2.2 Secondary Convention Path (Fallback for Unit Testing)
+### 2.2 Unit Test Convention Path (Fallback)
 
 If `conventions-system-test.md` does not exist or for unit test specifics, read:
 
@@ -58,7 +58,7 @@ If `conventions-system-test.md` does not exist or for unit test specifics, read:
 speccrew-workspace/knowledges/techs/{platform_id}/conventions-unit-test.md
 ```
 
-### 2.3 Fallback Convention Path (Last Resort)
+### 2.3 Generic Convention Path (Last Resort)
 
 If neither conventions file exists, read `conventions-dev.md` and infer:
 
@@ -66,7 +66,7 @@ If neither conventions file exists, read `conventions-dev.md` and infer:
 |-----------------|-------------------|
 | conventions-dev.md | Extract framework from tech stack, infer unit test framework |
 
-### 2.3 Information to Extract
+### 2.4 Information to Extract
 
 | Item | Purpose |
 |------|---------|
@@ -109,6 +109,23 @@ For mocking strategy planning:
 
 Create a comprehensive test code generation plan:
 
+### 4.0 Determine File Grouping Strategy
+
+Before organizing test files, determine the grouping strategy:
+
+| Condition | Grouping Strategy |
+|-----------|-------------------|
+| Test cases share same module/component | Group into single test file |
+| Test cases are independent | One test file per test case |
+| Test cases span multiple modules | Create separate test files per module |
+
+**File Grouping Rules:**
+
+1. **IF test cases share same module/component THEN** group into single test file
+2. **IF test cases are independent THEN** one test file per test case
+3. **Maximum test cases per file:** 10 (split into multiple files if exceeded)
+4. **Naming convention:** `{module-name}.test.{ext}` or `{module-name}.spec.{ext}`
+
 ### 4.1 Test File Structure Planning
 
 Determine how test files are organized:

package/.speccrew/skills/speccrew-test-execute/SKILL.md

@@ -85,6 +85,12 @@ Determine if the system under test requires:
 
 **Checkpoint A**: If any environment check fails, report specific missing items and stop execution.
 
+✋ **STOP IF FAILED**: IF any pre-check fails THEN:
+1. Stop workflow immediately
+2. Report all failures to user
+3. Do NOT proceed to test execution
+4. Fix all environment issues before retry
+
 ## Step 3: Execute Tests
 
 ### 3.1 Determine Test Command
@@ -183,6 +189,8 @@ For each deviation, analyze:
 - **Skip Reason**: Why test could not execute
 - **Flaky Pattern**: Conditions causing intermittent failure
 
+> 📋 **Output Requirement**: These root cause analysis results MUST be included in Step 6 Report under the "Recommendations" section. Each root cause should map to its corresponding test case ID for traceability.
+
 ## Step 6: Generate Test Report
 
 ### 6.1 Read Template

package/package.json

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