verification-before-completion

Files (1)

• SKILL.md

SKILL.md (first lines)

# Verification Before Completion

## Purpose

User-relevant correctness and completion claims require current trustworthy
evidence. Decide what evidence is needed from the claimed capability and risk,
then compare it internally against semantic acceptance; do not turn an internal
checklist into the user's report.

## Judge evidence freshness

Before relying on preserved evidence, reason about what state changed after it
was produced: source, dependencies, configuration, generated artifacts,
environment, data, deployment boundary, or the scenario itself. Evidence is
stale when a relevant change could invalidate its meaning, not merely because
time passed.

When freshness is uncertain, run a focused probe that tests the disputed state.
Use that result to decide whether preserved evidence remains trustworthy or a
broader test, build, readback, or production-shaped scenario must be regenerated.
Match verification breadth to the breadth and risk of the claim.

## Verify semantic acceptance

Identify the real scenario and observable result before declaring success:

- frontend work: inspect rendered visual state and exercise relevant interaction;
- persistence: save, restart or reload, and read back intended state;
- API, CLI, or automation: exercise meaningful arguments and failure paths, then
  inspect resulting state rather than only a response envelope;
- benchmarks or agents: inspect actual task performance, abnormal behavior, and
  behavioral trajectory rather than an aggregate score alone; and
- compatibility or migration: exercise a representative existing consumer or
  artifact across the promised boundary.

Unit tests, compilation, linting, and static checks support these claims but do
not replace semantic acceptance. If evidence cannot reach the user-relevant
scenario, report the limitation plainly instead of overstating completion.

## Closeout reporting

Before drafting the closeout, inspect project materials for defined consumers,
operational context, and module relationships. Do not claim there are no dependent
modules or no remaining risk until that investigation supports the statement.
Absent evidence is not evidence of no dependency or risk.

Lead the closeout with the capability or product behavior now working. Then state:

1. the project architecture or operational logic learned;
2. how affected modules and boundaries relate;
3. the current construction stage and completed milestone;
4. meaningful behavioral evidence, including real UX interaction, benchmark
   agent behavior, or observed abnormal behavior when relevant; and
5. remaining blockers, risks, or the next meaningful milestone.

Do not lead with filenames, function names, variables, tool calls, or test
inventories unless the user requests engineering detail or an identifier is
needed to explain a real blocker. This is not a reason to remove useful detail:
state concrete business, product, operational, semantic, and architectural
evidence where it explains the outcome.

## Before the claim

Confirm internally that available current trustworthy evidence supports the
specific claim, material semantic acceptance scenarios have been exercised, and
any remaining gap is stated in the closeout. A worker report or a green support
signal alone is not a substitute for that judgment.

From BB-84C/superpowers-lite, MIT.

More from BB-84C/superpowers-lite