القائمة
Step-back protocol — restate, generalise, specialise, invert, ask why, pre-mortem, check stakeholders, and audit framings before solving
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
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
Clear documentation through visual excellence
End-to-end academic paper drafting for CHI, HBR, journals, and conferences with venue-specific templates, drafting workflows, and revision strategies.
| 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 |
