cc-dev-template 0.1.80 → 0.1.82

package/src/skills/spec-to-tasks/references/step-2-explore.md

@@ -1,43 +0,0 @@
-# Step 2: Verify File Landscape
-
-The spec should already contain a File Landscape section from the interview process. This step verifies and supplements it.
-
-## Check the Spec
-
-Read the spec's File Landscape section. It should list:
-- **Files to create**: New files with paths and purposes
-- **Files to modify**: Existing files that need changes
-
-If the File Landscape section is missing or incomplete, use an Explorer to fill the gaps:
-
-> "To implement [feature from spec], what files would need to be created or modified? Give me concrete file paths."
-
-## Map Files to Acceptance Criteria
-
-For each acceptance criterion in the spec, identify which files are involved. This mapping drives task generation.
-
-Example:
-```
-"User can receive notifications"
-  → src/models/notification.ts
-  → src/services/notificationService.ts
-  → src/services/notificationService.test.ts
-
-"User can view notification list"
-  → src/routes/notifications.ts
-  → src/components/NotificationList.tsx
-```
-
-If a criterion's files aren't clear from the spec, ask an Explorer:
-
-> "What files would be involved in making this criterion pass: [criterion]?"
-
-## Output
-
-You should now have:
-1. Complete list of files to create and modify
-2. Each acceptance criterion mapped to its files
-
-## Next Step
-
-Once files are mapped to criteria, read `references/step-3-generate.md`.

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

@@ -1,69 +0,0 @@
-# Step 3: Generate Task Files
-
-Create individual task files based on the spec and codebase exploration.
-
-## Task Principles
-
-**Criterion-based**: Each task corresponds to one acceptance criterion from the spec. A task includes all files needed to make that criterion pass. Do NOT split by file or architectural layer.
-
-**Verifiable**: Every task has a verification method from the spec. A coder implements, a QA agent verifies, and the loop continues until it passes.
-
-**Ordered**: Name files so they sort in dependency order (T001, T002, etc.). Tasks with no dependencies on each other can be worked in parallel.
-
-**Concrete file paths**: Use the file paths discovered in Step 2. Every task lists all files it touches.
-
-## Deriving Tasks from Acceptance Criteria
-
-Each acceptance criterion in the spec becomes one task.
-
-**For each criterion, determine:**
-1. What files must exist or change for this to pass?
-2. What's the verification method from the spec?
-3. What other criteria must pass first? (dependencies)
-
-**Grouping rules:**
-- If two criteria share foundational work (e.g., both need a model), the first task creates the foundation, later tasks build on it
-- If a criterion is too large (touches 10+ files), flag it — the spec may need refinement
-- Small tasks are fine; artificial splits are not
-
-**Anti-patterns to avoid:**
-- "Create the User model" — no verifiable outcome
-- "Add service layer" — implementation detail, not behavior
-- "Set up database schema" — means to an end, not the end
-
-**Good task boundaries:**
-- "User can register with email" — verifiable, coherent
-- "Duplicate emails are rejected" — verifiable, coherent
-- "Dashboard shows notification count" — verifiable, coherent
-
-## Validate Criteria Quality
-
-Before generating tasks, verify each acceptance criterion has:
-- A specific, testable condition
-- A verification method (test command, agent-browser script, or query)
-
-If criteria are vague or missing verification, stop and ask:
-> "The criterion '[X]' doesn't have a clear verification method. Should I suggest one, or would you like to refine the spec first?"
-
-## Generate Task Files
-
-Create a `tasks/` directory inside the spec folder:
-
-```
-docs/specs/<name>/
-├── spec.md
-└── tasks/
-    ├── T001-<slug>.md
-    ├── T002-<slug>.md
-    └── T003-<slug>.md
-```
-
-Use the template in `templates/task.md` for each file. Name files in dependency order so alphabetical sorting reflects execution order.
-
-## Do NOT Present Results Yet
-
-You have generated task files but you are NOT done. The review step is next and it is mandatory.
-
-**IMPORTANT: You are not done. You MUST read and complete the next step. The workflow is incomplete without it.**
-
-Read `references/step-4-review.md` now.

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

@@ -1,95 +0,0 @@
-# Step 4: Review Task Breakdown
-
-**IMPORTANT: This step is mandatory. The spec-to-tasks workflow is not complete until this step is finished. Do not skip this.**
-
-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.
-
-## Review Checklist
-
-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
-
-### 1. Coverage
-
-Compare acceptance criteria in the spec to tasks generated.
-
-- Every acceptance criterion has exactly one corresponding task
-- No criteria were skipped or forgotten
-- No phantom tasks that don't map to a criterion
-
-**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.
-
-### 2. Dependency Order
-
-- 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
-
-### 3. File Plausibility
-
-- 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)
-
-### 4. Verification Executability
-
-- 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
-
-- Task titles match or closely reflect the acceptance criterion
-- Status is `pending` for all new tasks
-- Frontmatter format is consistent across all task files
-
-### 9. Component Consolidation
-
-- 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
-
-**IMPORTANT: You are not done. You MUST read and complete the next step. The workflow is incomplete without it.**
-
-Read `references/step-5-reflect.md` now.

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

@@ -1,22 +0,0 @@
-# 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.

package/src/skills/spec-to-tasks/templates/task.md

@@ -1,30 +0,0 @@
----
-id: T00X
-title: <Short descriptive title — the acceptance criterion>
-status: pending
-depends_on: []
----
-
-## Criterion
-
-<The acceptance criterion from the spec, verbatim or lightly edited for clarity>
-
-## Files
-
-- <path/to/file.ts>
-- <path/to/another-file.ts>
-- <path/to/test-file.test.ts>
-
-## Verification
-
-<The verification method from the spec — test command, agent-browser script, or manual steps>
-
----
-
-## Implementation Notes
-
-<!-- Coder agent writes here after each implementation attempt -->
-
-## Review Notes
-
-<!-- QA agent writes here after each review pass -->

package/src/skills/task-review/SKILL.md

@@ -1,18 +0,0 @@
----
-name: task-review
-description: Reviews task breakdown for completeness, correct ordering, and implementation readiness. Use after spec-to-tasks generates task files.
-argument-hint: <spec-name>
-context: fork
----
-
-# Task Review
-
-Review the task breakdown to catch issues before implementation begins.
-
-## What To Do Now
-
-If an argument was provided, use it as the spec name. Otherwise, find the most recent spec with a `tasks/` directory.
-
-Read the spec file and all task files in the `tasks/` directory.
-
-Then read `references/checklist.md` and evaluate each item.

package/src/skills/task-review/references/checklist.md

@@ -1,155 +0,0 @@
-# Task Review Checklist
-
-Evaluate each area. For each issue found, note the severity:
-- **Critical**: Must fix before implementation
-- **Warning**: Should fix, but could proceed
-- **Note**: Minor suggestion
-
-## 1. Coverage
-
-Compare acceptance criteria in the spec to tasks generated.
-
-**Check:**
-- [ ] Every acceptance criterion has exactly one corresponding task
-- [ ] No criteria were skipped or forgotten
-- [ ] No phantom tasks that don't map to a criterion
-
-**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.
-
-## 2. Dependency Order
-
-Tasks should be sequenced so each can be completed without waiting on later tasks.
-
-**Check:**
-- [ ] 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
-
-**Common issues:**
-- API route task before the service it calls
-- UI component before the API it fetches from
-- Test file before the code it tests (tests should be in same task as code)
-
-## 3. File Plausibility
-
-Files listed in each task should make sense for the project.
-
-**Check:**
-- [ ] File paths follow project conventions (use Explorer if unsure)
-- [ ] 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)
-
-**How to verify:**
-For files to modify, confirm they exist. For files to create, confirm the parent directory exists and the naming follows conventions.
-
-## 4. Verification Executability
-
-Each task's verification method must be concrete and runnable.
-
-**Check:**
-- [ ] Verification is a specific command or script, not vague prose
-- [ ] Test file paths exist or will be created by the task
-- [ ] agent-browser commands reference real routes/elements
-- [ ] 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
-
-Each task's verification must test ALL behaviors mentioned in its criterion.
-
-**Check:**
-- [ ] 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
-
-**How to verify:**
-For each task, extract bullet points from the criterion. For each bullet, find the matching verification step. If a behavior is mentioned but not tested, that's a Critical issue.
-
-**Common gaps:**
-- Criterion mentions "X persists across refresh" but verification doesn't test refresh
-- Criterion mentions "handles edge case Y" but verification only tests happy path
-- Criterion mentions animation/timing but verification can't test it (should note "Manual test required")
-
-## 6. Dependency Completeness
-
-Dependencies must be complete, not just valid.
-
-**Check:**
-- [ ] 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
-- [ ] If task X requires context from task Y (e.g., branding, layout, shared state), Y must be in X's depends_on
-
-**How to verify:**
-For each task, look at its Files section. For each "modify" entry, search other tasks for where that file is created. If found, verify the creating task is in depends_on. Also check the criterion for implicit dependencies (e.g., "shows branding" implies depending on the branding task).
-
-**Common gaps:**
-- Task uses a layout but doesn't depend on the task that configures the layout
-- Task modifies shared state but doesn't depend on the task that creates the context
-- Task assumes a feature exists but the feature is created by a later task
-
-## 7. Task Scope
-
-Each task should be appropriately sized for the coder→QA loop.
-
-**Check:**
-- [ ] 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, not just "creates a file"
-
-## 8. Consistency
-
-Cross-check task files against each other and the spec.
-
-**Check:**
-- [ ] Task titles match or closely reflect the acceptance criterion
-- [ ] Status is `pending` for all new tasks
-- [ ] Frontmatter format is consistent across all task files
-- [ ] Implementation Notes and Review Notes sections exist (empty is fine)
-
-## 9. Component Consolidation
-
-Scan for tasks that create structurally similar files.
-
-**Check:**
-- [ ] No two tasks create components with similar names, purposes, or overlapping structure
-- [ ] Shared patterns (cards, forms, list items, layout sections) use a single shared component with configuration, not separate implementations
-- [ ] Utility functions or services with similar logic are consolidated
-
-**How to verify:**
-Compare files-to-create across all tasks. Group by similarity (naming patterns, structural role, data shape). When two or more tasks create similar files, flag for consolidation.
-
-**Common issues:**
-- Three "card" components for different pages that differ only by displayed fields
-- Two form components with nearly identical validation and submission logic
-- Repeated layout patterns that could be a shared template with slots/children
-
----
-
-## Output Format
-
-Return findings as a structured list:
-
-```
-## Critical Issues
-- [T002] Depends on T005 which comes later - wrong order
-- [T003] Missing verification method
-
-## Warnings
-- [T001] touches 12 files - consider splitting
-- Criterion "User can delete account" has no corresponding task
-
-## Notes
-- [T004] Could merge with T005 since they share the same files
-
-## Skill Observations (optional)
-If any checklist items, severity criteria, or review patterns in this skill were wrong, incomplete, or misleading during this review, note them here. Leave empty if no issues were found.
-```
-
-If no issues found, state: "Task breakdown looks good. All criteria covered, dependencies valid, verification methods concrete."