agentleFS
Sign inStart free
jaydubya818jaydubya818/MissionControl/skills/principle-prove-it-works/SKILL.md

principle-prove-it-works

Skill2 starsChanged 8 months agoMITView on GitHub

Apply when the actual candidate and observable result still need verification.

We split this skill into the rules it gives an agent

10 rules. 6 are common, 4 are distinctive, and 0 are very specific to this project.

  • 6

    Common

    Most of the 46 edited versions we read keep these.

  • 4

    Distinctive

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Common:

    Verify every task output by checking the real thing directly.

    line 18
  2. Distinctive:

    Pattern: After completing any task, ask: "how do I prove this actually works?"

    line 22
  3. Common:

    Check the real thing, not a proxy:

    line 24
  4. Common:

    Check process liveness directly, not indirectly through derived state

    line 25
  5. Common:

    Read the actual value, not a cached or derived representation

    line 26
  6. Common:

    When verification fails, suspect the observation method before suspecting the system

    line 27
  7. Distinctive:

    Run it and exercise the actual feature path

    line 31
  8. Distinctive:

    Check the full chain: does data flow from input to output?

    line 32
  9. Distinctive:

    When verifying delegated work, inspect the actual output artifact (git diff, file contents, runtime behavior), not the delegate's summary.

    line 40
  10. Common:

    Keep the artifact visible for the human.

    line 46

“Common” is measured: kept by at least 6 in 10 of the 46 edited versions of this file we could read. “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

Prove It Works

Verify every task output by checking the real thing directly. Do not infer from proxies, self-reports, or "it compiles."

Why: Unverified work has unknown correctness. Indirect verification (file mtimes, output freshness, agent self-reports, cached screenshots) feels cheaper than direct observation. Acting on a wrong inference costs far more than checking the source.

Pattern: After completing any task, ask: "how do I prove this actually works?"

Check the real thing, not a proxy:

  • Check process liveness directly, not indirectly through derived state
  • Read the actual value, not a cached or derived representation
  • When verification fails, suspect the observation method before suspecting the system

Code and features:

  1. Build it (necessary but not sufficient)
  2. Run it and exercise the actual feature path
  3. Check the full chain: does data flow from input to output?
  4. For integrations, test the full communication path end-to-end

Verify the process as well as the outcome. A correct result can rest on a broken process, and a review that checks results passes it: a clause reconstructed from the user's paste instead of the durable record, a constraint honored by chance from a file never read. For each fact you relied on, name the record it came from and confirm that record is the one the project's rules point at.

Red is a colour, not a measurement. A failing check proves the instrument only when the failure content is the disagreement you predicted. An exception, an empty collection against a non-empty literal, and a real mismatch all print red, so quote the assertion's diff (Extra items in the right set), never the assertion (assert {...} == {...}). A convergence probe keys on behavior only the new artifact can produce, never an identity field the old one also emits; a same-SHA restart lets old code report the new commit SHA.

Delegation: trust artifacts, not self-reports. When verifying delegated work, inspect the actual output artifact (git diff, file contents, runtime behavior), not the delegate's summary.

Script the check when you can

The strongest proof is a deterministic script that re-runs the same comparison, not a one-time eyeball. Write the script, run it, and keep its output as an artifact a reviewer can re-run instead of trusting your word.

Keep the artifact visible for the human. Commit it only for large or complex work where the trail has to be auditable later, like a big port or migration (the show-me-your-work skill).

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