Menü
Step-back protocol — restate, generalise, specialise, invert, ask why, pre-mortem, check stakeholders, and audit framings before solving
Run the 7-step Artificial Critical Thinking pass — Materiality → Hypothesise → Alternatives → Disconfirmers → Audit priors → Severity → Commit-with-marker
Challenge what you think is right — alternative hypotheses, missing data, evidence quality, bias detection, falsifiability, and adversarial review
Build knowledge bases that build software — research before code, teach before execute
Two-phase brain upgrade — mechanical install via shared core, then LLM-led semantic reconciliation
Generate consistent visual character references across multiple scenarios using Flux and nano-banana-pro on Replicate
Create professional ultra-wide cinematic banners for GitHub READMEs using modern AI image models with typography
| type | skill |
| lifecycle | stable |
| inheritance | inheritable |
| name | problem-framing-audit |
| description | Step-back protocol — restate, generalise, specialise, invert, ask why, pre-mortem, check stakeholders, and audit framings before solving |
| tier | core |
| applyTo | **/* |
| user-invokable | true |
| currency | "2026-04-26T00:00:00.000Z" |
Before you solve, audit the frame. A flawless solution to the wrong problem is still a wrong answer.
The first failure mode in critical thinking is solving the wrong problem precisely (Mitroff & Featheringham 1974, Type III error). Most "thinking harder" effort runs downstream of a frame that was never audited — the user's literal request, restated as my plan, treated as ground truth. This skill is the structural answer.
The frame audit runs before the materiality gate. Materiality asks "if I get this answer wrong, would it change anything?" Framing asks something prior: "am I even working on the right question?"
| Trigger | Activation |
|---|---|
| Single-file edit, < 15 minutes of work, mechanical task | Skip — frame audit adds friction without payoff |
| Task uses the words "fix", "improve", "make faster", "speed up", "broken", "make it work" | Always audit — these phrases hide a symptom-frame |
| Task spans 3+ files, requires architectural choice, or estimates > 15 minutes | Always audit |
| User restates the same request after a failed attempt | Always audit — repeated failure is a signal the frame is wrong |
| User says "just" do X, or "simply" Y, or "all you have to do is" | Always audit — these phrases mark unexamined frames |
User explicitly invokes /reframe or asks "what am I missing?" | Always audit |
The rule is asymmetric on purpose: trivial tasks pass through; non-trivial tasks audit first.
Eight checks. The discipline is not to run all eight on every problem — it is to run at least one before committing to a solution. Pick the check most likely to surface a different framing for this specific request.
| # | Check | Activation question | Source |
|---|---|---|---|
| 1. Restate | Can I write the problem in one sentence in my own words? | If I can't, I don't understand it yet. Ask. | Polya 1945 — What is the unknown? |
| 2. Generalise | What is this a special case of? | Naming the general class often reveals existing solutions and prior art. | Polya 1945 |
| 3. Specialise | What's the simplest concrete instance? | If the simplest case is already hard, the general case is the wrong target. | Polya 1945 |
| 4. Invert | What would make this worse? What would I do if I wanted to fail? | Inversion exposes hidden constraints. | Munger / Jacobi |
| 5. Five Whys | Why is this a problem? And why is that a problem? Repeat 5×. | Surfaces the cause-frame underneath the symptom-frame. | Toyota / Ohno |
| 6. Pre-mortem | Imagine we're done and it didn't work — what went wrong? | Reduces overconfidence by ~30% in field studies. | Klein 2007 |
| 7. Stakeholder check | Whose problem is this, really? What outcome would tell them it's solved? | "Make X faster" might be the wrong job if the user doesn't actually run X often. | Checkland 1981 (CATWOE) |
| 8. Frame audit | What other framings exist? Have I considered at least two? | Russo & Schoemaker: < 10% of decision effort goes to framing; ≥ 80% of decisions are downstream of an unaudited frame. | Russo & Schoemaker 2002 |
The most common type-III error: the user names a symptom and I optimise for it. The audit's job is to surface the cause underneath.
| Symptom-frame (what user said) | Cause-frame (what audit surfaces) | Right move |
|---|---|---|
| "Make this function faster" | Function is fine; it's called 1000× when it should be called 1× | Cache or batch the caller, not the function |
| "Fix this flaky test" | The test is correct; the system has a real race condition | Fix the race, not the test |
| "Make the build less noisy" | The warnings are real — system is leaking handles | Fix the leaks; the noise was the diagnostic |
| "Why does this query take 2 minutes?" | Query is fine; it returns 47M rows the UI then renders | Fix the contract, not the query |
| "Add a workaround for this API quirk" | The "quirk" is the API enforcing a real constraint | Honour the constraint, not work around it |
| "Make our skill load faster" | The skill is fine; it's loaded on every request when it should load once | Move the load gate, not the skill body |
In each row, the symptom-frame produces a working but pointless solution. The cause-frame produces the right one.
When the frame audit fires and produces a different framing than the user's literal request, the response must make the move visible:
| Marker | When to use |
|---|---|
**Frame**: Restated as ... | Always when audit fires — confirms my understanding |
**Cause-frame**: ... (when the symptom-frame is being replaced) | When step 5 (Five Whys) or step 7 (Stakeholder) surfaces a different problem |
**Considered framings**: (a) X, (b) Y — going with X because ... | When step 8 surfaces a real alternative |
**Pre-mortem**: If this fails, the most likely cause is ... | When step 6 surfaces a non-obvious failure mode worth flagging |
Markers are not boilerplate — they fire only when the audit produces something. A silent audit that produced no reframe needs no marker; just proceed.
| Anti-pattern | Why it fails | Correction |
|---|---|---|
| Run all 8 checks on every task | Friction kills the discipline; users stop bringing real work | Pick the one or two checks most likely to fire for this task |
| Restate the user's request word-for-word as the "frame" | That's not a restatement, that's parroting | Use your own words — that's the test |
| Run audit, surface a different frame, then solve the user's literal frame anyway | Discipline becomes theatre | If audit surfaces a different frame, propose it before solving — let the user choose |
| Skip audit because "it's obvious" | "Obvious" is exactly when frames are most often wrong | If you feel certain, run the audit anyway — that certainty is the signal |
| Ask 8 clarifying questions back-to-back | Audit becomes interrogation | One sharp question is better than 8 generic ones; pick the highest-leverage check |
Track the next 20 non-trivial sessions in which this skill activates. In what percentage did the audit surface a framing different from the user's literal request?
| Surface | How frame-audit attaches |
|---|---|
critical-thinking/SKILL.md | Inserted as Discipline -1 before the Materiality Gate; this skill is its detailed body |
critical-thinking.instructions.md | Adds the L1 always-on line: "Before solving non-trivially, restate the problem in one sentence; if user's framing differs from yours, flag it before proceeding." |
deep-thinking.instructions.md | The audit is a recommended first step on any deep-thinking session |
planner agent | Frame audit runs before plan decomposition |
act-pass skill | Step 1 of the 7-step pass is the frame audit |
/reframe prompt | User-invokable trigger to force this skill on a stuck problem |