before-buildinglisted

# Before building **Settle whether a thing should exist before building it.** A question from me is a question, not approval. I ask "do we need this?" more often than "is this correct?" — answer that one first, in the same reply, before there is code to defend. Then work the checklist, stopping at the first "no". Most ideas die at step 1; that is the checklist working, not failing. 1. **What already exists?** Assume it has been built and go find who built it — platform and stdlib first, then the ecosystem. **Cite what you find, a URL per fact, never from memory**: if you did not open it, you do not know it. Note what they call it, too — a feature inventing fresh vocabulary for something already named is a feature nobody finds. Searching is the step, not a formality before it. **Novelty is not the test.** Most of what I build is a better-fitting version of something that exists; `poops` is one of many bundlers. Finding nothing is no green light — the first possibility is nobody wanted it, and you must say why they were wrong. 2. **What distinct value would mine add?** The gate. Not "do they have this too" but **what does a user get from theirs, and what would they get from mine that they cannot get there?** Two tools ship the same bullet and deliver opposite value. Simpler, better-fitting, or mine to own rather than wait on, are all real answers. So is **"it exists but does not meet my standards"** — in practice my most common one. A pa