ctx-implement

Take a plan (inline text, file path, or from the conversation) and execute it step-by-step with build/test verification between steps.

When to Use

• When the user provides a plan document or file and says "implement this"
• When a multi-step task has been planned and needs disciplined execution
• When the user wants checkpointed progress with verification at each step
• After /ctx-brainstorm or plan mode produces an approved plan

When NOT to Use

• For single-step tasks: just do them directly
• When the plan is vague or incomplete: use /ctx-brainstorm first to refine it
• When the user wants to explore or discuss, not execute
• When changes are trivial (typo fix, config tweak)

Usage Examples

/ctx-implement
/ctx-implement path/to/plan.md
/ctx-implement (the plan from our discussion above)

Process

1. Load the plan

• If a file path is provided, read it
• If inline text is provided, use it directly
• If neither, look back in the conversation for the most recent plan or approved design
• If no plan can be found, ask the user for one

2. Break into steps

Parse the plan into discrete, checkable steps. Each step should be:

• Atomic: one logical change (a file, a function, a test)
• Verifiable: has a clear pass/fail check
• Ordered: dependencies respected (create before use, test after implement)

Present the step list to the user for confirmation:

Implementation plan (N steps):

1. [Step description] - verify: [check]
2. [Step description] - verify: [check]
3. ...

Ready to start?

3. Execute step-by-step

For each step:

1. Announce what you're doing (one line)
2. Think through the change before writing code: what does it touch, what could break, what's the simplest correct path?
3. Implement the change
4. Verify with the appropriate check:
   • Go code changed → CGO_ENABLED=0 go build -o /dev/null ./cmd/ctx
   • Tests affected → CGO_ENABLED=0 go test ./...
   • Config/template changed → build to verify embeds
   • Docs only → no verification needed
5. Report step result: pass or fail
6. If failed: stop, diagnose, fix, re-verify before moving to the next step

Verify after every individual step before proceeding to the next.

4. Checkpoint progress

After every 3-5 steps (or after a significant milestone):

• Summarize what has been completed
• Note any deviations from the plan
• Ask the user if they want to continue, adjust, or stop

5. Wrap up

After all steps complete:

• Run a final full verification (make check or CGO_ENABLED=0 go build && go test ./...)
• Summarize what was implemented
• Note any deviations from the original plan
• Suggest context to persist (decisions, learnings, tasks)

Step Verification Map

Change type	Verification command
Go source code	CGO_ENABLED=0 go build -o /dev/null ./cmd/ctx
Test files	CGO_ENABLED=0 go test ./...
Templates/embeds	CGO_ENABLED=0 go build -o /dev/null ./cmd/ctx
Makefile	Run the new/changed target
Skill files	Build (to verify embed) + check live copy matches
Docs/markdown only	None required
Shell scripts	bash -n script.sh (syntax check)

Handling Failures

When a step fails verification:

1. Don't panic: read the error output carefully
2. Reason through the failure step-by-step before attempting a fix; understand the cause, not just the symptom
3. Fix the issue in the current step
4. Re-verify the fix
5. Only then move to the next step
6. If the fix changes the plan, note the deviation

If a step fails repeatedly (3+ attempts), stop and ask the user for guidance rather than thrashing.

Output Format

Progress updates should be concise:

Step 1/6: Create ctx-next skill directory .......... OK
Step 2/6: Write SKILL.md template .................. OK
Step 3/6: Copy to live skill directory ............. OK
Step 4/6: Build to verify template embeds .......... OK
Step 5/6: Run tests ................................ OK
Step 6/6: Mark task in TASKS.md .................... OK

All 6 steps complete. Build and tests pass.

Examples

Good Implementation

Step 3/8: Add check target to Makefile Added check: build audit after the audit target. Verify: make check ... build OK, audit OK. Result: PASS

Bad Implementation

"I'll implement the whole plan now" [makes all changes at once without verification] "Done! Everything should work."

(No step-by-step, no verification, no checkpoints: this defeats the purpose of the skill.)

Quality Checklist

Before starting, verify:

• Plan exists and is clear enough to execute
• Steps are broken down and presented to the user
• User confirmed readiness to proceed

During execution, verify:

• Each step is verified before moving on
• Failures are fixed in place, not deferred
• Checkpoints happen every 3-5 steps

After completion, verify:

• Final full verification passes
• Deviations from plan are noted
• Summary of what was implemented is presented
• Context persistence is suggested if warranted