cc-dev-template 0.1.81 → 0.1.82

package/src/skills/spec-interview/references/step-7-finalize.md

@@ -1,60 +0,0 @@
-# Step 7: Finalize
-
-Review the spec for completeness and soundness, then hand off.
-
-## Request Final Team Reviews
-
-Message both the Critic and Pragmatist requesting final assessments:
-
-1. Message the Critic: "The spec is substantially complete. Please do a final review against your completeness checklist and sanity check framework. Write your complete findings to `{spec_dir}/working/critic-final-review.md` using the format in your prompt."
-2. Message the Pragmatist: "The spec is substantially complete. Please do a final complexity assessment. Write your findings to `{spec_dir}/working/pragmatist-final-assessment.md` using the format in your prompt."
-3. Wait for both to respond (they will message you when their files are ready)
-4. Read their working files: `critic-final-review.md` and `pragmatist-final-assessment.md`
-
-## Curate the Findings
-
-Synthesize findings from the Critic's review and the Pragmatist's assessment. Some findings may be:
-- Critical issues that must be addressed
-- Valid suggestions worth considering
-- Pedantic or irrelevant items to skip
-
-For each finding, form a recommendation: address it or skip it, and why.
-
-The Critic and Pragmatist have had full context of the entire interview — their findings are more informed than cold reviews. Weight their input accordingly.
-
-## Walk Through With User
-
-Use AskUserQuestion to present findings in batches (2-3 at a time). For each finding:
-- State what the review found
-- Give your recommendation (always include a recommended option)
-- Let user decide: fix, skip, or something else
-
-Track two lists:
-- **Addressed**: findings the user chose to fix
-- **Intentionally skipped**: findings the user chose to ignore
-
-After walking through all findings, make the approved changes to the spec.
-
-## Offer Another Pass
-
-Use AskUserQuestion: "Do you want to run the reviews again?"
-
-If yes, message the Critic and Pragmatist again with additional context: "We already ran a review. These changes were made: [list]. These findings were intentionally skipped: [list]. Look for anything new we haven't considered."
-
-Read their updated working files and repeat the curate → walk through → offer another pass cycle until user is satisfied.
-
-## Complete the Interview
-
-Once user confirms no more review passes needed:
-
-1. Show the user the final spec
-2. Use AskUserQuestion to confirm they are satisfied
-3. Ask if they want to proceed to task breakdown
-4. Shutdown the team:
-   - Send shutdown requests to all three teammates (researcher, critic, pragmatist) via SendMessage with type "shutdown_request"
-   - After all teammates confirm shutdown, use TeamDelete to clean up team resources
-   - The `{spec_dir}/working/` directory remains on disk as reference for implementation
-
-If yes to task breakdown, invoke `spec-to-tasks` and specify which spec to break down.
-
-Use the Read tool on `references/step-8-reflect.md` to reflect on the interview process and note any skill issues.

package/src/skills/spec-interview/references/step-8-reflect.md

@@ -1,32 +0,0 @@
-# Step 8: Reflect and Improve
-
-Reflect on this spec interview to improve the skill itself.
-
-## Assess
-
-Answer these questions honestly:
-
-1. Were any interview steps wrong, incomplete, or misleading? Did any step send you down a wrong path or leave out critical guidance?
-2. Did the team coordination work smoothly? Were the checkpoint patterns (post-ideation, deep dive, finalize) at the right moments? Did any teammate produce findings too late or too early to be useful?
-3. Did the prompt templates (researcher, critic, pragmatist) give adequate direction? Did any teammate misunderstand its role or produce unhelpful output?
-4. Did you discover a question sequence, interview technique, or spec structure that worked better than what the skill prescribed?
-5. Did any commands, paths, tool interactions, or team communication patterns fail and require correction?
-6. Was the step ordering right? Should any steps be reordered, merged, or split?
-
-## Act
-
-If you identified issues above, fix them now:
-
-1. Identify the specific file in the spec-interview skill where the issue lives
-2. Read that file
-3. Apply the fix -- add what was missing, correct what was wrong
-4. Apply the tribal knowledge test: only add what a fresh Claude instance would not already know about conducting spec interviews or coordinating agent teams
-5. Keep the file within its size target
-
-If no issues were found, confirm that to the user.
-
-## Report
-
-Tell the user:
-- What you changed in the spec-interview skill and why, OR
-- That no updates were needed and the skill performed correctly

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

@@ -1,91 +0,0 @@
----
-name: spec-review
-description: Review a feature spec for completeness and implementation readiness. Checks data models, integration points, acceptance criteria, CLAUDE.md alignment, and duplication.
-argument-hint: <spec-name>
-context: fork
----
-
-# Spec Review
-
-## Find the Spec
-
-Use the path from the prompt if provided. Otherwise, find the most recently modified file in `docs/specs/`. If no specs exist, inform the user and stop.
-
-## Read Context
-
-Read the spec file and all CLAUDE.md files in the project (root and subdirectories). CLAUDE.md files contain project constraints and conventions to check alignment against.
-
-## Evaluate Against Checklist
-
-A spec is implementation-ready when ALL of these are satisfied:
-
-### Must Have (Blocking if missing)
-
-- [ ] **Clear intent** - What is being built and why is unambiguous
-- [ ] **Data model defined** - Entities, relationships, and constraints are explicit
-- [ ] **Integration points mapped** - What existing code this touches is documented
-- [ ] **Core behavior specified** - Main flows are step-by-step clear
-- [ ] **Acceptance criteria exist** - Testable requirements are listed
-- [ ] **Verification methods defined** - Every acceptance criterion has a specific way to verify it (test command, agent-browser steps, or explicit check)
-- [ ] **No ambiguities** - Nothing requires interpretation; all requirements are explicit
-- [ ] **No unknowns** - All information needed for implementation is present; nothing left to discover
-- [ ] **CLAUDE.md alignment** - Spec does not conflict with constraints in any CLAUDE.md file
-- [ ] **No internal duplication** - File Landscape contains no sets of new files that serve similar purposes and could share a common implementation
-
-### Should Have (Gaps that cause implementation friction)
-
-- [ ] **Edge cases covered** - Error conditions and boundaries are addressed
-- [ ] **External dependencies documented** - APIs, libraries, services are listed
-- [ ] **Blockers section exists** - Missing credentials, pending decisions are called out
-- [ ] **UI/UX wireframes exist** - If feature has a user interface, ASCII wireframes are present
-- [ ] **Design direction documented** - If feature has UI, visual approach is explicit (not assumed)
-
-### Implementation Readiness
-
-The test: could an agent implement this feature with ZERO assumptions? If the agent would need to guess, interpret, or discover anything, the spec is not ready.
-
-Flag these problems:
-- Vague language ("should handle errors appropriately" — HOW?)
-- Missing details ("integrates with auth" — WHERE? HOW?)
-- Unstated assumptions ("uses the standard pattern" — WHICH pattern?)
-- Blocking dependencies ("needs API access" — DO WE HAVE IT?)
-- Unverifiable criteria ("dashboard works correctly" — HOW DO WE CHECK?)
-- Missing verification ("loads fast" — WHAT COMMAND PROVES IT?)
-- Implicit knowledge ("depends on how X works" — SPECIFY IT)
-- Unverified claims ("the API returns..." — HAS THIS BEEN CONFIRMED?)
-- CLAUDE.md conflicts (spec proposes X but CLAUDE.md requires Y — WHICH IS IT?)
-- Near-duplicate new components (three card components for different pages — CONSOLIDATE into one shared component with props/configuration)
-
-## Output Format
-
-Return the review as:
-
-```
-## Spec Review: [Feature Name]
-
-### Status: [READY | NEEDS WORK]
-
-### Missing (Blocking)
-- [Item]: [What's missing and why it blocks implementation]
-
-### CLAUDE.md Conflicts
-- [Constraint from CLAUDE.md]: [How the spec conflicts with it]
-
-### Gaps (Non-blocking but should address)
-- [Item]: [What's unclear or incomplete]
-
-### Duplication Concerns
-- [Group of similar new files/components]: [How they overlap and consolidation recommendation]
-
-### Blocking Dependencies
-- [Dependency]: [What's needed before implementation can start]
-
-### Skill Observations (optional)
-If any checklist items, evaluation criteria, or output format instructions in this skill were wrong, incomplete, or misleading during this review, note them here. Leave empty if no issues were found.
-
-### Recommendation
-[Specific questions to ask the user, or "Spec is implementation-ready"]
-```
-
-**READY**: Spec can proceed to task breakdown.
-**NEEDS WORK**: List specific questions that need answers.

package/src/skills/spec-sanity-check/SKILL.md

@@ -1,82 +0,0 @@
----
-name: spec-sanity-check
-description: Fresh-eyes review of a spec's logic and assumptions. Checks for logic gaps, incorrect assumptions about existing systems, unconsidered scenarios, and implementation pitfalls.
-argument-hint: <spec-path>
-context: fork
----
-
-# Spec Sanity Check
-
-Review the spec with fresh eyes. Focus on whether the plan will actually work, not format or completeness.
-
-## Find the Spec
-
-Use the path from the prompt if provided. Otherwise, find the most recently modified file in `docs/specs/`. If no specs exist, inform the user and stop.
-
-## Read and Understand
-
-Read the entire spec. Understand what is being built and how.
-
-## Ask These Questions
-
-For each section of the spec, challenge it:
-
-### Logic Gaps
-- Does the described flow actually work end-to-end?
-- Are there steps that assume a previous step succeeded without checking?
-- Are there circular dependencies?
-- Does the order of operations make sense?
-
-### Incorrect Assumptions
-- Are there assumptions about how existing systems work that might be wrong?
-- Are there assumptions about external APIs, libraries, or services?
-- Are there assumptions about data formats or availability?
-- Use Explorer subagents to verify assumptions against the actual codebase
-
-### Unconsidered Scenarios
-- What happens in edge cases not explicitly covered?
-- What happens under load or at scale?
-- What happens if external dependencies fail?
-- What happens if data is malformed or missing?
-
-### Implementation Pitfalls
-- Are there common bugs this approach would likely introduce?
-- Are there security implications not addressed?
-- Are there performance implications not addressed?
-- Are there race conditions or timing issues?
-
-### The "What If" Test
-- What if [key assumption] is wrong?
-- What if [external dependency] changes?
-- What if [data volume] is 10x what we expect?
-
-## Output Format
-
-Return findings as:
-
-```
-## Sanity Check: [Feature Name]
-
-### Status: [SOUND | CONCERNS]
-
-### Logic Issues
-- [Issue]: [Why this is a problem]
-
-### Questionable Assumptions
-- [Assumption]: [Why this might be wrong] [Suggestion to verify]
-
-### Unconsidered Scenarios
-- [Scenario]: [What could go wrong]
-
-### Potential Pitfalls
-- [Pitfall]: [How to avoid]
-
-### Skill Observations (optional)
-If any evaluation questions, check categories, or output format instructions in this skill were wrong, incomplete, or misleading during this review, note them here. Leave empty if no issues were found.
-
-### Recommendation
-[Either "Plan is sound" or specific concerns to address]
-```
-
-**SOUND**: No significant concerns found.
-**CONCERNS**: Issues that should be addressed before implementation.

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

@@ -1,24 +0,0 @@
----
-name: spec-to-tasks
-description: Converts a feature specification into implementation tasks. Use after a spec is complete and approved, or when planning work for a defined feature.
-argument-hint: <spec-name>
-context: fork
----
-
-# Spec to Tasks
-
-## Workflow Overview
-
-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. **Draft Tasks** - Create draft task files in `tasks/` directory
-4. **Review and Present** - Review drafts, auto-fix issues, then present final results to the user
-5. **Reflect** - Note any skill issues observed during this run
-
-Step 4 is where you present results to the user. Step 3 produces drafts; step 4 reviews, fixes, and presents them.
-
-## What To Do Now
-
-Read `references/step-1-identify-spec.md` and begin.

package/src/skills/spec-to-tasks/references/step-1-identify-spec.md

@@ -1,39 +0,0 @@
-# Step 1: Identify the Spec
-
-Locate the specification to convert into tasks.
-
-## If Spec Path Provided
-
-Use the path from the user's prompt. Verify the file exists and read it.
-
-## If No Path Provided
-
-Find the most recently modified spec:
-
-```bash
-git log -1 --name-only --diff-filter=AM -- 'docs/specs/**/*.md' | tail -1
-```
-
-If no specs found in git history, check `docs/specs/` for any spec files and ask the user which one to use.
-
-## Verify the Spec
-
-Read the spec file. Confirm it contains enough detail to generate implementation tasks:
-
-**Required:**
-- Acceptance Criteria with verification methods (each criterion becomes a task)
-- Clear behavior descriptions
-
-**Expected (from spec-interview):**
-- File Landscape section listing files to create/modify
-- Integration points and data model
-
-**If missing acceptance criteria or verification methods:**
-Inform the user: "This spec doesn't have acceptance criteria with verification methods. Each task needs a clear pass/fail test. Would you like to add them now, or run spec-interview to complete the spec?"
-
-**If missing file landscape:**
-Proceed to step 2 where we'll discover file paths via exploration.
-
-## Next Step
-
-Once the spec is identified and verified, read `references/step-2-explore.md`.

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,67 +0,0 @@
-# Step 3: Draft Task Files
-
-Create draft task files based on the spec and codebase exploration. These are drafts — you will review, fix, and present them in the next step.
-
-## 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.
-
-After writing all draft task files, use the Read tool on `references/step-4-review.md` to review and present your results to the user.
-
-## Continue to Review
-
-Draft task files are ready. Use the Read tool on `references/step-4-review.md` now — that is where you review the drafts and present the final results to the user.

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

@@ -1,90 +0,0 @@
-# Step 4: Review and Present Tasks
-
-Review the draft tasks, auto-fix all issues, then present the final results to the user. This is the step where the user sees your output.
-
-This is fully automated — fix every issue you find without asking the user. Do not ask 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 and Fix Loop
-
-Run the checklist above against all task files. Fix every issue you find — Critical, Warning, and fixable Notes — by editing the task files directly. Then re-run the full checklist from the top. Repeat until no issues remain.
-
-Do not present results until the loop is clean.
-
-## Present Results to User
-
-After the review loop completes clean, present:
-
-1. Number of tasks generated
-2. Task dependency tree (visual format)
-3. Summary of review findings and fixes applied (what you found, what you fixed)
-
-**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, auto-fix all issues found, and report what was fixed.
-
-## 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 run the review-and-fix loop.