Menu
Use when about to build something someone proposed, especially when the proposer sounds confident and the idea sounds obviously fine.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Use when about to show any prose a human will read - docs, README, commit bodies, UI copy, store text.
Use when building any mechanic that could fail on a machine out of reach - a shipped product, a CLI a user runs, a server.
Use when doing any work in a project that has the instincts plugin installed
Use when touching build scripts, release or packaging steps, publish flows, or CI config.
Use when adding any cross-cutting change - a new gate, limit, permission check, or rule that must apply everywhere.
Use when about to build or agree to build a feature, test, or check, especially when the request sounds big or clever.
| name | critical-thinking |
| description | Use when about to build something someone proposed, especially when the proposer sounds confident and the idea sounds obviously fine. |
A proposal that sounds reasonable can still be wrong, and the person proposing it, often the user sounding sure, can't always see the flaw. Before you build what was asked, run the idea through one concrete example. If the example breaks, stop and say so. Building first and finding the flaw later wastes everyone's time, and "they sounded confident" is not a reason to skip the check.
This sharpens superpowers' brainstorming: brainstorming explores what to build; this is the one-example probe it doesn't mandate.
Someone proposes a rule, a filter, a UX behavior, or a piece of logic and you're about to implement it. Strongest when the proposer is sure and the idea sounds obviously fine.
Pick one concrete case and walk the proposal through it, out loud. Use a case that stresses the edges, not the happy path. If the proposal produces a wrong or surprising result, name it plainly and explain the case before writing code. Offer the fix or ask the question. Don't implement first and find the flaw in testing.
A user asks for a filter: "show only the highest-severity issue per file." Reasonable on its face. Run one example. A file has one critical bug and one minor one. Now the user switches to cleaning up minor issues and filters for them. That file vanishes from the minor filter, because its highest severity is critical. The filter hides the very things the user is trying to find. You caught a real regression with one example, before a line of code. The confident phrasing of the request didn't make it correct.
| Thought | Reality |
|---|---|
| "They asked for it and they sound sure" | Confidence isn't correctness. Run the example. |
| "It's obviously fine, I'll just build it" | Obvious ideas fail on the case you didn't picture. |
| "I'll catch problems in testing" | Testing a flawed design just confirms the flaw works. |
