Menu
Implement an approved request or plan using project conventions and proportionate verification. Runs only on an explicit CoderKit implement request.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Verify repository state and perform explicitly authorized Git and publication actions: commit, push, pull request, tag, release, or deploy. Runs only on an explicit CoderKit commit request.
Reproduce unexpected behavior, trace the real path, and isolate the root cause before an authorized fix. Runs only on an explicit CoderKit debug request.
Understand the code and the solution space: trace real flows, compare genuinely different approaches, and choose a direction. Runs only on an explicit CoderKit explore request.
Implement an approved request or plan using project conventions and proportionate verification. Runs only on an explicit CoderKit implement request.
Inspect the actual project and create an actionable, evidence-grounded implementation plan without editing implementation files. Runs only on an explicit CoderKit plan request.
Run real checks and review the change: tests, typecheck, runtime exercise, plus correctness, security, and regression findings. Runs only on an explicit CoderKit verify request.
| name | implement |
| description | Implement an approved request or plan using project conventions and proportionate verification. Runs only on an explicit CoderKit implement request. |
Run this workflow only when the user explicitly requests CoderKit and names this tool. Do not suggest, infer, or auto-select it from task context. If it was selected without an explicit request, continue with normal host behavior without applying or mentioning CoderKit.
Structure the work in this order:
Ask only when missing information materially changes the result or required authority. Accept steering without restarting the workflow.
Right-size the workflow to the task. Use a fast path when the outcome and evidence are obvious; use deeper investigation only when uncertainty, risk, or scope warrants it. Do not create documents, dispatch agents, add process infrastructure, or expand test coverage merely because the workflow can — the work artifacts below are the one exception: they are mandated completion evidence, not discretionary documents. Stop when the completion evidence is satisfied. A finished, verified result is better than a perfect process.
Treat user-named files, URLs, tools, and prior artifacts as authoritative inputs: inspect them before substituting a generic alternative. Keep tangential cleanup and speculative improvements out of the active scope unless the user asks for them.
Persistent work products live in the target project under docs/work/NNN-short-name/: NNN is a zero-padded index allocated as the highest existing index plus one (starting at 000), and short-name is a kebab-case name derived from the request.
plan.md — written by plan whenever it runs; the stable contract later tools read as authority.tasks.md — created and maintained by implement from the plan's units: main tasks, subtasks, and any subagent or orchestration assignments, with statuses updated as work progresses.tasks/ — optional subfolder, created only when a single task needs a dedicated brief (for example a subagent fan-out).Explore produces no artifact. Tools other than plan and implement read these files but do not create them.
Finish with the evidence required by this tool, then name the natural next step — the next CoderKit tool in the workflow when one applies (explore → plan → implement → verify → commit, with debug for unexpected behavior), or nothing when the work is complete. Offer it as a suggestion the user can invoke; never invoke another CoderKit tool yourself, and never start the suggested work. This applies only at the end of an explicitly requested workflow: outside one, do not suggest CoderKit tools at all.
docs/work/ folder matching the request) and on first run seed tasks.md from the plan's units: main tasks, subtasks, and any subagent or orchestration assignments. Requests without a plan document stay artifact-free.tasks.md and record deviations and discoveries there. Split a task into a tasks/ brief only when it needs dedicated instructions, such as a subagent fan-out.Stop when the requested behavior is implemented, the proportional checks pass, and the diff contains only intended work. Do not add another review cycle or supporting system without a concrete unresolved risk.
Changed files, relevant runnable checks with results, and an up-to-date tasks.md when a plan document exists.