Problem Framing Audit (Discipline -1)
Before you solve, audit the frame. A flawless solution to the wrong problem is still a wrong answer.
Purpose
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?"
When to Activate
| 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 /problem-framing-audit or asks "what am I missing?" |
Always audit |
The rule is asymmetric on purpose: trivial tasks pass through; non-trivial tasks audit first.
The Step-Back Protocol
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 Symptom → Cause Move
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.
Output Markers
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-Patterns
| 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 |
Falsifiability Test (per PLAN-CT Lane C)
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?
- Target: ≥ 20% (Russo & Schoemaker's data suggests cause-frames differ from symptom-frames ~30–40% of the time; 20% is a conservative pass)
- If 0%: the audit is decorative. Either the activation rule is too narrow or the audit is rubber-stamping. Retire or rebuild.
- If 100%: the audit is over-firing. The activation rule is too broad. Tighten triggers.
Integration
| 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 |
/problem-framing-audit prompt |
User-invokable trigger to force this skill on a stuck problem |
Background Reading
- ACT/CRITICAL-THINKING-FAILURE-MODES.md §1 — the master failure mode and the step-back protocol
- ACT/PLAN-critical-thinking-improvement.md Lane C — design rationale and falsifiability
- Russo, J. E., & Schoemaker, P. J. H. (2002). Winning Decisions. Doubleday.
- Mitroff, I. I., & Featheringham, T. R. (1974). On systemic problem solving and the error of the third kind. Behavioral Science, 19(6).
- Polya, G. (1945). How to Solve It. Princeton University Press.
- Klein, G. (2007). Performing a project pre-mortem. Harvard Business Review.
- Checkland, P. (1981). Systems Thinking, Systems Practice. Wiley.
1---2name: problem-framing-audit3description: Step-back protocol — restate, generalise, specialise, invert, ask why, pre-mortem, check stakeholders, and audit framings before solving4---5
6# Problem Framing Audit (Discipline -1)
7
8
9> Before you solve, audit the frame. A flawless solution to the wrong problem is still a wrong answer.
10
11## Purpose
12
13The 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.
14
15The 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?"
16
17## When to Activate
18
19| Trigger | Activation |
20|---|---|
21| Single-file edit, < 15 minutes of work, mechanical task | **Skip** — frame audit adds friction without payoff |
22| Task uses the words "fix", "improve", "make faster", "speed up", "broken", "make it work" | **Always audit** — these phrases hide a symptom-frame |
23| Task spans 3+ files, requires architectural choice, or estimates > 15 minutes | **Always audit** |
24| User restates the same request after a failed attempt | **Always audit** — repeated failure is a signal the frame is wrong |
25| User says "just" do X, or "simply" Y, or "all you have to do is" | **Always audit** — these phrases mark unexamined frames |
26| User explicitly invokes `/problem-framing-audit` or asks "what am I missing?" | **Always audit** |
27
28The rule is asymmetric on purpose: trivial tasks pass through; non-trivial tasks audit first.
29
30## The Step-Back Protocol
31
32Eight 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.
33
34| # | Check | Activation question | Source |
35|---|---|---|---|
36| **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?* |
37| **2. Generalise** | What is this a special case of? | Naming the general class often reveals existing solutions and prior art. | Polya 1945 |
38| **3. Specialise** | What's the simplest concrete instance? | If the simplest case is already hard, the general case is the wrong target. | Polya 1945 |
39| **4. Invert** | What would make this worse? What would I do if I wanted to fail? | Inversion exposes hidden constraints. | Munger / Jacobi |
40| **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 |
41| **6. Pre-mortem** | Imagine we're done and it didn't work — what went wrong? | Reduces overconfidence by ~30% in field studies. | Klein 2007 |
42| **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) |
43| **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 |
44
45## The Symptom → Cause Move
46
47The 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.
48
49| Symptom-frame (what user said) | Cause-frame (what audit surfaces) | Right move |
50|---|---|---|
51| "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 |
52| "Fix this flaky test" | The test is correct; the system has a real race condition | Fix the race, not the test |
53| "Make the build less noisy" | The warnings are real — system is leaking handles | Fix the leaks; the noise was the diagnostic |
54| "Why does this query take 2 minutes?" | Query is fine; it returns 47M rows the UI then renders | Fix the contract, not the query |
55| "Add a workaround for this API quirk" | The "quirk" is the API enforcing a real constraint | Honour the constraint, not work around it |
56| "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 |
57
58In each row, the symptom-frame produces a working but pointless solution. The cause-frame produces the right one.
59
60## Output Markers
61
62When the frame audit fires and produces a different framing than the user's literal request, the response **must** make the move visible:
63
64| Marker | When to use |
65|---|---|
66| `**Frame**: Restated as ...` | Always when audit fires — confirms my understanding |
67| `**Cause-frame**: ...` (when the symptom-frame is being replaced) | When step 5 (Five Whys) or step 7 (Stakeholder) surfaces a different problem |
68| `**Considered framings**: (a) X, (b) Y — going with X because ...` | When step 8 surfaces a real alternative |
69| `**Pre-mortem**: If this fails, the most likely cause is ...` | When step 6 surfaces a non-obvious failure mode worth flagging |
70
71Markers are not boilerplate — they fire only when the audit produces something. A silent audit that produced no reframe needs no marker; just proceed.
72
73## Anti-Patterns
74
75| Anti-pattern | Why it fails | Correction |
76|---|---|---|
77| 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 |
78| 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 |
79| 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 |
80| 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 |
81| Ask 8 clarifying questions back-to-back | Audit becomes interrogation | One sharp question is better than 8 generic ones; pick the highest-leverage check |
82
83## Falsifiability Test (per PLAN-CT Lane C)
84
85Track 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?
86
87- **Target**: ≥ 20% (Russo & Schoemaker's data suggests cause-frames differ from symptom-frames ~30–40% of the time; 20% is a conservative pass)
88- **If 0%**: the audit is decorative. Either the activation rule is too narrow or the audit is rubber-stamping. Retire or rebuild.
89- **If 100%**: the audit is over-firing. The activation rule is too broad. Tighten triggers.
90
91## Integration
92
93| Surface | How frame-audit attaches |
94|---|---|
95| `critical-thinking/SKILL.md` | Inserted as **Discipline -1** before the Materiality Gate; this skill is its detailed body |
96| `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."* |
97| `deep-thinking.instructions.md` | The audit is a recommended first step on any deep-thinking session |
98| `planner` agent | Frame audit runs before plan decomposition |
99| `act-pass` skill | Step 1 of the 7-step pass *is* the frame audit |
100| `/problem-framing-audit` prompt | User-invokable trigger to force this skill on a stuck problem |
101
102## Background Reading
103
104- ACT/CRITICAL-THINKING-FAILURE-MODES.md §1 — the master failure mode and the step-back protocol
105- ACT/PLAN-critical-thinking-improvement.md Lane C — design rationale and falsifiability
106- Russo, J. E., & Schoemaker, P. J. H. (2002). *Winning Decisions*. Doubleday.
107- Mitroff, I. I., & Featheringham, T. R. (1974). On systemic problem solving and the error of the third kind. *Behavioral Science*, 19(6).
108- Polya, G. (1945). *How to Solve It*. Princeton University Press.
109- Klein, G. (2007). Performing a project pre-mortem. *Harvard Business Review*.
110- Checkland, P. (1981). *Systems Thinking, Systems Practice*. Wiley.
gabrielmoreira