structured-reasoning

Name: structured-reasoning
Author: UnpaidAttention

84stars18forks

How to install structured-reasoning?

unpaidattention/fable5-methodology/structured-reasoning

$npx -y skills add UnpaidAttention/fable5-methodology --skill structured-reasoning

Installs into the current project.

Summary

A step-by-step reasoning protocol for problems that exceed one intuitive step — generate and compare candidates, track assumptions, reason backward or from a minimal case when stuck, sanity-check intermediates, and run a mandatory devil's-advocate pass before finalizing. Trigger

Files · 1

View on GitHub

SKILL.md

1	# Structured Reasoning
2
3	Weaker reasoning fails in three predictable ways: skipped steps, unexamined assumptions, and
4	committing to the first plausible approach. This protocol makes each failure procedurally hard.
5	Do the steps visibly (in text or notes) — silent multi-step reasoning drops steps unnoticed.
6
7	## Step 1: Decide if this needs explicit reasoning
8
9	Answer directly ONLY if all hold: solved this exact shape before, one step reaches it, wrong is
10	cheap. Otherwise reason explicitly — any one triggers it: novelty; high stakes; multiple
11	interacting constraints; ANY arithmetic/counting/indexing/state-tracking; or you don't know the
12	second step. When in doubt, reason explicitly — it's cheap insurance.
13
14	## Step 2: Generate 2–3 candidates before starting any
15
16	One candidate is a reflex, not a decision — and reflexes commit you to the first
17	plausible-but-wrong path. For each candidate: one line of mechanism. Compare on explicit
18	criteria (correctness first, then simplicity, failure modes, reversibility). Pick, and write
19	one line on why over the runner-up. If you genuinely see only one approach, spend 30 seconds
20	forcing a second — "what if I did the opposite / did nothing / did it backward?" — before
21	proceeding.
22
23	## Step 3: Maintain a visible assumptions list
24
25	Write assumptions as you make them: "assuming input is pre-sorted", "assuming single writer",
26	"assuming the ID is unique". Keep the list in view. Rule: when a conclusion feels off or an
27	intermediate surprises you, check the ASSUMPTIONS first — a wrong conclusion is usually a wrong
28	assumption, not broken logic. Test the load-bearing ones instead of trusting them.
29
30	## Step 4: When forward reasoning stalls, switch technique
31
32	- Backward: write the desired end state; ask "what must be true one step before this?";
33	chain back to now. Best when the goal is crisp and the path isn't.
34	- Minimal case: strip to the smallest non-trivial instance (n=1, one field, no
35	concurrency); solve THAT completely; then generalize. A solved small case is a foothold; a
36	half-solved big case is a swamp.
37	- Concrete example: push one specific real value through by hand. Stuck abstract reasoning
38	usually unsticks the moment a real number moves through it.
39
40	## Step 5: Sanity-check every intermediate conclusion
41
42	Don't wait for the end. One line per intermediate:
43	- Order of magnitude — is the number even plausible?
44	- Boundary — does it hold at 0, 1, and the max?
45	- Invariant — does what must always be true (count conserved, total unchanged, sum
46	non-negative) still hold?
47	A failed check here costs one line; a bad intermediate carried to the end costs the whole chain.
48
49	## Step 6: Mandatory devil's-advocate pass before finalizing
50
51	Never finalize a non-trivial answer without trying to break it:
52	1. State what would prove it WRONG — the specific input/case/condition that fails it.
53	2. Check that case.
54	3. Probe the edges (empty, boundary, huge), your least-certain assumption, and every step you
55	labeled "probably fine".
56	If you can't build a falsifier, say so — but try hard first. This pass catches the confident-
57	wrong answer that would otherwise ship.
58
59	## Worked example
60
61	Problem: "Pick a rate-limit algorithm for the API; must allow short bursts but cap sustained
62	rate."
63
64	- Step 1: multiple interacting constraints (burst vs sustained) → reason explicitly.
65	- Step 2 candidates: (A) fixed window — mechanism: count per clock-minute; (B) sliding window
66	log — timestamp per request; (C) token bucket — refill at sustained rate, bucket depth =
67	burst. Compare: A is simplest but allows 2× burst at window edges (fails the "cap sustained"
68	intent); B is exact but stores every timestamp (memory cost); C allows configured burst AND
69	caps sustained, O(1) state. Pick C over B: meets both constraints at lower cost.
70	- Step 3 assumptions: "clock is monotonic per node"; "limit is per-user not global" — flagged.
71	- Step 5 sanity: bucket depth 10, refill 1/s → a client can send 10 instantly then 1/s
72	sustained. Boundary check at depth=0: next request waits ~1 s. Plausible. Invariant: tokens
73	never exceed bucket depth — holds.
74	- Step 6 devil's advocate: what breaks it? Multi-node deployment — per-node buckets allow N×
75	the limit (the

People who liked this also viewed

6 picks

Type

structured-reasoning

84stars18forks

View on GitHub

How to install structured-reasoning?

unpaidattention/fable5-methodology/structured-reasoning

$npx -y skills add UnpaidAttention/fable5-methodology --skill structured-reasoning

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Structured Reasoning
2
3	Weaker reasoning fails in three predictable ways: skipped steps, unexamined assumptions, and
4	committing to the first plausible approach. This protocol makes each failure procedurally hard.
5	Do the steps visibly (in text or notes) — silent multi-step reasoning drops steps unnoticed.
6
7	## Step 1: Decide if this needs explicit reasoning
8
9	Answer directly ONLY if all hold: solved this exact shape before, one step reaches it, wrong is
10	cheap. Otherwise reason explicitly — any one triggers it: novelty; high stakes; multiple
11	interacting constraints; ANY arithmetic/counting/indexing/state-tracking; or you don't know the
12	second step. When in doubt, reason explicitly — it's cheap insurance.
13
14	## Step 2: Generate 2–3 candidates before starting any
15
16	One candidate is a reflex, not a decision — and reflexes commit you to the first
17	plausible-but-wrong path. For each candidate: one line of mechanism. Compare on explicit
18	criteria (correctness first, then simplicity, failure modes, reversibility). Pick, and write
19	one line on why over the runner-up. If you genuinely see only one approach, spend 30 seconds
20	forcing a second — "what if I did the opposite / did nothing / did it backward?" — before
21	proceeding.
22
23	## Step 3: Maintain a visible assumptions list
24
25	Write assumptions as you make them: "assuming input is pre-sorted", "assuming single writer",
26	"assuming the ID is unique". Keep the list in view. Rule: when a conclusion feels off or an
27	intermediate surprises you, check the ASSUMPTIONS first — a wrong conclusion is usually a wrong
28	assumption, not broken logic. Test the load-bearing ones instead of trusting them.
29
30	## Step 4: When forward reasoning stalls, switch technique
31
32	- Backward: write the desired end state; ask "what must be true one step before this?";
33	chain back to now. Best when the goal is crisp and the path isn't.
34	- Minimal case: strip to the smallest non-trivial instance (n=1, one field, no
35	concurrency); solve THAT completely; then generalize. A solved small case is a foothold; a
36	half-solved big case is a swamp.
37	- Concrete example: push one specific real value through by hand. Stuck abstract reasoning
38	usually unsticks the moment a real number moves through it.
39
40	## Step 5: Sanity-check every intermediate conclusion
41
42	Don't wait for the end. One line per intermediate:
43	- Order of magnitude — is the number even plausible?
44	- Boundary — does it hold at 0, 1, and the max?
45	- Invariant — does what must always be true (count conserved, total unchanged, sum
46	non-negative) still hold?
47	A failed check here costs one line; a bad intermediate carried to the end costs the whole chain.
48
49	## Step 6: Mandatory devil's-advocate pass before finalizing
50
51	Never finalize a non-trivial answer without trying to break it:
52	1. State what would prove it WRONG — the specific input/case/condition that fails it.
53	2. Check that case.
54	3. Probe the edges (empty, boundary, huge), your least-certain assumption, and every step you
55	labeled "probably fine".
56	If you can't build a falsifier, say so — but try hard first. This pass catches the confident-
57	wrong answer that would otherwise ship.
58
59	## Worked example
60
61	Problem: "Pick a rate-limit algorithm for the API; must allow short bursts but cap sustained
62	rate."
63
64	- Step 1: multiple interacting constraints (burst vs sustained) → reason explicitly.
65	- Step 2 candidates: (A) fixed window — mechanism: count per clock-minute; (B) sliding window
66	log — timestamp per request; (C) token bucket — refill at sustained rate, bucket depth =
67	burst. Compare: A is simplest but allows 2× burst at window edges (fails the "cap sustained"
68	intent); B is exact but stores every timestamp (memory cost); C allows configured burst AND
69	caps sustained, O(1) state. Pick C over B: meets both constraints at lower cost.
70	- Step 3 assumptions: "clock is monotonic per node"; "limit is per-user not global" — flagged.
71	- Step 5 sanity: bucket depth 10, refill 1/s → a client can send 10 instantly then 1/s
72	sustained. Boundary check at depth=0: next request waits ~1 s. Plausible. Invariant: tokens
73	never exceed bucket depth — holds.
74	- Step 6 devil's advocate: what breaks it? Multi-node deployment — per-node buckets allow N×
75	the limit (the

People who liked this also viewed

6 picks

Type