principle-prove-it-works
Prove completed work against the real artifact before declaring success. Use after any implementation, migration, delegated task, configuration change, or fix where compilation, self-report, cached output, or file existence could hide failure.
- License 许可
- MIT
- 所属仓库
- caezium/skills
- 最近更新
- 2026-08-24
- Stars
- ★ 3
- Forks
- 0
01 前言 Front Matter
- name
- principle-prove-it-works
- description
- Prove completed work against the real artifact before declaring success. Use after any implementation, migration, delegated task, configuration change, or fix where compilation, self-report, cached output, or file existence could hide failure.
02 资源文件 1
- 许可证LICENSE1.0 KB
03 SKILL.md 正文
Prove it works
Verify the output by observing the real behavior. Build success is necessary evidence for code, not completion.
Evidence ladder
- Inspect the final diff or artifact.
- Run the repository's focused checks.
- Exercise the changed path with representative input.
- Trace the full input-to-output chain and inspect side effects.
- For an integration, exercise the real boundary end to end when safe and proportionate.
Choose the highest useful rung and report exactly what ran, what passed, and what remained unavailable. If the proof cannot run, mark the result unverified rather than rounding up.
Proof rules
- Read actual state, not cached or derived representations.
- Check process health directly when liveness matters.
- For delegated work, inspect files, diffs, tests, and runtime artifacts; a worker summary is only a lead.
- When an observation contradicts expectations, validate the observation method before changing the system.
- Prefer a deterministic, rerunnable script over a one-time eyeball when the task is non-trivial.
- Keep proof visible to the user. Commit it only when the work or review trail outlives the session.
Completion criterion: the final claim is paired with a command, artifact, or direct observation that would fail if the claim were false, plus an explicit note for every untested boundary.
<!-- Adapted from poteto/pstack principle-prove-it-works, MIT License, Lauren Tan, cursor/plugins@51a96e0. -->
04 同仓库更多 Skills
writing-for-agents
Writing documents for agents. Use when creating or editing skills, or modifying AGENTS.md or CLAUDE.md.
wrangler
Cloudflare Workers CLI for deploying, developing, and managing Workers, KV, R2, D1, Vectorize, Hyperdrive, Workers AI, Containers, Queues, Workflows, Pipelines, and Secrets Store. Load before running wrangler commands to ensure correct syntax and best practices. Biases towards retrieval from Cloudflare docs over pre-trained knowledge.
workers-best-practices
Reviews and authors Cloudflare Workers code against production best practices. Load when writing new Workers, reviewing Worker code, configuring wrangler.jsonc, or checking for common Workers anti-patterns (streaming, floating promises, global state, secrets, bindings, observability). Biases towards retrieval from Cloudflare docs over pre-trained knowledge.
wizard
Generate an interactive bash wizard that walks a human through steps only they can perform. Use when provisioning infrastructure, setting up credentials or CI secrets, walking an unfamiliar third-party dashboard, or running a one-off migration or cutover. Don't invoke this for steps the agent can perform itself.
why
Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available evidence sources, searches each relevant category, and returns a cited read on decisions and tradeoffs. Use how for runtime behavior.
week-prep
Generate a briefing with calendar, tasks, and attention flags. Use for "week prep", "briefing", or "what's on this week".