cc-dev-template 0.1.78 → 0.1.79

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "cc-dev-template",
-  "version": "0.1.78",
+  "version": "0.1.79",
   "description": "Structured AI-assisted development framework for Claude Code",
   "bin": {
     "cc-dev-template": "./bin/install.js"

package/src/skills/spec-to-tasks/SKILL.md

@@ -9,14 +9,15 @@ context: fork
 
 ## Workflow Overview
 
-This skill has 4 steps. **You must complete ALL steps before presenting to the user.**
+This skill has 5 steps. **You must complete ALL steps. Do not stop early or skip any step.**
 
 1. **Identify Spec** - Find and verify the spec file
 2. **Verify File Landscape** - Map files to acceptance criteria
 3. **Generate Tasks** - Create task files in `tasks/` directory
-4. **Review Tasks** - Invoke `task-review` skill to validate, fix issues
+4. **Review Tasks** - Run review checklist in a loop until no critical issues remain
+5. **Reflect** - Note any skill issues observed during this run
 
-Do NOT skip step 4. The review catches dependency errors and coverage gaps.
+Steps 4 and 5 are mandatory. The review loop in step 4 is automated — fix issues and re-check until clean, with no user input required.
 
 ## What To Do Now
 

package/src/skills/spec-to-tasks/references/step-3-generate.md

@@ -60,13 +60,10 @@ docs/specs/<name>/
 
 Use the template in `templates/task.md` for each file. Name files in dependency order so alphabetical sorting reflects execution order.
 
-## REQUIRED: Run Review Before Presenting
+## Do NOT Present Results Yet
 
-**Do NOT present results to the user yet.** After generating task files, you MUST:
+You have generated task files but you are NOT done. The review step is next and it is mandatory.
 
-1. Read `references/step-4-review.md`
-2. Invoke the `task-review` skill to validate the breakdown
-3. Fix any critical issues found
-4. Only then present results (including any warnings)
+**IMPORTANT: You are not done. You MUST read and complete the next step. The workflow is incomplete without it.**
 
-This review step catches dependency errors, coverage gaps, and verification issues. Skipping it leads to broken task breakdowns that fail during implementation.
+Read `references/step-4-review.md` now.

package/src/skills/spec-to-tasks/references/step-4-review.md

@@ -1,50 +1,95 @@
 # Step 4: Review Task Breakdown
 
-**This step is REQUIRED.** Do not present results until review is complete.
+**IMPORTANT: This step is mandatory. The spec-to-tasks workflow is not complete until this step is finished. Do not skip this.**
 
-## Run Task Review
+You must review the generated tasks, fix any issues, and re-review until the breakdown is clean. This is fully automated — do not ask the user for input during this step.
 
-Invoke the task-review skill NOW:
+## Review Checklist
 
-```
-Skill(skill: "task-review", args: "<spec-name>")
-```
+Read every task file and the spec. Evaluate each area below. For each issue found, note the severity:
+- **Critical**: Must fix before proceeding
+- **Warning**: Should fix, but could proceed
+- **Note**: Minor suggestion
 
-Wait for the review to complete before proceeding.
+### 1. Coverage
 
-The review will check:
-- Coverage (all criteria have tasks)
-- Dependency order (tasks properly sequenced)
-- File plausibility (paths make sense)
-- Verification executability (concrete commands)
-- Task scope (appropriately sized)
-- Consistency (format, frontmatter)
+Compare acceptance criteria in the spec to tasks generated.
 
-## Handle Findings
+- Every acceptance criterion has exactly one corresponding task
+- No criteria were skipped or forgotten
+- No phantom tasks that don't map to a criterion
 
-The review returns findings categorized as Critical, Warning, or Note.
+**How to verify:** List each criterion from the spec's Acceptance Criteria section. For each, find the matching task file. Flag any orphans in either direction.
 
-**Critical issues**: Fix before proceeding. Update the affected task files.
+### 2. Dependency Order
 
-**Warnings**: Present to user with your recommendation (fix or skip).
+- Task file names sort in valid execution order (T001, T002, etc.)
+- Each task's `depends_on` references only earlier tasks
+- No circular dependencies
+- Foundation work comes before features that use it
 
-**Notes**: Mention briefly, no action required.
+### 3. File Plausibility
 
-## Present to User
+- File paths follow project conventions
+- Files to modify actually exist in the codebase
+- Files to create are in appropriate directories
+- No duplicate files across tasks (each file appears in exactly one task)
 
-After addressing critical issues, present:
+### 4. Verification Executability
 
-1. Number of tasks generated
-2. Task titles in dependency order
-3. Any warnings from the review (with recommendations)
-4. Offer to show task files or proceed to implementation
+- Verification is a specific command or script, not vague prose
+- Test file paths exist or will be created by the task
+- No "manually verify" without clear steps
+
+**Red flags:** "Verify it works correctly", "Check that the feature functions", test commands for files not listed in the task.
+
+### 5. Verification Completeness
+
+- Read the criterion text carefully — identify every distinct behavior or edge case mentioned
+- For each behavior, confirm there's a corresponding verification step
+- Flag any behaviors in the criterion that have no verification
+
+### 6. Dependency Completeness
+
+- If task X modifies a file, check if another task creates it — that task must be in X's depends_on
+- If task X uses a component/function/route, check if another task creates it — that task must be in X's depends_on
+
+### 7. Task Scope
+
+- No task touches more than ~10 files (consider splitting)
+- No trivially small tasks that could merge with related work
+- Each task produces a verifiable outcome
+
+### 8. Consistency
 
-If the user wants changes, update the task files and re-run the review.
+- Task titles match or closely reflect the acceptance criterion
+- Status is `pending` for all new tasks
+- Frontmatter format is consistent across all task files
 
-## Skill Observations
+### 9. Component Consolidation
 
-If any task generation patterns, step instructions, or template formats in this skill were wrong, incomplete, or misleading during this run, include a note in your final output to the user. This helps the parent context decide whether to update the skill.
+- No two tasks create components with similar names, purposes, or overlapping structure
+- Shared patterns use a single shared component with configuration, not separate implementations
+
+## Review Loop
+
+Run the checklist above against all task files. Then:
+
+1. **If Critical issues found:** Fix them by editing the task files. Then re-run the full checklist again from the top. Repeat until no Critical issues remain.
+2. **If only Warnings/Notes remain:** Proceed — you will present these to the user.
+3. **If no issues found:** Proceed.
+
+Do NOT present results after a single pass if Critical issues exist. The loop must continue until clean.
+
+## Present to User
+
+After the review loop completes with no Critical issues, present:
+
+1. Number of tasks generated
+2. Task dependency tree (visual format)
+3. Any Warnings from the review (with your recommendation)
+4. Offer to show task files or proceed to implementation
 
-## Complete
+**IMPORTANT: You are not done. You MUST read and complete the next step. The workflow is incomplete without it.**
 
-Once the user approves the task breakdown, the skill is complete. The tasks are ready for implementation.
+Read `references/step-5-reflect.md` now.

package/src/skills/spec-to-tasks/references/step-5-reflect.md

@@ -0,0 +1,22 @@
+# Step 5: Skill Reflection
+
+**IMPORTANT: This step is mandatory. The spec-to-tasks workflow is not complete until this step is finished. Do not skip this.**
+
+## Reflect on This Run
+
+Think about how this skill performed during this session. Consider:
+
+1. **Step instructions**: Were any steps unclear, misleading, or missing information?
+2. **Task template**: Did the template work well, or did you need to deviate from it?
+3. **Review checklist**: Did the checklist catch real issues? Were any checks unnecessary or missing?
+4. **Workflow flow**: Did the step order make sense? Were there unnecessary steps or missing ones?
+
+## Report Issues
+
+If you identified any problems with the skill's instructions, templates, or workflow, include a brief note in your final output to the user under a "Skill Observations" heading. Keep it factual — what was wrong, what would be better.
+
+If everything worked well, state: "No skill issues observed."
+
+## Complete
+
+The spec-to-tasks workflow is now complete.