AGENT SKILL

principle-prove-it-works

Apply after completing a task, before declaring done. Verify against the real artifact (run the feature, read the actual value, inspect the diff), not a proxy, self-report, or 'it compiles.'

License 许可
MIT
最近更新
2026-11-11
Stars
★ 0
Forks
0

01 前言 Front Matter

name
principle-prove-it-works
description
Apply after completing a task, before declaring done. Verify against the real artifact (run the feature, read the actual value, inspect the diff), not a proxy, self-report, or 'it compiles.'
disable-model-invocation
true

03 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

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).

04 同仓库更多 Skills

bbishdotdev
bbishdotdev/ai-tools

why

Use for 'why does X work this way', 'why we picked Y', design rationale, regressions, postmortems, or data-backed thresholds. Discovers available MCPs and queries each evidence category (source control, issue tracker, long-form docs, real-time chat, infrastructure observability, error tracking, product analytics warehouse) in parallel, then returns a cited read on decisions and tradeoffs. Use how for runtime behavior.

数据分析师
★ 0
bbishdotdev
bbishdotdev/ai-tools

unslop

Cut AI tells from any writing. Must always apply.

★ 0
bbishdotdev
bbishdotdev/ai-tools

typescript-best-practices

TypeScript best practices. Use when reading or editing any .ts or .tsx file.

★ 0
bbishdotdev
bbishdotdev/ai-tools

technical-writing

Layered technical-writing standard: Diátaxis structure, Google developer style sentences, STE instruction rules, Global English syntax. Use for /technical-writing or when writing or reviewing docs, RFCs, readmes, PR descriptions, or commit messages.

开发工程师内容创作者写作与文案
★ 0
bbishdotdev
bbishdotdev/ai-tools

teach

Explain a body of work plainly so a person actually understands it. Runs the `how` and `why` skills and weaves what they find into one clear explanation. Use for 'teach me this', 'help me really understand X', 'explain this change or subsystem to me'.

教师与教育
★ 0
bbishdotdev
bbishdotdev/ai-tools

tdd

Use only when the user explicitly asks for TDD, a failing test, or a regression test, OR when the bug has an obvious cheap local test target. Skip when the test path is unclear, expensive, integration-heavy, or not requested.

★ 0