---
name: verify-output
description: Structured verification pass before delivering code, scripts, configurations, or any technical artifact. Re-read request, check each requirement against output, actually run the code, include tests when asked, self-review, fix silently before responding. Apply on every coding task — skipping verification is the most common cause of incomplete outputs.
triggers: [verify, verification, test, deliver, ship, check, validate, review, qa, lint, compile]
---

# Verify Your Work

Apply this skill BEFORE delivering any code, script, configuration, or technical artifact. Skipping verification is the single most common cause of incomplete or broken outputs. Treat as mandatory for every coding task, not optional polish.

## 1. Re-read the request

Before finalizing your response, re-read the user's original message (and any follow-ups) in full. Extract every discrete requirement, constraint, and preference they stated. Write them down internally as a checklist. This catches drift — it's easy to start solving a related-but-different problem mid-task.

## 2. Check each requirement against your output

Walk through your internal checklist point by point. For each requirement, locate the exact lines in your output that satisfy it. If you cannot point to concrete lines that fulfill a requirement, the work is not done — go back and address the gap before responding. Pay special attention to edge cases, error handling, and boundary conditions the user mentioned.

## 3. Run the code

Whenever possible, use `exec` to actually run, compile, lint, or test your code before presenting it. Do not guess whether code works — execute it and observe the result. If the code produces errors, fix them and re-run until it succeeds.

- For scripts: run with representative inputs.
- For libraries/modules: write and execute a minimal smoke test.
- For config files: validate syntax (json, yaml, toml parsers).

If execution is genuinely impossible (no runtime, user said don't run), state that you were unable to verify execution and explain why — do not silently skip.

## 4. Include tests when requested

If the user asked for tests, they are a hard requirement — not a nice-to-have. Deliver the tests alongside the implementation, not as an afterthought. Run the tests and confirm they pass before responding. If the user did not explicitly ask for tests but the change is non-trivial, consider whether a test would catch a regression and offer one.

## 5. Self-review

After everything above, use `read` to re-read any files you created or modified. Look with fresh eyes as if reviewing someone else's code. Check for:

- typos, missing imports, unused variables
- inconsistent naming
- hardcoded values that should be configurable
- incomplete error handling
- security issues (exposed secrets, injection vectors, missing input validation)

If you find problems during self-review, fix them, re-run verification, and only then respond.

## Verification failures

If any step above reveals a gap, do NOT respond with a partial answer and a disclaimer. Instead, fix the issue silently and re-verify. The user should receive working, complete output — not a draft with known issues. Only flag genuinely unresolvable ambiguities (where you need the user's decision to proceed).
