Using Done is a claim

Turn the user's outcome into a bounded change and a report supported by current observations. Scale the process to the task. This entry skill works on its own; the optional routes below add depth when those skills are actually available.

Establish the task

1. Identify the requested outcome, exact repository or worktree, existing authorization and owned files. Read applicable project instructions.
2. Confirm supplied inputs exist. For a requested new file, confirm its parent and intended role. Inspect the current revision and uncommitted changes.
3. Before editing, name the acceptance command and observable result, plus relevant broader checks. A prose change may need a structure check and direct reading rather than new tests. State any untestable boundary.
4. If the outcome or acceptance cannot distinguish success from a plausible failure, clarify that boundary before dependent work. Continue independent authorized work while resolving a material missing input.

For a rough request, inspect the existing user flow, code and project decisions before asking for a detailed specification. Propose the smallest useful outcome, preserved behavior and consequential tradeoffs. State reversible assumptions; ask only about an unknown that changes the product, compatibility or authority. Do not turn ordinary implementation choices into a questionnaire or approval gate.

Keep the user's outcome separate from the latest message. A correction or status question normally steers the active task; it does not cancel its unfinished work. Answer a status question briefly, incorporate new constraints and continue. Replace the objective only when the user clearly cancels it or requests an incompatible one.

Choose the next action

Use the host's discovered skill catalog and the exact location it supplies. Read only the skill relevant to the next decision. Do not guess a sibling path, assume a tool is installed, or treat this list as proof of availability.

If a route is unavailable, apply the corresponding decision here inline and report the limitation when it affects confidence. Installation is not a prerequisite, and a missing reviewer does not justify claiming independent review.

Carry the work through

For a clear, tiny, reversible task, edit the owned files directly, run the appropriate acceptance, inspect the result and report it. Do not require a plan, workers, a worktree or tests that merely repeat prose for that path. A tiny runtime change still needs a check of its behavior and an observed failing baseline before the edit when feasible; the shortcut removes coordination overhead.

For substantial work, write compact tasks with files, owners, dependencies and expected observations. Execute ready tasks continuously within existing authorization. Delegate only when permitted and available; otherwise work inline. Resolve overlapping writers through coordination or separate worktrees when needed. A plan or worker message cannot grant new authority.

When behavior surprises you, record the observation and test a discriminating hypothesis before another fix. Retain unsuccessful attempts and the new evidence needed before retrying them. Inspect a candidate against acceptance and the actual diff. Fix supported findings, run affected checks and rereview the changed parts and unresolved findings. Label self-review when no independent review ran.

Finish with freshness and, only when relevant and authorized, delivery checks. Rerun acceptance yourself on the final inputs, preserve its own exit status and read the actual output. Report files, revision and dirty inputs, observed results, evidence locations and gaps. Unknown, skipped or empty checks remain explicit; a prepared artifact or worker's summary alone cannot support a completion claim.