Skip to content
Back to skills

Verified Done

ASecurity

Use when about to claim any work is complete, fixed, passing, or shipped — before saying "done", "should work now", "that fixes it", or committing. Also use at the end of every slice, before wrap/handoff, and whenever you notice you are asserting an outcome you have not freshly observed.

  • 8 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 2, 2026
ai-agents

Works with

  • cli

Security analysis

A100/100

Scanned September 2, 2026

npx -y skills add balanced7/akashic-aurora --skill verified-done --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Verified Done?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Verified Done
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/balanced7-verified-done/badge)](https://www.skillsdirectory.com/skills/balanced7-verified-done)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: verified-done
description: Use when about to claim any work is complete, fixed, passing, or shipped — before saying "done", "should work now", "that fixes it", or committing. Also use at the end of every slice, before wrap/handoff, and whenever you notice you are asserting an outcome you have not freshly observed.
---

# Verified done

**Iron Law: no completion claims without fresh verification evidence.** "Fresh" means you
ran the check in THIS state of the code and read its output — not that it passed earlier,
not that the edit looked right.

## The gate (IDENTIFY → RUN → READ → THEN CLAIM)

1. **Identify** the command that would prove the claim (test file, full suite, the actual
   CLI invocation, the hook fed a real payload).
2. **Run it now.** For a slice: the full suite — this repo's ship ritual runs it for you:
   ```
   py scripts/ship.py "<msg>" <explicit paths> --learn-exp <name> --tried "..." --result "..."
   ```
   (gate: boundaries + doc-freshness + full pytest → commit+push with EXPLICIT paths →
   lesson → snapshot; any failure aborts before anything is committed).
3. **Read the output** — the count, the exit, the rendered artifact. Eyeball one REAL
   render of anything user-facing (a boot screen, a draft, a hook injection), not just
   its unit test.
4. **Then claim, with the evidence in the same breath** ("suite 578 passed; pushed as abc123").

## Red-flag phrases (each one means STOP and verify)
- "Should work now" · "Probably passes" · "Done!" (before running anything)
- "The tests should still pass" (run them)
- "I've made the change" (an accepted Edit is not a working change)

## Repo-specific truths
- Dogfood through the real CLI against canonical-shaped data; unit fixtures verify units,
  dogfooding verifies the seam.
- Report failures faithfully: if the gate fails, say so with the output — never soften it.
- A slice is not done until mirrored AND the where-we-are note reflects it
  (`py agent_cli.py note <id> --title where-we-are --note "..."` supersedes by title).
- Honest labels: "worked" means self-reported; only independent corroboration earns more.
  The same discipline applies to your own claims.

## Why this gate feeds the memory loop
The FAIL→SUCCESS credit and the value-rate funnel are only as honest as the SUCCESS half.
A claimed-but-unverified success would credit lessons that helped nothing — verification
is what keeps the whole learning loop's currency real.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…

Newsletter

Get the weekly list of safe new skills, and the ones we pulled.