Skip to content
Back to skills

Prove

ASecurity

Capture the evidence a change actually works: the BEFORE state while the defect still reproduces, the AFTER state once it passes, both put where a reviewer sees them, so no completion claim rests on the author saying so.

  • 6 stars
  • 0 votes
  • 0 copies
  • 1 view
  • Added September 3, 2026
ai-agentsgobashgit

Works with

  • mcp

Security analysis

A100/100

Scanned September 24, 2026

npx -y skills add djnsty23/claude-auto-dev --skill prove --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Prove?

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

Security grade badge for Prove
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/djnsty23-prove/badge)](https://www.skillsdirectory.com/skills/djnsty23-prove)

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: prove
description: "Capture the evidence a change actually works: the BEFORE state while the defect still reproduces, the AFTER state once it passes, both put where a reviewer sees them, so no completion claim rests on the author saying so."
when_to_use: "Use before the first edit of a fix and again once it works. Use whenever asked to write a status line, summary, report or release note that says something is fixed, passing or done, whenever a claim would otherwise have no command output behind it, and on the word prove."
allowed-tools: Bash, Read, Write, Grep, Glob, mcp__Claude_Browser__*
model: opus
user-invocable: true
argument-hint: "[before <slug> | after <slug>]"
---

# Prove

Two captures of the same observable, taken at the two moments that make them
comparable. Everything else here is detail.

**The before capture happens while the defect still reproduces.** That is the
only moment it costs nothing, and it is gone the instant you start editing. A
session that fixes first and captures second cannot tell "I fixed it" from
"it was never broken in the way I described", because both produce one green
screenshot.

## Where it goes

`.claude/evidence/<slug>/` holds `before.png`, `after.png` for visual work;
`before.txt`, `after.txt` for numbers or output.

**Not `.claude/screenshots/`.** That directory is gitignored and documented as
cleaned each run, so a before state stored there is destroyed by the run that
produces the after state. Check the destination with `git check-ignore -v` in the actual project; a
plugin cannot assume every repo tracks `.claude/evidence/`. Follow
`rule-file-organization` for durable evidence and keep credentials, session
state and private user data out of published artifacts.

**Tracked means commit it WITH the change, not beside it.** Left uncommitted the
evidence dirties the tree, and any gate that refuses a dirty tree then refuses
to run at all, which is a self-inflicted block right at the step that needs the
gate green. Identify the code revision/tree tested separately from any later
evidence-only commit; do not imply a gate ran on a SHA it never checked.

## Step 1: before, and it is a probe

```bash
mkdir -p .claude/evidence/<slug>
```

Record the expected result before editing, reproduce the defect, then capture.
For each capture retain the command/flow, cwd, code revision and working-tree
state, time, environment/URL, build identity, role/account and relevant data
state. Do not record credential values. Which observable depends on the change:

| Change has | Capture |
|---|---|
| A visible surface | Screenshot at the viewport the bug appears at. Assert `innerWidth`/`innerHeight` in the same call, or the rect you measured is against a zero-height window |
| A number that moves | The number, with the command that produced it and the population it counted |
| Output that changes shape | The output pair, byte for byte |
| No before state (purely additive) | Write `before.txt` saying so, in one line |

**If the defect does not reproduce, stop.** An empty before capture is not a
minor inconvenience, it is the finding: you are about to fix something you have
not observed. Load `rule-diagnosis` rather than editing.

## Step 2: after, once the change works

Same observable, same viewport, same command, same population. A pair taken two
different ways compares two different things and proves nothing.

Assert the expected behavior against both captures: the before fails for the
defect’s reason, the after satisfies the same criterion, and a valid control
still works. Inspect screenshots when visual behavior matters. Byte inequality
alone proves nothing: timestamps or unrelated pixels can differ while the bug
persists. Identical screenshots can be valid for a nonvisual fix; then use an
observable that actually distinguishes the behavior instead of forcing pixels
to change. For output contracts, compare meaningful fields and retain raw logs.

## Step 3: put it where a reviewer reads it

The evidence is worthless in the session that produced it. It has to reach the
person deciding whether to merge.

- **Commit body** is the default, and the only one that works with commits that
  stay local. Name the paths and state what changed between them in one line.
- **Pull request body**, when one is opened. A relative path does not reliably
  render there; after the branch is pushed, reference the raw URL:
  `https://raw.githubusercontent.com/<owner>/<repo>/<commit-sha>/.claude/evidence/<slug>/after.png`

Write the delta in words beside the images. A reviewer scanning two screenshots
should not have to find the difference themselves, and a difference you cannot
state in a sentence is one you have not checked.

## What this does not do

It does not replace the gate. Evidence is for the human; the gate is for the
machine, and `rule-gate-integrity` covers whether that gate can fail at all. A
change with a beautiful before/after pair and a red gate is not shippable.
Local proof, merged code, deployment and verified live behavior are separate
claims. For a live acceptance criterion, check the deployed revision and repeat
the relevant flow there under the current authorization; local screenshots do
not establish that deployment worked.

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…