Inherit-Legacy-Style: The Skill That Stops Claude From "Helpfully" Rewriting Your Old Codebase

I'll admit it: every time I drop an agent onto a hand-written legacy codebase, I get a little twitchy. Not because the agent is bad — it's because it's too good. It sees an old Express app and wants to refactor it to ESM. It sees a Python 2.7 module and quietly rewrites it in 3.12 style. It sees your bespoke error-handling convention and "helpfully" replaces it with the textbook idiom it was trained on. You come back to your desk and half your git diff is style churn you never asked for.

That's the problem inherit-legacy-style exists to solve. It sits in the SkillsMP marketplace under the ECC umbrella (246k stars and counting on the parent repo), and it's one of the more thoughtful pieces of agent infrastructure I've read this month. Here's what I think after sitting with it for a while.

What it actually does

Strip away the marketing and inherit-legacy-style does three things, in order:

1. Detects whether you've run it before by checking for .ai-style-rules.md at the project root. First run = full scan. Subsequent runs = incremental sniff against git diff.
2. Scans the codebase along four "meta-architecture" dimensions — File Anatomy (declaration order), State & Control Flow (naming), Infrastructure (where cross-cutting utils live), and Error Handling (try/catch vs. interceptor vs. Result). Critically, it does not touch syntax or tech-stack choices. It's measuring the shape of how you write, not what you write.
3. Resolves conflicts one at a time with you, then writes the consensus into .ai-style-rules.md with three mandatory sections: Golden Files (real exemplars), Naming & State-Control Rules, and DONTs. Optionally, it pokes a @.ai-style-rules.md reference into your CLAUDE.md so the agent loads it on every subsequent turn.

The thing I appreciate most is the framing. The skill is honest that it's not enforcing quality — it's enforcing alignment. Your code might be quirky. Your error handling might be weird. The skill doesn't care. It cares that the agent doesn't suddenly start doing it differently.

Why it matters

Here's the dirty secret of working with coding agents on legacy code: the agent's pretrained defaults are usually better than your legacy code's conventions. ES modules are better than CommonJS. Composition is better than inheritance. Result<T, E> is better than thrown exceptions in many contexts. But "better" is irrelevant if the goal is consistency within the project, and that's the gap this skill fills.

There's also a quieter benefit. By forcing the agent to open every code-writing turn with a "compliance declaration" naming the exemplar it's following and the DONTs it's avoiding, you get a paper trail in the reasoning chain. You can see why the agent made the choices it did. For code review, that's huge. For onboarding new team members to AI workflows, it's even bigger.

Finally, the conflict-resolution protocol is genuinely well-designed. The "signal-threshold noise reduction" rule — if a 843-vs-8 split exists, the 8 goes to DONTs and nobody gets interrupted — is exactly the kind of judgment you want. Agents love to ask questions. This one knows when not to.

Key capabilities worth highlighting

1. Scale-aware scanning tiers. It measures project size with git ls-files | grep -cE ... and switches strategy: small projects get full close-reads, medium projects get layer-stratified sampling, large projects get --stat summaries first. I've watched agents blow up trying to "read" 5,000 files. This one doesn't.

2. The Grilling Protocol. For genuinely ambiguous conventions, you get exactly one question with four options: follow A, follow B, this is evolution (update rules), or "I have a new rule." No stacked questions. No 20-option megapropts. It's a designed conversation, not an interrogation.

3. Incremental mode with evolution logs. Re-running the skill after a team change or a big PR doesn't overwrite your existing rules. It appends an evolution log entry. That's the right default — legacy projects do evolve, and your style rules should too.

4. Three-tier enforcement strength. You pick: soft hook (just reference the rules in CLAUDE.md), hard hook (also install a PreToolUse hook in settings.json that mechanically blocks writes violating the rules), or no hook. The skill defaults to recommending soft. I like that it doesn't assume you want mechanical enforcement — most teams don't, and the cost of false positives in a hard hook is real.

5. The anti-patterns section is unusually honest. "FAIL: Do NOT copy bugs from exemplar files — reuse structure, flag defects." That one line tells you the author has actually run this skill against real codebases. It's a small thing, but it signals the difference between a skill designed in the abstract and one that's been used in anger.

Who should install this

Yes, install it if: - You're onboarding an agent to a codebase older than ~3 years with established conventions. - You maintain a long-lived monolith where internal consistency matters more than modernization. - You've been burned by agents "helpfully" rewriting your error handling or state management. - You're working in a regulated environment where audit trails of agent decisions are valuable.

Skip it if: - You're on a greenfield project. There's no legacy to inherit. Use a regular style skill instead. - You're doing pure research or one-off questions. The skill description explicitly says don't. - Your project is small (<50 files) and homogeneous enough that the agent's defaults already match your style. The skill will work but won't earn its keep. - You change tech stacks frequently. The rules will churn too fast to be useful.

How to install

Two options, pick one:

Personal (all your projects):

git clone https://github.com/affaan-m/ECC.git
cp -r ECC/skills/inherit-legacy-style ~/.claude/skills/

Project-local (just this repo):

mkdir -p .claude/skills
git clone https://github.com/affaan-m/ECC.git
cp -r ECC/skills/inherit-legacy-style .claude/skills/

Then either type /inherit-legacy-style in your agent session, or describe your use case in plain English and let the description matcher pick it up.

Concerns and limitations

Let me be honest about what bothers me.

The star count is suspicious. 246,148 stars on the parent repo is a lot. Either this is one of the most important repos in the AI tooling space, or the metric is being inflated somehow. I checked the badge URL — it points to a custom endpoint at api.ecc.tools, not the raw GitHub API. That doesn't mean the number is fake, but I'd take it with a grain of salt until I see it independently verified. The skill itself doesn't need 246k stars to be good, and I'm judging it on its own merits.

The "compliance declaration" per turn is aspirational. The skill says every code-writing turn should open with a compliance declaration, but it can't actually enforce that from the skill side — it relies on the rules being in context via CLAUDE.md and the model choosing to follow them. In practice, with strong base models this works. With weaker ones, it'll drift. The hard hook helps, but only for write-time violations, not for the reasoning preamble.

Signal-threshold defaults may not match your team. The 5% / count-10 cutoff for "weak signal auto-suppression" is a sensible default, but it's still a default. If your team is mid-migration and has lots of 40/60 splits, you're going to get grilled a lot. You may want to tune these thresholds via your own rules — and the skill doesn't expose them as configuration.

It generates files at the project root. .ai-style-rules.md is a project-level commitment. If you're working across many repos with different conventions, that's fine. If you're a contractor hopping between client codebases, you may end up with rules files everywhere. Worth knowing upfront.

The skill description says "language- and framework-agnostic" but the file-extension list in Step 1 is fairly Western-enterprise. .js|ts|jsx|tsx|vue|py|go|rs|java|kt|rb|php|cs|swift|c|cpp|h. No Erlang, no Elixir, no OCaml, no Haskell, no Clojure, no Lua, no R. If your legacy codebase is in any of those, the file-counting step will undercount and you'll get the wrong scanning tier. Probably worth a PR.

Verdict

Install it. Specifically: install it on the next legacy project you touch and run it once. The output — .ai-style-rules.md with real exemplars and a DONTs list — is useful even if you never enable the enforcement hook. It's documentation of conventions your team probably never wrote down explicitly. That's valuable on its own.

The skill is also a good case study in how to design agent infrastructure: detect mode automatically, scale your scanning strategy, suppress noise with explicit thresholds, ask one question at a time, and never assume the user wants maximum enforcement. There's a lot of subtle craft in this SKILL.md and it's worth reading even if you never install it.

Just keep your salt handy for the star count.

Links: - SkillsMP: https://skillsmp.com/creators/affaan-m/ecc/skills-inherit-legacy-style - GitHub: https://github.com/affaan-m/ECC/tree/main/skills/inherit-legacy-style