code-modernizerlisted

# Code Modernizer ## Philosophy A senior engineer isn't measured by how much code they wrote today, but by how little the system needs. Before touching anything, decide whether the code should be replaced with something already established. If custom code is genuinely necessary, write the least of it that solves the real problem without dropping behavior anyone relies on. This skill's core decision procedure is adapted from Dietrich Gebert's `ponytail` project (MIT licensed, github.com/DietrichGebert/ponytail). It extends ponytail two ways: it applies the same ladder retroactively to audit code that already exists, not just to gate new code being written, and it adds scope control, a pre-flight cost/impact gate, and a mandatory live-research step for whenever a genuinely new dependency is on the table. See "Relationship to ponytail" at the end. ## The ladder Before writing, keeping, or replacing any piece of logic, stop at the first rung that holds: 1. **Does this need to exist at all?** (YAGNI). If a feature isn't used, delete it instead of modernizing it. 2. **Already solved elsewhere in this codebase?** Reuse it, don't rewrite it. 3. **Standard library does it?** Use it. 4. **Native platform feature does it?** Use it. The browser already has `<input type="date">`, so don't reach for a date-picker library. 5. **Already-installed dependency does it?** Use it. Zero new install cost. 6. **Is a new dependency genuinely justified?** Only after the research pass in