Solve
Slow down. The first idea is rarely the best idea, and an
unverified idea is worthless. Think, solve, then prove.
The Shape
Understand — What is the real problem? Not the
symptom, not the first framing. Find the essential
difficulty. Name the constraints, the invariants, the
failure modes.
Solve — Find the solution. Explore the space
honestly — if the obvious approach has a flaw, name it
and move on. The right solution often isn't the first
one; it's the one that survives scrutiny.
Prove — Show it works. Trace every path. Name every
invariant. End with QED or a counterexample. If you find
a counterexample, return to step 2 — a disproved solution
is not a solution. (Invoke /prove mentally or literally.)
Summarize — Prose for humans. What's the solution,
why is it right, what did you rule out and why.
On Activation
Work through all four steps. Do not skip the proof — it's
the point. Present your work: the reasoning, the formal
argument, the summary.
If the proof fails, that's the skill working. Iterate until
the solution and proof are consistent, or report that the
problem is harder than it looked.
Anti-patterns
- Solving without understanding — you'll solve the
wrong problem.
- Skipping the proof — "it works" without verification
is hope, not engineering.
- Proving the easy part — prove the part you're least
sure about, not the part that's obviously correct.
- One iteration — if your first solution passes the
proof on the first try, you probably didn't probe hard
enough. Actively try to break it.
The user has a problem. Understand it, solve it, prove it,
summarize it.
1---2name: solve3description: Think deeply about a problem, find the right solution, then prove it correct. Rigor over speed.4---56# Solve78Slow down. The first idea is rarely the best idea, and an9unverified idea is worthless. Think, solve, then prove.1011## The Shape12131. **Understand** — What is the real problem? Not the14 symptom, not the first framing. Find the essential15 difficulty. Name the constraints, the invariants, the16 failure modes.17182. **Solve** — Find the solution. Explore the space19 honestly — if the obvious approach has a flaw, name it20 and move on. The right solution often isn't the first21 one; it's the one that survives scrutiny.22233. **Prove** — Show it works. Trace every path. Name every24 invariant. End with QED or a counterexample. If you find25 a counterexample, return to step 2 — a disproved solution26 is not a solution. (Invoke `/prove` mentally or literally.)27284. **Summarize** — Prose for humans. What's the solution,29 why is it right, what did you rule out and why.3031## On Activation3233Work through all four steps. Do not skip the proof — it's34the point. Present your work: the reasoning, the formal35argument, the summary.3637If the proof fails, that's the skill working. Iterate until38the solution and proof are consistent, or report that the39problem is harder than it looked.4041## Anti-patterns4243- **Solving without understanding** — you'll solve the44 wrong problem.45- **Skipping the proof** — "it works" without verification46 is hope, not engineering.47- **Proving the easy part** — prove the part you're least48 sure about, not the part that's obviously correct.49- **One iteration** — if your first solution passes the50 proof on the first try, you probably didn't probe hard51 enough. Actively try to break it.5253---5455The user has a problem. Understand it, solve it, prove it,56summarize it.
corygabrielsen