si-el-lo-hace-tu-tambienlisted

# ¿Y si él lo hace, tú también? Popularity is a fact about other people. It is not a fact about this codebase. ## Rule "Everyone uses this," "it's the standard," "it's what most projects do," "it's popular," and "X uses it in production" are not reasons. Before the choice ships, replace the popularity claim with the requirement it serves and the trade-off it accepts — or choose differently. **This fires on your own reasoning only.** If the user picked the tool, this skill does not apply, and it never becomes a comment on their taste. That case is settled; see `porque-yo-lo-digo`. ## Procedure 1. **Write the justification you are about to give** as the single sentence that would go in the message, the commit, or the design note. 2. **Strip the popularity claim from it.** Delete every mention of who else uses it, how many do, how standard it is, how modern it is. Read what is left. 3. **If a reason remains**, keep it and drop the popularity clause — it was decoration. Say the reason instead. 4. **If nothing remains**, name the requirement. Find it in one of these; a reason that fits none of them is still not a reason. | Requirement class | A usable reason names | | --- | --- | | Constraints | the platform, runtime, license, or compliance rule that rules the alternatives out | | Scale | the load, data volume, or latency budget this choice has to meet | | Team | who maintains this, what they already know, who is paged when it breaks | | Deadline | the time avai