Verify agent work before accepting it

A confident completion message is not evidence that a change works. Verify the resulting state with the project's checks, review the actual diff, and independently rederive claims that will drive important decisions.

Start with observable evidenceCopy Anchor Link

Fix the failing parser case. Show the regression test, run the targeted tests and typecheck after the final edit, and report any checks you could not run.

git status --short
git diff
git diff --staged

Choose the right workflowCopy Anchor Link

The following skills are contributed by the bundled skill collection. Check /help or bundled skills if one is unavailable in your session.

Review and verification consume model time and quota, especially when they dispatch several agents. Scope the target and the claims that matter rather than asking for unlimited review.

Review a diff with /reviewCopy Anchor Link

/review
/review --staged
/review --head

No argument reviews working-tree changes relative to HEAD, not just staged changes. --staged narrows the target to the index. You can also provide a PR number or URL, commit SHA, branch, or patch path. Give the intended behavior with --brief or --spec when the diff does not explain it:

/review --staged --brief "Keep existing parser behavior, but reject duplicate keys."

The review covers security, correctness, API compatibility, test coverage, performance, observability, and compliance with stated intent. Smaller changes can use a lighter reviewer; larger changes use parallel dimension agents and a synthesis step. Findings should identify specific evidence and a severity, not merely say the code looks good.

/review is read-only: it does not fix files, commit, push, comment on a PR, or edit its description. Its narrowly defined merge offer still requires your explicit confirmation. It can skip unsuitable targets such as generated or pure-documentation diffs.

Treat a recommendation as review evidence, not a test result. A static review cannot prove an unexecuted test passed or an external deployment succeeded.

Independently check claims with /shadow-verifyCopy Anchor Link

Use this after an investigation or review when its conclusions will drive edits or other high-stakes actions:

/shadow-verify
/shadow-verify --findings-list findings.md

The default mode selects two or three high-stakes, concrete claims from the preceding findings. --findings-list asks for an explicit checklist across a supplied findings document rather than sampling a few claims.

A verifier should derive the answer from primary evidence without inheriting the original agent's reasoning. It needs the relevant search surface, but not a conclusion it is expected to confirm.

The workflow also flags unchecked composition boundaries or verification that only reread the same artifact without independent evidence. A verifier that runs out of budget is not a successful confirmation.

Confidence is a reason to check a claim, not a verdict. Some orchestrators use a separate confidence gate: low confidence, declared coverage gaps, or a boundary flag request verification. Do not assume every confident sentence is mechanically intercepted everywhere.

Ship completed work with /ship --verifyCopy Anchor Link

/ship --verify

This is a release workflow, not a read-only check. It runs preflight and project checks, drafts and creates a commit, pushes the feature branch, and opens a pull request. Use it only when the local work is ready for that external handoff.

--verify forces the optional adversarial wave even for a small diff. The skill also requests that wave automatically for a cumulative diff over 100 changed lines. A contradictory verifier result is surfaced before opening the PR so you can decide whether to proceed, revise, or abort.

The shipping skill aborts on failed test, typecheck, or lint gates, records skipped checks separately, and refuses to push to the default branch. It is not a replacement for your repository's CI or branch-protection rules.

Understand afk's evidence signalsCopy Anchor Link

The runtime can distinguish a turn with no code changes, a turn with post-change verification, and one with changes but no recognized verification afterward. Stop hooks can use this evidence to ask for a correction, and surfaces can indicate that a completion lacks corroboration.

These are conservative heuristics over observed tool events and command shapes, not a proof of correctness. A command can look like a test while covering the wrong behavior. Delegated work also has its own evidence stream. Ask for concrete artifacts and inspect the final state rather than relying only on a status label.

Design for a better failure modeCopy Anchor Link

The failure-geometry pattern is a way to make failure earlier, smaller, louder, cheaper, more local, more informative, or easier to recover from. It is not a separate /failure-geometry command or a runtime guarantee.

Use four questions when writing a custom skill:

1. Name the default failure. What happens without hardening? For example, malformed output gets accepted or a blocked action retries forever.
2. Choose the preferred failure. Should the workflow reject, pause in a named state, or ask for a decision?
3. Add structure. Use a parser, gate, bounded retry, rubric, or explicit output contract. A comment promising care is not enforcement.
4. Verify the signal. Exercise the failure path and check that the user or caller can see it.

Examples in afk include confidence-gated rechecking, explicit coverage and boundary fields, and abort propagation where a parent can cancel children without a child automatically cancelling its parent. When a skill reaches its own iteration limit, report a partial or blocked result with a resumption path rather than disguising it as success.

Before relying on a new skill, record its expected breakage patterns and test both the happy path and the intended failure path.

RelatedCopy Anchor Link