subtractlisted

# subtract The most common mistake of smart engineers is to optimize a thing that should not exist. This skill runs before that mistake becomes possible: it takes a plan and returns a smaller one. Steps 1–2 of the algorithm, nothing else. Simplifying, accelerating, and automating belong to other skills — and running them on a part this skill should have deleted is the exact failure the algorithm exists to prevent. ## Phase 1 — Question (make the requirements less dumb) For every requirement, feature, phase, or part in the plan: 1. **Name the owner.** A person, not a department. "The roadmap says" and "best practice" are not owners. A requirement nobody will put their name to is deleted by default. The founder's name counts — but write it down, because seeing your own name against a weak requirement is half the cure. 2. **Ask what breaks without it.** Concretely — which user, which day, what do they see. "It would be less complete" is not breakage. 3. **Rate frequency × impact.** Common+high → keep for Phase 2 scrutiny. Rare+high → record for later, don't build now. Rare+low → gone. One person hit it once → it's an anecdote, not a requirement. 4. **Question hardest the requirements from the smartest source.** Those are the least-questioned ones in the pile — including requirements this assistant generated, which arrive pre-polished and are exactly the kind nobody pushes back on. ## Phase 2 — Delete Take what survived and cut past the comfortab