メニュー
Investigate unknown bugs with an explicit hypothesis ledger and evidence-driven probes before drafting a task spec. Triggers on unexplained failures, ambiguous test failures, regressions, or bug reports without a supported root cause.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
Turn a design handoff into a task contract that can actually be checked — named source, resolved components, token names instead of raw values, and an explicit list of what stays unverifiable. Use when a Figma frame, mockup, or design spec is handed over for implementation.
Convert a PRD, ticket, or feature request into a task contract that can fail — behaviour split from outcome, product nouns resolved to symbols that exist, unspecified cases surfaced as questions, and success metrics parked where a merge gate cannot wave them through. Use when product writing is handed over for implementation.
Enumerate what a change can reach and what enforces it — privileged operations and their callers, guards and the sites that apply them, and every module that reads a secret — before designing an auth, permission, or secrets change. Feeds the security review; produces a population and a gap list, never a verdict.
Read-only review of whether the tests in a finished change actually prove its behaviour — changed code no test reaches, a test exercising a different path than the one that changed, an assertion edited to match the new output, and a suite that ran nothing. Use after implementation, and whenever a change claims to be covered.
Gather who already depends on a service, handler, or state owner before changing it, and name the runtime gaps the codegraph cannot span. Use before designing a change to an API, queue consumer, background job, migration, or shared state; it feeds the architecture review rather than replacing it.
Read-only review of a finished UI change against the codegraph — a component nothing renders, a props contract changed without its callers, a reinvented component, or a raw value where the design system has a token. Use after implementing React or Vue work; triggers "review this UI change", "check the component", or a finished frontend diff.
| name | mastermind-investigation-ledger |
| description | Investigate unknown bugs with an explicit hypothesis ledger and evidence-driven probes before drafting a task spec. Triggers on unexplained failures, ambiguous test failures, regressions, or bug reports without a supported root cause. |
| metadata | {"version":"0.1.1","authors":["mastermind"],"tags":["debugging","investigation"]} |
When a bug, test failure, or regression has no known cause, diagnose before specifying the fix. The ledger prevents premature closure while allowing independent evidence gathering when it is safe and useful.
Use when:
Do NOT use when:
Track every hypothesis explicitly:
| # | hypothesis | status | evidence_for | evidence_against |
|---|---|---|---|---|
| 1 | <concrete, falsifiable cause> | open / weakened / confirmed | <facts> | <facts> |
Current best explanation: <a concrete code location, config value, or dependency>
Next decision point: <the smallest probe or independent probe set that best splits the live hypotheses>
confirmed only when evidence_for is populated AND evidence_against has been checked. No evidence_against = premature closure; keep it open.evidence_for / evidence_against and set the
next decision point.Stop when the root cause or contributing causes are supported and the best explanation names concrete locations. Then:
After ~5 probes without a confirmed hypothesis (or sooner when no distinguishing test remains): stop and escalate to the user with the full ledger and ruled-out table. Bounded investigation beats an infinite probe loop. Don't guess a cause; don't open a spec on an open or weakened hypothesis.
evidence_against, you're guessing.