From swe-assistant
Use when the user is considering a meaningful change to the existing way things work — proposing a rewrite of a module or system, wanting to bypass or break a team coding standard or convention, talking about forking a library or framework instead of contributing upstream, or proposing to swap one technology for another in the stack. Triggers include phrases like "I want to rewrite this", "let me migrate us from X to Y", "we should replace [tool] with [other tool]", "I'm going to fork the library to fix this", "I don't agree with our coding standards", "let me just bypass the linter rule", "this whole module needs a rewrite", "let's switch from X to Y framework", or asking whether some kind of large change to existing code, conventions, or stack is a good idea. Walks through the four pitfalls from The Missing Readme (Chapter 3) — rewrites, going rogue on standards, forking without upstreaming, adding new technologies — using Horowitz's "10x better" rule as the decision criterion. For new-technology evaluation specifically, route to choose-boring-technology. Do not trigger for small in-flight refactors, code reviews, or active incidents.
How this skill is triggered — by the user, by Claude, or both
Slash command
/swe-assistant:change-disciplineThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
*The Missing Readme*, Chapter 3, "Working with Existing Code" (Section: Avoiding Pitfalls). The 10x rule is from Ben Horowitz, *The Hard Thing About Hard Things* (Harper Business, 2014). The boring-technology framing is from Dan McKinley's *Choose Boring Technology* (http://boringtechnology.club/) — see also the dedicated [`choose-boring-technology`](../choose-boring-technology/SKILL.md) skill.
The Missing Readme, Chapter 3, "Working with Existing Code" (Section: Avoiding Pitfalls). The 10x rule is from Ben Horowitz, The Hard Thing About Hard Things (Harper Business, 2014). The boring-technology framing is from Dan McKinley's Choose Boring Technology (http://boringtechnology.club/) — see also the dedicated choose-boring-technology skill.
Engineers — especially early- and mid-career — frequently feel the urge to change things in the codebases and stacks they inherit. "This should be rewritten." "This standard is dumb, I'll just bypass it." "Let me fork this and fix the bug." "We should switch to [new framework]."
These urges are often partly right — the existing thing does have problems. But changes have compound costs that the urge tends to obscure. This skill fires when the user is contemplating that kind of change, and helps them apply real cost/benefit discipline before they commit time and political capital to it.
Default to staying put. The cost of changing what already works is usually invisible until you start the change.
Existing code, standards, and stacks come with accumulated context — bug fixes embedded in the implementation, documentation people have read, mental models teammates have built. Changing them resets that accumulation. The new thing has to be meaningfully better, not just "what I would have built."
The Horowitz test, applied to engineering decisions:
"The primary thing that any technology startup must do is build a product that's at least ten times better at doing something than the current prevailing way of doing that thing. Two or three times better will not be good enough to get people to switch to the new thing fast enough or in large enough volume to matter." — Ben Horowitz, The Hard Thing About Hard Things (2014)
The rule transfers cleanly: switching from one piece of working software, one convention, or one technology to another is also asking everyone to "switch." Costs the asker forgets to count: retraining teammates, breaking other code that depended on the old thing, losing the embedded context, replacing all the surrounding tooling and integrations, migration time across many systems, debugging time in the new thing while you re-learn its failure modes. If the new thing is only 2× or 3× better, the switch loses on net almost every time. 10× is the threshold that makes the math actually work.
This isn't a literal exactly-ten requirement — it's a guard against romantic estimates of benefit. If you struggle to argue the change is dramatically better, it probably isn't.
The most common form: "This module is a mess, I'm going to rewrite it from scratch."
What the urge misses:
software-entropy for the reframe — most code mess is the natural cost of evolution, not negligence.)Better moves, in roughly increasing order of intervention:
changing-legacy-code.changing-legacy-code.technical-debt for the framework.The urge: "This linter rule is stupid, I'll just disable it for my PR." Or "Our naming convention is bad, I'll use the one I prefer."
Why this fails even when you're right:
The right move: change the standard through proper channels. Concretely:
technical-debt, or design-doc for larger changes.)Side benefit of going through channels: you build cross-team relationships and become known as someone who proposes change constructively rather than someone who just diverges. That's how engineers become early adopters of real change later.
The urge: "This library has a bug. I'll fork it, fix the bug, and use my fork."
What happens next:
Better moves:
The rule: don't fork without committing the fix upstream first, or accepting upfront that you're now maintaining a separate piece of software.
The urge: "This new framework / language / database / tool is so much better, we should adopt it."
This pitfall is significant enough that it has its own dedicated skill: see choose-boring-technology for the full treatment of innovation tokens, ecosystem-maturity evaluation, and the decision framework. The short version:
Route to choose-boring-technology for the full framework.
Ask the user:
The answer routes which of the four pitfalls to surface.
Walk them through the Horowitz framing. Ask:
If they can't argue 10×, the change is probably not worth it. That's a useful conclusion on its own.
For most cases there's a smaller intervention that captures most of the benefit at much lower cost:
changing-legacy-code)choose-boring-technology)Help them find the smaller move.
When the change does pass the 10× test — and sometimes it does — help them plan it as a real proposal:
design-doc for technical changes; technical-debt for paydown proposals).Confirm the decision (do the smaller thing, or propose the bigger thing through channels) and the next concrete action. If they're going to propose a real change, offer to walk through the proposal with them.
changing-legacy-code.choose-boring-technology.technical-debt. (Tech debt paydown is sometimes the right alternative to a rewrite — this skill helps them see the difference.)incident-response. Discipline-about-change conversations are for calm afternoons.Surfaced as primary references but not yet folded in — see READING-LIST.md.
choose-boring-technology.npx claudepluginhub tmerrien/swe-assistant --plugin swe-assistantProvides UI/UX resources: 50+ styles, color palettes, font pairings, guidelines, charts for web/mobile across React, Next.js, Vue, Svelte, Tailwind, React Native, Flutter. Aids planning, building, reviewing interfaces.
Fetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.