implement

name	implement
description	Use for substantive code changes where a structured build loop adds value. Implement the approved request or plan with proportionate verification; skip for trivial edits.
argument-hint	[request or context]

Contextual selection

CoderKit is an optional helper framework, not a mandatory process. Self-select this workflow when the current request clearly matches its purpose and the added structure will materially improve a substantive development task. Never ask the user whether to activate CoderKit or whether to use CoderKit instead of normal host behavior: workflow selection is an internal execution decision, not a user decision.

Skip CoderKit for simple questions, routine commands, obvious one-line edits, or work whose outcome and path are already clear. Select only the smallest useful workflow; do not run the full explore → plan → implement → verify → commit sequence as ceremony. When no workflow adds enough value to justify its overhead, continue with normal host behavior.

Ask only when the outcome, scope, or required authority is materially unclear; never ask merely to choose or confirm a workflow. Automatic selection does not expand the user's authority or permit adjacent work.

Prompting envelope

Structure the work in this order:

• Outcome: state the result the user wants before choosing an approach.
• Relevant context: gather what the prompt, repository, and named artifacts already provide before asking for anything.
• Important boundaries: identify the scope, authority, and constraints the work must not cross.
• Work: execute against the outcome within those boundaries.
• Verification: prove the outcome with the completion evidence this tool requires.

Ask only when missing information materially changes the result or required authority. Accept steering without restarting the workflow.

Proportionality

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.

Work artifacts

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.

Completion

Finish with the evidence required by this tool. Select another CoderKit workflow only when it is genuinely needed and the user's existing request already authorizes that work; never chain the whole lifecycle by default. Otherwise stop and report the result or natural next step without asking the user to activate anything. Never turn workflow selection into a confirmation prompt, and never treat automatic selection as authorization for Git publication, deployment, destructive changes, or other adjacent work.

Implement

Method

1. Triage the input: follow an approved plan when one exists; otherwise derive the smallest executable scope directly from the request. Stop and surface a contradiction if the plan no longer matches repository reality.
2. When following a plan document, locate its work folder (user-named, or the highest-index 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.
3. Inspect repository instructions, named references, relevant implementation, callers, tests, and working-tree state before editing.
4. Preserve unrelated work. Reuse existing code and conventions before adding dependencies, abstractions, files, or infrastructure.
5. Implement the smallest complete vertical change. Work in coherent batches and keep the application runnable between them when practical.
6. As each batch completes, update statuses in 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.
7. Validate trust boundaries and handle failures that could cause data loss, insecure behavior, or misleading success. Avoid defensive complexity for impossible internal states.
8. Add or update the smallest check that proves changed behavior. Characterize legacy behavior before changing it when regression risk is material.
9. Run focused verification after the change, then only the broader checks justified by its reach and risk. Fix relevant failures immediately; do not accumulate a speculative test matrix.
10. Inspect the final diff for accidental scope, dead code, debug output, generated drift, and incomplete work. Finish the requested feature rather than stopping at an internal milestone.

Stop conditions

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.

Completion evidence

Changed files, relevant runnable checks with results, and an up-to-date tasks.md when a plan document exists.