---

name: radical-simplification description: Cognitive moves for collapsing complexity — reframe, clarify, reduce, decompose, invert, constrain, transfer, generalize, audit — distilled from the working method of mathematicians, physicists, and software engineers known for turning hard problems into simple solutions (Pólya, Feynman, Hamming, Brooks, Knuth, Dijkstra, Lamport, Tao, Grothendieck, Munger, Hofstadter). Use when stuck on a complex problem, when a proposed design feels overengineered, when reviewing code that has accreted accidental complexity, or when the user wants an elegant solution to a hard engineering or product problem. Triggers on phrases like "this feels too complicated", "we are going in circles", "there must be a simpler way", "interview me about this plan", "find the underlying problem", and on stuck-state moments where forward search has run out and the agent needs a different angle.

Radical Simplification — Cognitive Moves for Collapsing Complex Problems

Distillation of the documented working method of mathematicians, physicists, and engineers who consistently turn complex problems into simple solutions. The skill is not a step list — it is a toolbox of cognitive moves, each correcting a specific wrong default a capable model has when faced with complexity. The moves are mostly orthogonal; pick the one that matches the symptom.

This is the thinking layer that sits above refactoring (code-simplifier), metric design (deterministic-metric-design), and reviews (design-review). Those skills apply a methodology to a known shape of artifact. This skill is the methodology itself — how to arrive at the simple shape in the first place.

When to Apply

Use this skill when:

• The user says the problem feels too complicated, that the team is going in circles, or that there must be a simpler way
• A proposed design has accreted parameters, dependencies, or branches and feels overengineered
• A plan has been drafted but unresolved decisions remain, and the agent is about to commit to assumed answers
• A bug investigation has tried several variants of the same approach without progress
• A review surfaces complexity that may be accidental (Brooks) rather than essential
• The agent is asked to find an elegant solution to a hard engineering or product problem
• Forward search has exhausted and the agent needs a different angle (work backwards, invert, transfer from another domain)
• The agent is producing fluent-sounding output but cannot back it up under expansion (Feynman test)

This skill is not for cleaning up code that already does the right thing — that is code-simplifier. Use this when the approach itself is what needs to get simpler.

How to Use

The nine categories are orthogonal cognitive moves. Match the move to the symptom:

Symptom	Reach for	First rule to read
Solving feels off — maybe the wrong problem	Frame	frame-restate-problem
Plan drafted but unresolved decisions remain	Clarify	clarify-interview-one-at-a-time
Drowning in cases, parameters, branches	Reduce	reduce-toy-case-first
Parts are tangled; changes ripple	Decompose	decomp-orthogonal-axes
Forward search is exponential or stuck	Invert	invert-work-backwards
Missing the structural truth of the system	Constrain	constrain-name-the-invariant
Stuck inside the current vocabulary	Transfer	transfer-cross-domain-analogue
The specific problem keeps resisting	Generalize	gen-rising-sea
Producing fluent output you cannot back up	Audit	audit-feynman-technique

For category overviews and the ordering rationale, see references/_sections.md.

Rule Categories

#	Category	Prefix	Move	Rules
1	Reframe the Problem	frame	Restate, separate essential from accidental, find the decision	3
2	Clarify Through Interview	clarify	One-at-a-time questions with recommended answers; read the source before asking	2
3	Reduce to the Smallest Case	reduce	Toy case, limit cases, Pareto compression	3
4	Decompose Along Orthogonal Axes	decomp	Orthogonal axes, WHAT vs HOW	2
5	Invert the Search	invert	Work backwards, assume failure	2
6	Constrain with Invariants and Symmetries	constrain	Name the invariant, dimensional check	2
7	Transfer From Another Domain	transfer	Cross-domain analogue, vocabulary lock-in	2
8	Generalize Until the Problem Dissolves	gen	Rising sea	1
9	Audit Your Own Understanding	audit	Feynman, name the confusion, Fermi check	3

Quick Reference

1. Reframe the Problem

• frame-restate-problem — Restate in your own words before solving; surfaces the wrong-problem case while it is still cheap
• frame-essential-vs-accidental — Brooks's distinction: name each piece of complexity as inherent or layered-on
• frame-find-decision-point — Find the decision the answer must change; answer that, not the literal question

2. Clarify Through Interview

• clarify-interview-one-at-a-time — Walk the design tree one branch at a time; every question paired with your recommended answer so the user reviews a position, not generates one
• clarify-prefer-source-over-asking — If a grep, file read, or runtime check would answer it, do that — only ask what the source cannot tell you

3. Reduce to the Smallest Case

• reduce-toy-case-first — Solve n=1 fully before generalizing; the structure of the big problem becomes visible
• reduce-limit-cases — Probe zero, infinity, empty, identity to expose where the design degrades
• reduce-pareto-compress — Design for the 20% of inputs that produce 80% of the result

4. Decompose Along Orthogonal Axes

• decomp-orthogonal-axes — Axes are correct when changing one does not force changing another; verbs over today's nouns
• decomp-what-vs-how — Write the WHAT before debating the HOW; the spec is the referee

5. Invert the Search

• invert-work-backwards — When forward search is exponential, ask what must be true one step before the goal
• invert-assume-failure — Write the postmortem before writing the design (Munger's inversion)

6. Constrain with Invariants and Symmetries

• constrain-name-the-invariant — The property that does not change is often the answer in disguise
• constrain-dimensional-check — Mismatched units, types, or categories are bugs before they are runtime failures

7. Transfer From Another Domain

• transfer-cross-domain-analogue — Search for the structural twin in another domain; the twin's solution often transplants
• transfer-suspect-vocabulary-lock-in — Suffix accretion (Manager, Helper, Coordinator) signals the original noun is wrong

8. Generalize Until the Problem Dissolves

• gen-rising-sea — Grothendieck's rising sea; the more abstract version is sometimes the easier one — but only if it has fewer concepts, not more

9. Audit Your Own Understanding

• audit-feynman-technique — Unfold technical shorthand into beginner-vocabulary sentences; the hand-waves are the gaps
• audit-name-the-confusion — When stuck, name what you do not know — do not retry variants of the same approach
• audit-fermi-sanity-check — Bound the answer order-of-magnitude before producing it; 10× disagreements are the signal

Related Skills

• code-simplifier — Refactoring patterns once the right approach is known (this skill ends, that one begins)
• deterministic-metric-design — Applies this methodology to the specific problem of inventing metrics
• design-review — Applies this methodology to the specific problem of reviewing UI

Authoring Note

These moves are load-bearing, not decorative. The wrong default each rule corrects is named in the rule itself — if a rule restates something a capable model already does correctly, cut it. The coverage of the skill is proven by /dev-skill:eval on real complex-problem prompts, not by hitting a rule count.