agentleFS
Sign inStart free
FuDesign2008FuDesign2008/open-skills/skills/completion-evidence-discipline/SKILL.md

completion-evidence-discipline

Skill6 starsChanged 6 days agoMITView on GitHub

Hard discipline for verification and completion claims: do NOT claim tests passed, a fix works, or a task is complete without fresh evidence from commands or checks run in the CURRENT turn; label unavailable checks as pending with the exact action required. Referenced by PDCA verification stages via staged-review-flow and host workflows. Triggers — 「完成须有证据」「验证证据纪律」「宣称完成前验证」「completion evidence」 / completion evidence discipline, fresh verification evidence. An opened-UI pass claim cites a non-empty image saved this turn. Do NOT use as a standalone product workflow.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When about to claim any of: tests passed, typecheck/build OK, verification complete, bug fixed, ready to merge/archive:

    line 23
  2. Very specific:

    Prefer user-invocable: false.

    line 48

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Completion Evidence Discipline

Internal shared skill. Single source of truth for fresh-evidence gates on completion and verification claims. Hosts declare it in dependencies (directly or via staged-review-flow) and abort if missing — no silent fallback.

Name note: this skill is intentionally not named verification-before-completion (reserved by an external skills repo). Use this name only.

Iron Law

NO COMPLETION OR PASS CLAIMS WITHOUT FRESH EVIDENCE FROM THE CURRENT TURN.

  • Fresh = produced by a command, check, or observed tool result executed in this assistant turn (or an attached log from that same turn).
  • Not fresh = prior-turn memory, “we designed a test”, subagent success text alone, or assumed green CI.

Required behavior

When about to claim any of: tests passed, typecheck/build OK, verification complete, bug fixed, ready to merge/archive:

  1. Run the relevant command/check in this turn, or
  2. Label Pending with the exact manual action still required — and do not say it passed.

When the check opened a UI, that fresh evidence includes a filesystem path to a non-empty png, jpg, jpeg, or webp saved this turn. A path with no such file does not support a pass claim. Checks that did not open a UI do not require an image. Before an opened-UI image supports the check, look at the saved image in this turn. A blank frame, a solid black frame, or an image with no readable interface stays pending and states that the capture is still required. A readable interface that is not the screen this check was supposed to open stays pending and states the expected screen and what the image shows. If the image was not inspected, the item stays pending and states that the image was not inspected. Keep the file. Do not treat any of those as the expected capture.

Compose with staged-review-flow verification honesty:

LabelMeaning
ExecutedCommand/action + concise output summary from this turn
PendingExact action the user (or a later turn) must still run

Forbidden

  • Reporting “all green” / “verified” when no verifying command was run this turn
  • Treating designed scenarios or unchecked assertions as executed passes
  • Renaming or aliasing this skill to verification-before-completion inside this repository

Integration guide

  • Hosts: one-line pointer at verification / closeout — load this skill; do not paste the Iron Law or opened-UI screenshot inspection prose.
  • staged-review-flow: honesty rule MUST compose with this gate (Executed ⇒ fresh evidence).
  • Orthogonal to runtime-verification-discipline: this skill gates evidence freshness (did you run it this turn); that skill gates verification environment and executor (which tier, who ran it, sufficient?). A pass claim must satisfy both.
  • Prefer user-invocable: false; users reach it through PDCA hosts.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free