Plan Simplify

Read a written plan — a migration plan, a design document, an RFC, a spec, a runbook set — together with the system it is meant to change, and report what can be removed or merged without losing safety, speed or a stated requirement. Each finding states what the plan says, why that part is redundant, what replaces it, what goes away and what it costs. The findings go into a separate document next to the plan. The plan itself is never edited by this skill.

The question this review asks is "what here does not pay for itself?", not "what will kill this?". The second question is a pre-mortem and belongs to awesome-design-doc. Mistakes in the plan's logic surface along the way and are reported too, but the main product is a shorter plan that is just as safe.

Bundled file (load on demand):

• references/simplification-lenses.md — the catalogue of over-engineering patterns this review hunts for, each with the question that exposes it and the evidence that confirms it. Read it before the hunting pass (step 5).

When to Activate

• "Simplify this plan", "trim this design", "find over-engineering in the spec", "what can we cut from this RFC without losing safety".
• A long plan has grown over several revisions, and nobody has checked whether each mechanism still earns its place.
• The owner wants recommendations before implementation starts, while a change is still a text edit and not rewritten code.

Do not activate for these jobs. A plan that does not exist yet goes to awesome-design-doc, which writes it. A pre-mortem of a chosen approach also goes to awesome-design-doc. Code already written goes to awesome-architecture-audit for a whole project or awesome-code-review for one diff. Prose quality of a document goes to awesome-document-style.

Ground rules