From swe-assistant
Use when the user is evaluating, proposing, or being pulled toward adding a new technology to a stack — a new programming language, framework, database, library, build tool, deployment platform, or any meaningful new dependency. Triggers include phrases like "should we use [X framework / language / tool]", "I want to introduce [tech] to our stack", "let's switch from X to Y", "what's the best language for this project", "evaluating [tech] for [purpose]", "I think we should adopt [new thing]", "is [new tech] worth it", or asking about the trade-offs of any new-tech adoption decision. Walks through the boring-technology framework from The Missing Readme (Chapter 3, citing Dan McKinley's Choose Boring Technology) — the concept of innovation tokens, the ecosystem-maturity evaluation criteria (packaging, IDE, libraries, tests, engineer market, performance, integrations), and the cost-vs-benefit framework that determines whether the new technology earns its token. Do not trigger for in-stack technical questions (how to use a tool already chosen), for code reviews, or for the broader question of "should we change X" that isn't specifically about technology adoption (route to change-discipline).
How this skill is triggered — by the user, by Claude, or both
Slash command
/swe-assistant:choose-boring-technologyThe 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 framework comes from **Dan McKinley's *Choose Boring Technology***: http://boringtechnology.club/ (originally a talk and essay, 2015). See also the related [`change-discipline`](../change-discipline/SKILL.md) for the broader pitfalls.
The Missing Readme, Chapter 3, "Working with Existing Code" (Section: Avoiding Pitfalls). The framework comes from Dan McKinley's Choose Boring Technology: http://boringtechnology.club/ (originally a talk and essay, 2015). See also the related change-discipline for the broader pitfalls.
Engineers love new technology. New tech is shiny, new tech promises to solve the frustrations of the current stack, new tech makes you feel like you're on the leading edge. And occasionally, new tech is genuinely the right answer.
But the most expensive engineering mistakes are made by teams that adopt new technology too eagerly. This skill fires when the user is in (or proposing to enter) a new-tech-evaluation moment, and gives them the framework to decide honestly.
Boring isn't bad. Boring is well-understood.
The trap: judging new vs. boring on feature comparisons rather than on failure-mode and ecosystem maturity. Features are visible in marketing; failure modes are invisible until they happen to you.
The core concept from McKinley's essay. Worth installing as a vocabulary.
Every team has a small, finite budget of innovation tokens. An "innovation token" is what you spend when you introduce a non-boring choice into your stack — a new language, a new framework, a new database, a new build system, a novel architecture pattern.
The implication: spend tokens on the choices that genuinely differentiate your product or unlock something the boring options can't. Don't spend them on "this language is more elegant" or "I prefer this framework's syntax." Those don't earn tokens.
The honest test: "If I could only make one non-boring choice this year, would this be it?" If no, the boring option wins.
The headline cost of adoption is "learning the new thing." That's the small one. The hidden costs:
These costs don't show up in any single decision moment. They show up across years, and they're typically much larger than the benefit that motivated the adoption.
When evaluating any new piece of technology, especially a language or major framework, the question is not "is this technology good?" — it's "is the ecosystem around it mature enough for our needs?" Specifically:
A new technology can be brilliant on the language-level merits and still be a bad adoption choice if the ecosystem isn't ready.
When the user is considering a new-tech adoption, walk them through:
What specifically are they trying to do that the current stack can't?
changing-legacy-code).If they can't state the need precisely, the urge isn't ready to become a proposal.
Before evaluating the new thing, ask: what's the most boring possible solution to this need within the existing stack? Often it's a small extension, a known pattern, or a library that's already in use elsewhere in the codebase. If the boring solution gets you 80% of the benefit, the new tech probably isn't earning its token.
change-discipline)Is the new tech genuinely 10× better at the specific underlying need than the boring alternative? Not 2× or 3× — dramatically better, enough to overcome the compound costs of adoption.
If the honest answer is "no, more like 2× better but it feels nicer to work with" — that's a token-not-earned answer.
Run the eight evaluation criteria above (packaging, IDE, libraries, tests, support, hiring, performance, integration). Score each honestly. A new tech that scores low on any 2–3 of these is going to bite the team for years.
If it survives the test, treat the adoption as a real engineering project:
design-doc. Name the underlying need, the boring alternative, the proposed adoption, the trade-offs, the success criteria.Ask:
The answers tell you whether this is a tactical question (which tool of two should we use) or a real adoption decision (let's bring a new technology into our stack).
Often the most useful thing this skill does is help the user see they hadn't considered the boring option. Ask: "What does the existing stack offer that solves 80% of this?"
If it's a real adoption decision, walk through the 10× test and the ecosystem-maturity criteria. Don't lecture — ask the questions and let them answer.
The decision is one of:
Help them pick the right one and name the next concrete action.
If they're moving forward, route to design-doc for the proposal. If they're not, the decision itself is the deliverable.
change-discipline.incident-response.learning-toolkit instead.Surfaced as the primary reference but not yet folded in — see READING-LIST.md.
Provides 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.
npx claudepluginhub tmerrien/swe-assistant --plugin swe-assistant