# Skill: Run a 6-step verification loop before declaring any task done

> Apply this skill at the end of every feature or session -- it prevents the agent from falsely reporting "done" by requiring a concrete traffic-light report covering build, types, linter, tests, secrets, and changed files.

Source: sodigi·learn -- vibecoding/proverka-pered-zapuskom · https://sodigi.io/learn/vibecoding/proverka-pered-zapuskom

## When to use
- When the agent says "done" or "everything works" -- treat it as a hypothesis until the loop confirms it.
- After completing a feature, before moving to the next one.
- Before publishing or deploying any version to real users.
- After a large refactor that touched many files.
- When something is "acting weird" -- run the loop to get a precise error address instead of guessing.

## Core rules
- "Done" from an agent is a hypothesis. It becomes a fact only when the project builds, runs, and passes all checks.
- Build first, everything else second. If the build fails, stop and fix it before writing any new code.
- A valid report shows PASS or FAIL with numbers for each phase -- not a wall of logs with a cheerful "success" at the top.
- "Tests passed" without a count is meaningless. Zero tests all pass by definition.
- A security check is not optional -- one exposed key in public code causes real harm.
- Review the changed-files list every time. "I asked to fix one button; why did 40 files change?" is a valid question.
- Run the loop at natural boundaries (feature complete, before publish, after rebuild, every 10-15 minutes in long sessions) -- not after every single line.

## Procedure
1. Build the project. If the build fails: stop, fix it, do not continue to the next phase.
2. Run type checking. List all type errors found; fix critical ones immediately.
3. Run the linter. List all lint warnings and errors.
4. Run tests. Report: total count, passed, failed. If any test is red, provide the specific failing test name.
5. Check for secrets: scan for any passwords, API keys, or tokens that appear in committed or staged files.
6. Show the list of changed files (e.g., git diff --name-only). Flag any unexpected changes.
7. Produce a final traffic-light summary: PASS/FAIL per phase plus an honest verdict -- "ready to publish" or "not ready, fix X first."

## Ready-to-use prompt
```
When you finish the task, do not tell me "done" until you have run the full
verification and shown me the report.

Go step by step:
1. Build the project. If the build fails -- stop and fix it first, do not
   touch anything new yet.
2. Check the types and the linter, and list any errors you find.
3. Run the tests and write down: how many total, how many passed, how many
   failed.
4. Check that no passwords, keys, or tokens ended up in the code.
5. Show the list of changed files.

At the end, give me a short traffic-light report for each item: PASS or FAIL.
And an honest verdict: ready to publish or not. If something is red -- fix it
first, then report.
```

## Pitfalls
- Taking the agent's word "done" at face value -- it means "I finished typing," not "I verified it works."
- Building new features on top of a failed build -- errors compound and become impossible to untangle.
- Checking only once at the very end of a long session -- bugs pile up invisibly and are hard to attribute.
- Accepting "tests passed" with no count -- zero tests all pass trivially.
- Skipping the security step -- one exposed key in a public repository is a real incident.
- Never opening the live site after a green report -- the report covers code; a human eye catches layout and interaction issues the checks miss.