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:

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

Rule Categories

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.