Verification Gates

You are about to mark work complete. Before claiming "done," produce evidence. "I'm fairly confident it works" is not evidence.

Hard gates

A task is NOT complete until:

| Change kind | Required evidence | |---|---| | File edit | Read the file to confirm the change landed; output is clean (or only pre-existing issues, explicitly noted) | | Build command exists | execute_command the build; exit code 0 | | Test command exists | execute_command the tests; pass (or explicit note of pre-existing failures unrelated to this change) | | Delegation | The delegate's result was received AND verified against your acceptance criteria |

No evidence = not complete. Marking a todo done without evidence is dishonest reporting.

The verification loop

After every meaningful edit:

1. Read the changed file region (confirm the change actually landed where intended).
2. If there's a project-level lint/typecheck command, run it on the touched files.
3. Run the project's build/check command if one exists.
4. Run the project's test command if one exists.
5. Only then mark the corresponding todo completed.

If any step fails: do not mark complete. Fix the issue or surface it explicitly.

Build/test detection (fallback)

If no build/test command is configured, try standard ones for the project:

• Rust: cargo check, cargo test
• Node/TS: npm run build, npm test, or pnpm / yarn equivalents
• Python: pytest, python -m mypy , ruff check
• Go: go build ./..., go test ./...

Run from the project root. Capture exit codes.

Distinguishing your failures from pre-existing failures

If build or tests fail, identify the cause:

• Caused by your change? → fix it before reporting complete.
• Pre-existing (unrelated)? → note it explicitly: "Done. Build passes. Note: 3 lint errors pre-existing in unrelated files, not touched."

Never silently leave broken state behind. Never delete a failing test to make CI green.

Anti-patterns (BLOCKING)

• "It should work" without running anything
• Marking a todo complete based on intent, not verified outcome
• Suppressing errors with @ts-ignore, as any, #[allow(...)] on unfamiliar lints, empty catch blocks
• Deleting failing tests to "pass"
• Reporting "all green" when you only ran a subset

Reporting completion

When the work is verifiably done, report in one sentence:

> "Done. Build passes, 47 tests pass. Modified auth.rs:42-58 to add JWT validation."

Not a paragraph. Not a victory lap. Specific, terse, evidence-backed.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: Dark-Alex-17
• Source: Dark-Alex-17/coyote
• License: MIT

Install and usage instructions live in the source repository linked above.