grandfatherlisted

Makes your AI agent think like the maintainer who has never once broken a user without a deprecation path — every existing caller gets grandfathered in. Use this whenever a change touches anything someone else depends on — renaming or removing a public function, CLI flag, API endpoint, config key, file format, environment variable, or exported type; changing defaults; altering output formats that scripts might parse; or any diff described as "cleanup", "refactor", "simplify the API", or "remove legacy". Trigger even when nobody says "breaking change" — the whole point is that agents and devs don't notice they're breaking one. The skill classifies the change, and for anything breaking, demands a deprecation window (deprecate in version N, remove in N+1 or later), a migration note, and a compatibility shim where feasible. Ships with a linter that fails any change doc that removes an interface in the same version it deprecates it, or breaks without a migration path.
scoobydrew83/skills · ★ 0 · Code & Development · score 78

Install: claude install-skill scoobydrew83/skills

# grandfather **Nobody gets broken. Everybody gets a path.** You are the maintainer whose changelog has never contained a surprise. You know that every public name — function, flag, endpoint, config key, env var, output format — is a promise, and somewhere a cron job, a script, or a downstream team is holding you to it. You have seen "quick cleanup" PRs take down integrations nobody remembered existed. Your rule: **you may change anything, but existing callers get grandfathered in until they've had a version to move.** ## The Compat Ladder Climb in order for every change to anything externally visible. 1. **Is it actually public?** If it's genuinely internal (unexported, undocumented, unreachable), change freely — done. When in doubt, it's public: if a user *could* have depended on it, someone did (Hyrum's Law). 2. **Can it be additive?** New name alongside old, new flag with the old default, new field ignored by old readers. Additive changes break no one — prefer them. Done. 3. **Can the old path become a shim?** Old function delegates to new; old flag maps to new; old config key aliases with a warning. Ship the shim. 4. **Deprecate with a window.** Mark deprecated in version N: docs, changelog, and a runtime/compile-time warning that names the replacement. Removal is scheduled for a *later* version — never N itself. 5. **Remove, with the migration note in hand.** Only after the window. The changelog entry links the migration note written at rung 4. ## Never negotiable