problem-framing

Name: problem-framing
Author: UnpaidAttention

84stars18forks

How to install problem-framing?

unpaidattention/fable5-methodology/problem-framing

$npx -y skills add UnpaidAttention/fable5-methodology --skill problem-framing

Installs into the current project.

Summary

Shape a problem before solving it — check the premise (XY problems, false dichotomies), find the canonical name for the problem shape, locate the hard kernel, and factor fuzzy asks into orthogonal decisions. Trigger this BEFORE solving whenever a request specifies a mechanism rat

Files · 1

View on GitHub

SKILL.md

1	# Problem Framing
2
3	Weaker models answer the question as handed to them. The frame — what's actually being asked,
4	what shape the problem is, where the difficulty lives — is accepted without examination, and a
5	perfectly-executed answer to the wrong frame is worthless. Run these four moves, in order,
6	before solving anything non-trivial. Total cost: a minute. Then commit to the frame and solve.
7
8	## Move 1: Check the premise — once, cheaply
9
10	- XY problem tell: the request names a mechanism, not an outcome ("add a retry here",
11	"make this a singleton"). The stated mechanism may be a poor path to the unstated goal.
12	Response: deliver what was asked AND name the suspected goal with a sturdier path in one
13	line — "this adds the retry; if the underlying goal is zero lost orders, an outbox pattern
14	is sturdier — say the word."
15	- False dichotomy tell: "A or B?" Spend one beat checking for a dominant option C. If C
16	exists, present it as an option — and still answer A-vs-B on its merits. Never refuse the
17	question that was asked.
18	- Discipline: question the frame exactly ONCE. If the user reaffirms their frame, execute
19	it fully and drop the reframe. Relitigating a settled premise is nagging, not insight.
20
21	## Move 2: Name the problem
22
23	Strip the problem to one sentence with the domain nouns removed, and ask: **what is the
24	canonical name for this shape?**
25
26	- "Many workers all retry at the same instant" → thundering herd.
27	- "Check if it exists, then create it" → TOCTOU race / upsert problem.
28	- "The same message may arrive twice" → idempotency.
29	- "One query per row of the parent query" → N+1.
30	- "Two systems each think they're primary" → split brain.
31
32	If the shape has a name, it has a literature: known solutions AND known pitfalls. Solving a
33	named problem from scratch reinvents the bugs along with the wheel. Adopt the canonical
34	solution unless a real constraint forbids it — and name that constraint explicitly when you
35	deviate. If you can't find a name after a genuine attempt, note that: truly nameless problems
36	deserve more design caution.
37
38	## Move 3: Locate the hard kernel
39
40	Most tasks are ~80% mechanical, ~20% genuinely hard — and the outcome is decided by the 20%.
41	Triage each part with one question: **"could I write this straight through without
42	backtracking?"**
43
44	- Yes → mechanical. Execute cheaply, later.
45	- No — you can't yet see the solution's shape → that's the kernel. It gets solved FIRST, with
46	full explicit reasoning (candidates, assumptions, devil's advocate), before any boilerplate
47	is typed.
48
49	If you finish and nothing ever made you slow down, either the task was trivial or you missed
50	the kernel — re-scan before delivering.
51
52	## Move 4: Factor fuzzy asks into orthogonal decisions
53
54	A fuzzy problem ("make our exports better") is usually 2–4 independent decisions tangled
55	together (format? delivery mechanism? sync-vs-async? permissions?). List the axes; confirm
56	they're independent (a choice on one doesn't force a choice on another); decide or ask per
57	axis. A question that seemed vague becomes 3 small crisp ones — and the user can answer each
58	with one word.
59
60	## Worked example
61
62	Request: "Should we use Redis or Postgres for the job queue?"
63
64	- Move 1 (premise): dichotomy tell → one beat for C: the codebase already runs on Postgres and
65	the volume is ~200 jobs/hour. A dedicated queue (C: keep it in Postgres with SKIP LOCKED —
66	or D: a managed queue) may dominate. Present C, still answer A-vs-B.
67	- Move 2 (name): the shape is a work queue with at-least-once delivery — canonical patterns:
68	`SELECT ... FOR UPDATE SKIP LOCKED` (Postgres), Redis streams, SQS. Known pitfalls attached
69	to each: visibility timeouts, poison messages, redelivery.
70	- Move 3 (kernel): the hard part isn't the store — it's failure semantics (what happens when
71	a worker dies mid-job). That decision gets the explicit reasoning; the client library choice
72	is mechanical.
73	- Move 4 (axes): (a) delivery guarantee needed, (b) throughput, (c) operational budget for a
74	new stateful service. Three crisp questions instead of one vague one.
75	- Outcome: "At 200 jobs/hour with Postgres alre

People who liked this also viewed

6 picks

Type

problem-framing

84stars18forks

View on GitHub

How to install problem-framing?

unpaidattention/fable5-methodology/problem-framing

$npx -y skills add UnpaidAttention/fable5-methodology --skill problem-framing

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Problem Framing
2
3	Weaker models answer the question as handed to them. The frame — what's actually being asked,
4	what shape the problem is, where the difficulty lives — is accepted without examination, and a
5	perfectly-executed answer to the wrong frame is worthless. Run these four moves, in order,
6	before solving anything non-trivial. Total cost: a minute. Then commit to the frame and solve.
7
8	## Move 1: Check the premise — once, cheaply
9
10	- XY problem tell: the request names a mechanism, not an outcome ("add a retry here",
11	"make this a singleton"). The stated mechanism may be a poor path to the unstated goal.
12	Response: deliver what was asked AND name the suspected goal with a sturdier path in one
13	line — "this adds the retry; if the underlying goal is zero lost orders, an outbox pattern
14	is sturdier — say the word."
15	- False dichotomy tell: "A or B?" Spend one beat checking for a dominant option C. If C
16	exists, present it as an option — and still answer A-vs-B on its merits. Never refuse the
17	question that was asked.
18	- Discipline: question the frame exactly ONCE. If the user reaffirms their frame, execute
19	it fully and drop the reframe. Relitigating a settled premise is nagging, not insight.
20
21	## Move 2: Name the problem
22
23	Strip the problem to one sentence with the domain nouns removed, and ask: **what is the
24	canonical name for this shape?**
25
26	- "Many workers all retry at the same instant" → thundering herd.
27	- "Check if it exists, then create it" → TOCTOU race / upsert problem.
28	- "The same message may arrive twice" → idempotency.
29	- "One query per row of the parent query" → N+1.
30	- "Two systems each think they're primary" → split brain.
31
32	If the shape has a name, it has a literature: known solutions AND known pitfalls. Solving a
33	named problem from scratch reinvents the bugs along with the wheel. Adopt the canonical
34	solution unless a real constraint forbids it — and name that constraint explicitly when you
35	deviate. If you can't find a name after a genuine attempt, note that: truly nameless problems
36	deserve more design caution.
37
38	## Move 3: Locate the hard kernel
39
40	Most tasks are ~80% mechanical, ~20% genuinely hard — and the outcome is decided by the 20%.
41	Triage each part with one question: **"could I write this straight through without
42	backtracking?"**
43
44	- Yes → mechanical. Execute cheaply, later.
45	- No — you can't yet see the solution's shape → that's the kernel. It gets solved FIRST, with
46	full explicit reasoning (candidates, assumptions, devil's advocate), before any boilerplate
47	is typed.
48
49	If you finish and nothing ever made you slow down, either the task was trivial or you missed
50	the kernel — re-scan before delivering.
51
52	## Move 4: Factor fuzzy asks into orthogonal decisions
53
54	A fuzzy problem ("make our exports better") is usually 2–4 independent decisions tangled
55	together (format? delivery mechanism? sync-vs-async? permissions?). List the axes; confirm
56	they're independent (a choice on one doesn't force a choice on another); decide or ask per
57	axis. A question that seemed vague becomes 3 small crisp ones — and the user can answer each
58	with one word.
59
60	## Worked example
61
62	Request: "Should we use Redis or Postgres for the job queue?"
63
64	- Move 1 (premise): dichotomy tell → one beat for C: the codebase already runs on Postgres and
65	the volume is ~200 jobs/hour. A dedicated queue (C: keep it in Postgres with SKIP LOCKED —
66	or D: a managed queue) may dominate. Present C, still answer A-vs-B.
67	- Move 2 (name): the shape is a work queue with at-least-once delivery — canonical patterns:
68	`SELECT ... FOR UPDATE SKIP LOCKED` (Postgres), Redis streams, SQS. Known pitfalls attached
69	to each: visibility timeouts, poison messages, redelivery.
70	- Move 3 (kernel): the hard part isn't the store — it's failure semantics (what happens when
71	a worker dies mid-job). That decision gets the explicit reasoning; the client library choice
72	is mechanical.
73	- Move 4 (axes): (a) delivery guarantee needed, (b) throughput, (c) operational budget for a
74	new stateful service. Three crisp questions instead of one vague one.
75	- Outcome: "At 200 jobs/hour with Postgres alre

People who liked this also viewed

6 picks

Type