skills/develop/SKILL.md
Execute implementation from a plan or spec file. Reads the plan phases, dispatches workers with full spec context, verifies each against the spec. Triggers: 'develop', 'execute the plan', 'build this', 'implement this spec'.
npx skillsauth add luan/dot-claude developInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Read a plan (preferred) or spec, dispatch workers per phase, verify each worker's output against the spec.
<path> — path to plan file (preferred) or spec file--auto — skip user confirmations (for vibe/supervibe calls)ct plan latest. If no plan, fall back to ct spec latest.If content is already in your conversation (from a preceding /spec call), use it directly.
Plan file provided (preferred path):
PLAN_CONTENT=$(ct plan read <path>)
The plan's frontmatter contains source: linking to its spec. Read the spec too — workers need both:
SPEC_CONTENT=$(ct spec read <spec-stem>)
Spec file provided (no plan):
SPEC_CONTENT=$(ct spec read <path>)
Decompose into tasks yourself (Step 2 fallback).
Extract reviewer annotations: Run ct spec comments <spec-file> and (if plan exists) ct plan comments <plan-file>. If either returns comments, store them — they'll be appended to worker prompts in Step 3.
If the file doesn't exist or is empty, report and stop.
From plan file: Parse phase markers directly into tasks. Each phase becomes one task. The plan already specifies files, approach, steps, and dependencies — use them as-is.
From spec file (fallback): Break the spec into implementation tasks. Use the Architecture Context to determine natural boundaries (files, modules, layers). For each task, note:
Create a task list: After decomposing, create a TaskCreate entry for each phase/task. This gives the user visible progress tracking throughout execution. Set dependencies between tasks using addBlockedBy to reflect the plan's dependency graph. Mark each task in_progress when its worker starts and completed when it passes spec compliance.
For each ready task, spawn an Agent with the worker prompt below. Cap: 4 concurrent workers. Dispatch unblocked tasks in parallel, re-dispatch as tasks complete and unblock others. Single task → one worker.
Implement this phase.
## Phase
<phase title, files, approach, steps from plan>
## Full Spec
<entire spec content — Problem, Recommendation, Architecture Context, Risks>
## Your Workflow
1. Read the files listed in the phase (Modify + Create paths)
2. Write a failing test that describes the target behavior
3. Run the test — confirm it fails for the right reason (missing method, wrong behavior — not random error)
4. Implement the minimum code to make the test pass
5. Run all tests — confirm green
6. Run the project build command — confirm it compiles
7. Run the phase's verification step if specified
8. Report completion with a summary of what you implemented
## Reviewer Annotations
<if spec or plan had inline comments, include them here>
Address these in your implementation.
## If blocked
- Design conflict with the spec → report "RESCOPE: <reason>" and stop
- Task too large → break it down and report the subtasks
Workers get the full spec text plus their phase details from the plan. The spec provides the "why", the plan provides the "how". Both fit in a worker's context.
After each worker completes, spawn a reviewer Agent:
Review this implementation against the spec.
## Spec
<full spec content>
## Changes
<git diff for this worker's changes>
## Check
1. Does the implementation match the Recommendation section?
2. Does it fit the Architecture Context (right files, right patterns)?
3. Are the Risks addressed or acknowledged?
Output: PASS or FAIL with specific citations.
If FAIL: list exactly what doesn't match and what should change.
PASS → mark task complete, dispatch next worker. FAIL → send feedback to the worker, worker fixes, re-review. Max 2 fix cycles per worker.
After all workers complete and pass spec compliance:
git add -u, show git diff --cached --stat.Output:
Develop: <spec topic>
Workers: N/N completed, all passed spec compliance
Files changed: <list>
Next: verify the implementation, then /crit and /commit
tools
Tree-sitter indexed code navigator (ct sym CLI). Use INSTEAD OF Read/Grep/Glob/Bash when exploring existing code, understanding how something works, locating a symbol, tracing the call graph up (impact) or down (trace), finding implementations of an interface, scoping a diff to one symbol, or preparing to edit code you have not read yet. Triggers: 'how does X work', 'explain this class/file/symbol', 'walk me through X', 'what does X do', 'where is X defined', 'who calls X', 'what does X call', 'find implementations of', 'what breaks if I change X', 'outline this file', 'map imports', 'show me this symbol', exploring unfamiliar repo, tracing call graph, scoping diff to a symbol, preparing to edit code I haven't read, about to Read a file over ~500 lines to understand it. Do NOT use for: writing new code from scratch, editing prose or config, running tests, or when a stack trace already names the file and line.
development
Fully autonomous development workflow from prompt to commit. Chains spec → develop → review → commit. Triggers: /vibe, 'vibe this', 'autonomous workflow', 'just do it all', 'build this end-to-end', 'full pipeline', 'handle everything'.
development
Comprehensive vault maintenance — cross-references blueprints against codebase state to produce a maintenance plan: archive consumed artifacts, audit docs for staleness, propose new docs for undocumented stable systems. Triggers: 'vault sweep', 'sweep the vault', 'clean up vault', 'vault maintenance', 'what can we archive', 'audit blueprints', 'vault hygiene', 'blueprint cleanup'. Use whenever the user wants a holistic view of vault health rather than archiving a single artifact (that's /archive). Also use when the user asks what's stale, what needs docs, or whether artifacts can be cleaned up.
development
Analyze current diff, classify changes by risk, and produce structured manual test plan. Triggers: 'test plan', 'what should I test', 'manual testing', 'verification steps', 'QA checklist'. Exits early for trivial changes. Do NOT use when: writing automated tests — use /develop with TDD. Do NOT use when: reviewing code quality — use /crit instead.