verify

name	verify
description	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.

Explicit activation

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.

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, 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.

Verify

Two roles in one pass: run the checks the agent can actually run, and review the change the checks cannot judge.

Method

1. Resolve what is under verification: the change or claim, its requirements or plan, base and head, and what "working" concretely means for it. When the user names no scope, default to the working-tree diff against the merge base with the default branch.
2. Run proportional checks in escalating order: focused tests, typecheck or lint, build, then exercising the real flow at runtime, with screenshots or output where the behavior is visual. Capture actual output; never infer a result from reading code alone, and never report a check as passing without having run it.
3. Review what checks cannot judge: read the diff in context, then inspect the affected callers, interfaces, tests, trust boundaries, and adjacent behavior needed to evaluate a concrete risk.
4. Prioritize correctness, security, data loss, regressions, and missing requirements. Review maintainability only where it creates a concrete future failure or disproportionate complexity. Separate introduced problems from pre-existing conditions.
5. For every finding, provide severity, confidence, precise location, triggering condition, impact, and an actionable correction. Verify the surrounding code before reporting it.
6. Do not duplicate formatter or linter output, invent speculative edge cases without a plausible path, or turn personal style preference into a defect.
7. Report faithfully: a failing check or a defect is a finding, not an invitation to silently fix. Remain read-only unless the user asks for fixes.
8. Calibrate the verdict to the actual scope: ready, ready with specific fixes, or not ready. List verification gaps and residual risks separately from defects, then stop.

Quality bar

A short report with two proven findings and real command output is better than a long one padded with possibilities. When clean, state that the checks pass and no material findings remain, and name any limits plainly.

Completion evidence

Commands run with actual output, prioritized findings, and a calibrated verdict.