Apply when the actual candidate and observable result still need verification.
Scanned 9/23/2026
Install to Claude Code
npx -y skills add jaydubya818/MissionControl --skill principle-prove-it-works --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Principle Prove It Works?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/jaydubya818-principle-prove-it-works)More formats (shields.io, HTML) on the badges page.
---
name: principle-prove-it-works
description: "Apply when the actual candidate and observable result still need verification."
license: MIT
metadata:
author: jstack-maintainers
source: michael-denyer/pstack-claude
source-version: "0.9.30"
source-commit: 45f768349a6d7d7e71509fee3f5bccfad54b3bad
owner: software-factory
risk: low
capabilities: jstack,engineering-principle
user-invocable: false
---
# 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).
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!