菜单
REQUIRED before any design or plan when adding a feature to a system you did not personally write. Build a 30-50 line probe that produces the proposed feature's output against the real codebase, define an independent oracle that computes the same answer a different way, and refuse to proceed until probe and oracle agree.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
Replaces brainstorming for feature design. Produces a design where every claim is paired with an experiment that would prove it wrong, and the cheapest such experiment runs before the design is approved. Refuses to run until prove-it-prototype has produced agreement between probe and oracle.
REQUIRED before prove-it-prototype when a feature request originates from a human in natural language. Interrogates the requester one question at a time until every vague noun is resolved, every success criterion is measurable, every edge case has an explicit decision, every "TBD" is closed, and the requester has signed off in their own words. Refuses to proceed until the artifact has zero hand-waving.
Replaces executing-plans. Executes slices one at a time. After each slice, runs the slice's stress fixture AND the prove-it-prototype oracle against the binary AND the budget check. If any of those fail, STOPS and surfaces the drift to the user. Treats the plan as a hypothesis, not a contract.
Use when responding to PR review feedback (human or bot) before applying any changes. Treats each finding as a hypothesis to verify, not an instruction to follow. Decides per finding whether the bug claim is real AND whether the proposed fix is right AND whether to accept, modify, or reject. Refuses to apply changes without per-finding verification.
Replaces writing-plans. Decomposes a falsifiable design into small slices, each with mandatory complexity budget, scale budget, stress fixture, and oracle. Refuses to run until falsifiable-design has produced an approved design with a passing cheapest-falsifier.
A scoped TDD discipline. Use for unit tests inside a slice during checkpointed-build. Adds two mandatory steps beyond GREEN — BUDGET and ORACLE — and treats TDD as one tool in a larger spiral, not the whole methodology.
| name | prove-it-prototype |
| description | REQUIRED before any design or plan when adding a feature to a system you did not personally write. Build a 30-50 line probe that produces the proposed feature's output against the real codebase, define an independent oracle that computes the same answer a different way, and refuse to proceed until probe and oracle agree. |
You think you understand the system you're extending. You don't. Prove it.
Before any design, any plan, any task list, any TDD ceremony, you build a probe. The probe produces the smallest slice of the proposed feature's output against the actual system on actual data. Then you compute the same answer a different way — that's the oracle — and you compare. If they disagree, the design you're about to write is built on a fantasy.
No design. No plan. No code. No tests.
Probe first. Oracle first. Agreement first.
If you cannot produce a 30-50 line probe and an independent oracle, you do not understand the feature well enough to design it. Go think harder. Come back.
Always, when adding a feature on top of a system whose behavior you can observe but did not write — a resolver, a parser, a database, a third-party API, somebody else's library, even your own code from six months ago. Anything where your mental model could be wrong and you wouldn't notice.
Skip only when writing a small standalone utility with no underlying system to depend on. If you're not sure whether to skip: don't skip.
Upstream check. If the feature request originated from a human in natural language (a stakeholder ask, a Linear ticket of two sentences, a Slack message), [[interrogated-spec]] runs before this skill. You cannot probe a feature whose definition is still mush — the probe will faithfully answer the wrong question. Confirm the upstream artifact exists at .<feature-slug>/spec.md with a verbatim sign-off line before proceeding.
grep. If the probe calls the HTTP API, the oracle hand-counts the database. The oracle is allowed to be tedious. It is required to be unaffected by the same bug.Legitimate oracles:
grep | sort | uniq -c)cargo tree, git log, ls, anything in /usr/binFake oracles, do not accept these:
Check the tracker for prior art. Before probing, search your project's issue tracker for tickets that mention the area or behavior you're about to investigate. Keyword-match on the function names, files, or symptoms involved. Read any matches: prior reviewers may have already filed the bug you're about to re-discover, and existing tickets carry context (PR comments, related fixes, reviewer rationale) that saves probe iterations. 5-minute upper bound — do not rabbit-hole. Output: a short list of related issue IDs in your probe directory (e.g., .<issue>/related-issues.md), or an explicit "no prior art found" note.
How to find the tracker (when not already known), in rough order of likelihood:
CLAUDE.md / AGENTS.md / GEMINI.md often documents the tracker and how to query it. Check first.gh CLI + GitHub remote → GitHub Issues. Try gh issue list --search "<keyword>".rivets, bd, beads, linear). Check Cargo.toml, package.json, Makefile, or bin/ for clues; the tool is often dogfooded..github/ISSUE_TEMPLATE/, BUGS.md, or ISSUES.md at the repo root.gh pr list --state all + read the comments) and any docs/ design notes. Same idea, different surface.State the smallest possible question the feature answers. Not the whole feature. The smallest factual question. (For coupling: "what packages does this workspace contain?" not "what are the coupling metrics?")
Write the probe. Aim for under 50 lines. Run it against the real codebase.
Pick an oracle. Write down — in one sentence — how you will compute the same answer independently.
Run the oracle. Compare output item by item to the probe's output.
If they disagree: the probe is wrong, the oracle is wrong, or the underlying system is broken. Investigate. Repeat until they agree.
If they agree on the smallest question: expand by one. New question. New probe slice. New oracle check. Continue until the probe covers enough of the feature's output that you trust the design will be standing on solid ground.
This is the most important moment in the entire feature. Do not paper over it.
Causes, in descending order of how often they're the real reason:
The underlying system is broken in a way you didn't know about. Before filing a new bug, search the tracker for an existing ticket describing the symptom. Drift in your probe may be a re-discovery of work someone already filed. If found: link to the existing ticket from your design doc; if the existing ticket is closed-but-not-applied (an incomplete fix), note the residual gap. Otherwise file the bug. Either way: pause this feature until that bug is filed and either fixed or scoped around.
Your model of the system is wrong. The system does something you didn't predict. Update your model. Write down what you learned.
The probe is wrong. Fix it.
The oracle is wrong. Fix it. (Last resort. The oracle's job is to be independent. If you're "fixing" the oracle to match the probe, you have lost.)
If cause 1 fires: stop. You cannot build a feature on a broken substrate. Either fix the substrate or rescope the feature so it doesn't depend on the broken part.
The next skill — falsifiable-design — refuses to run until you can answer yes to all of these:
If you learned nothing new, you didn't probe hard enough. Try again with a sharper question.
This is not exploration. Exploration is "let me poke at the system to see how it works." Probing is "let me build the smallest possible version of the feature's output and check it against ground truth." Exploration is fine; it produces vibes. Probes produce evidence. Vibes are not allowed to gate downstream skills.
The artifacts of running this skill:
probe.{sh,py,rs,…} — the probe code, committed to the repo (or attached to the design doc).If any of those three artifacts don't exist, the skill didn't run. Run it.