frame-check

Files (2)

• SKILL.md
• frame-moves.md · references/

SKILL.md (first lines)

# Frame check

Most failed work is not a wrong answer. It is a right answer to the wrong
question. Kimball named this the error of the third kind in 1957 and Mitroff
built a practice on it. The work is rigorous, the execution is clean, and it is
aimed at something that was never the problem.

Catch it before the work commits.

## What you are looking for

A problem statement arrives sounding like an observation. "Onboarding is too
slow." "Users are confused." "It's a race condition." None of those are
observations. Someone watched something, selected part of it, decided what it
meant, and concluded — and the sentence you received is the last link with the
chain removed. Your job is to put the chain back and ask what else the bottom of
it supports.

Two different failures produce a wrong problem, and they need different tools.

**The conclusion outran the evidence.** What was observed supports several
readings, and one got picked without anyone noticing a choice was made. Argyris's
ladder of inference is the tool here: walk back down to what a camera would have
recorded.

**The evidence is sound and the goal is wrong.** The diagnosis holds up and is
aimed at an objective nobody has examined. Climbing down the ladder will never
find this, because the goal never entered as evidence. Argyris's double-loop
learning is the tool: ask which governing goal makes this count as a problem at
all.

Check the first. Check the second before you finish.

## 1. Get rung one before you say anything

The bottom rung is observable data — what a recording device would have captured,
before anyone interpreted it. Go find it. An assertion about the evidence that
you did not actually check is the same error you are here to catch.

Where rung one usually hides:

- **A recurring bug.** `git log` the file. Has this been "fixed" before, and
  what did each fix assume? Three fixes to one symptom is strong evidence the
  frame is wrong, not that the engineers were careless.
- **An incident or failure.** The raw stack trace and log lines, not the summary
  of them. Summaries are already rung three.
- **A metric.** How the dashboard actually computes it, in the query or the
  event definition. Metric names drift from metric definitions constantly, and a
  problem stated in terms of a name is often a problem about something else.
- **A user complaint.** The verbatim, not the paraphrase in the ticket title.
- **A "slow" or "flaky" claim.** The actual numbers and their distribution. "Slow"
  is never rung one.

When you genuinely cannot reach any of it, say so plainly and name the smallest
thing that would produce it. "There is nothing at rung one here; the fastest way
to get some is X" is a legitimate and useful answer. Inventing an analysis on top
of an empty bottom rung is not.

## 2. Separate what was seen from what was concluded

Do not produce a rung-by-rung table. The canonical ladder has seven rungs and
several of them do not separate cleanly under pressure, so filling in all seven
yields a worksheet rather than a finding. Use it as a lens and report only the
catches.

Ask, in order, and keep the answers to yourself:

- What would a camera have recorded?
- Which part of that got attended to, and what got dropped?
- What was it taken to mean?
- What was concluded, and what is being done about it?

The catch is wherever an answer is larger than the answer beneath it. That is the
leap. Name it in one sentence, quoting the stated problem and the observation it
actually rests on.

## 3. Generate frames the evidence supports

Three or so, no more. Every frame must be consistent with rung one — a fabricated
alternative is worse than no alternative, because it costs the user attention and
teaches them to distrust the exercise.

Always include the null frame: this is not a problem, or not one worth solving.
Maybe the signal is noise, maybe the cost of the fix exceeds the cost of living
with it, maybe the population you are worried about was never going to convert.
Solving a non-problem is a Type III error too, and it is the one nobody checks
for.

For the generative moves — changing the actor, changing the level, looking
outside the boundary, bright spots, inversion, Ackoff's dissolve — read
`references/frame-moves.md`. It also carries the canonical ladder and worked
examples across a bug, a product metric, and an org problem.

## 4. Land a discriminating test

Argyris cared about making inferences *testable*, not merely visible. A frame
check that ends in doubt has made the user worse off: they now have less
confidence and no more information. Always land the next observation.

A good test is cheap (minutes or hours), decisive (the frames predict different
results), and available (the data exists or can be got today). State which result
supports which frame **before** it runs. Predicting in advance is what stops the
result from being absorbed into whichever frame someone already preferred.

If no cheap test discriminates, say that too, and name the expensive one. That is
still more useful than a list of possibilities.

## 5. Double-loop check

Before you finish, ask once: what goal makes this a problem? Then ask whether
that goal is the right goal.

Some signals that the goal is the rotten part rather than the diagnosis — the
same problem keeps recurring in different clothes, the fix always trades against
something nobody will name, or the honest answer to "what happens if we just
don't solve this?" is "not much."

If the goal survives, do not mention it. If it does not, that is the finding, and
it outranks everything above it.

From petekp/claude-code-setup, MIT.

More from petekp/claude-code-setup