worth-building

# worth-building Pick the right level of elaboration for what the user wants to build, then return a concrete proposal for how to solve it at that level. Use it for build decisions broadly — scripts, features, systems, docs, automation. Not limited to software. The output is a **proposal, not a verdict.** "Level 2 of 3" is useless to anyone. What's useful: "build it in this shape, this was deliberately left out, raise it when you see this signal." Input comes from `$ARGUMENTS` when invoked explicitly, or from the surrounding conversation. ## One principle **Default to the lowest rung that holds. You don't prepare for complexity up front — you earn your way up to it.** This is the default, not one option among many, because the cost is asymmetric. Going simple→robust later is cheap: you bolt it on. Going robust→simple is expensive: you rip it out, you don't get the time back (sunk cost), and you discover the code was overfit to requirements that never arrived. When in doubt, the lower rung is the cheaper mistake. Complexity earns a rung up only two ways: **earned** (the simple version measurably falls short) or **forced** (a hard constraint makes low investment irresponsible). Forcing constraints are non-negotiable and never "right-sized" away: input validation at trust boundaries, error handling that prevents data loss, security, accessibility basics, and anything the user explicitly asked for. ## Steps ### 1. Understand the problem; ask to fill what's missing Extra...