The Claude Code Plugin Stack I Actually Run

TL;DR: Plugins bundle skills, hooks, and MCP configs into one install, and it’s tempting to grab whatever looks useful. I don’t. A plugin earns a slot in my stack only if it encodes a discipline I’d otherwise have to reconstruct from memory every session, or a piece of domain expertise I don’t personally hold. Almost all of that value lives in one category — process and workflow — and it’s the category most people skip in favor of flashier domain-specific tooling. The domain stuff is real too, but only on the projects that actually need it; I don’t run Elixir-specific plugins against a Python repo just because they’re installed globally. Below is the actual stack, organized by why each one is there.

The question that decides if a plugin earns a slot

I run a lot of different codebases in a given month — my own projects, client engagements where I’m the fractional CTO or vCISO walking into someone else’s repo, greenfield prototypes. Every one of those sessions starts the same way: an agent with no memory of yesterday, reading whatever context I hand it. Plugins are how I hand it more than a prompt.

But “more context” isn’t automatically good. A plugin that just wraps a prompt template I could type myself isn’t worth a permanent install — it’s clutter that shows up in every session whether the project needs it or not. The bar I actually use: does this encode a repeatable discipline or real domain expertise I’d otherwise have to reconstruct from scratch, every single time? If yes, it’s earned a slot. If it’s just “a thing that exists in the marketplace,” it’s not.

That filter sorts my stack into three very unequal piles. The first is small in plugin count and enormous in leverage. The other two are real, but scoped tight.

Process plugins: where almost all the value lives

These don’t teach the agent anything about a tech stack. They change how the agent and I work together, which means they pay off on every project, every day, regardless of language or domain. If I could only keep one category, it’s this one.

Superpowers’ brainstorming-first workflow. The single highest-leverage habit I’ve adopted is refusing to let an agent write code before it’s asked me clarifying questions. Left alone, a coding agent will take an ambiguous ask and confidently build something — fast, plausible, and frequently not what I meant. A brainstorm-first discipline forces a short back-and-forth before the first line of code: what’s actually broken, who hits this, what does “done” look like. It costs two minutes. Skipping it costs an afternoon of reviewing code against the wrong spec. I’ve written before about prompting skills instead of prompting the model one sentence at a time — this is the clearest example of a skill that’s worth more than any prompt, because the discipline only works if it fires every time, unprompted, and a plugin is how you make “every time” actually happen instead of “when I remember to ask for it.”

Superpowers’ systematic-debugging discipline. The default failure mode for an agent staring at a bug is the same as the default failure mode for a junior engineer: jump straight to the first plausible fix, apply it, declare victory. That’s a symptom patch, not a root cause fix, and it’s how the same bug comes back three commits later wearing a different hat. A debugging plugin worth keeping forces the boring sequence — reproduce, isolate, form a hypothesis, test the hypothesis, then fix — before any edit gets made. I’ve catalogued the specific bug patterns this catches in the AI coding agent bugs I catch every week; most of them are exactly this shortcut, taken with confidence.

The code-review skill, run at adjustable effort. Not every diff deserves the same scrutiny. A one-line config change and a new auth boundary should not get the same review budget, and an agent that reviews everything at maximum depth is as useless as one that reviews everything at a skim — the first wastes your afternoon, the second misses the thing that matters. The review plugins I keep let me dial the pass: quick sanity check on a small diff, full adversarial read on anything touching money, auth, or a data boundary. That’s the same judgment I apply running an actual PR review, encoded so it doesn’t depend on me remembering to ask for it that day.

Ponytail’s lazy-engineer discipline. This is the one that saves the most wall-clock time and gets skipped the most, because it doesn’t feel like it’s “doing” anything — it’s a plugin whose entire job is to argue against writing code. Reuse what’s already in the codebase before adding a new file. Reach for the standard library before a dependency. Treat YAGNI as a reflex, not a suggestion, and push back out loud when a task is drifting toward an interface with one implementation or a config knob for a value that never changes. Left alone, agents over-build — they’ll happily scaffold an abstraction layer for a feature that will only ever have one caller. The instinct to ship the smallest working slice and question the rest in the same breath is the same one I’ve written about for shipping complex features as vertical slices; a lazy-engineer plugin is that instinct running inside the agent instead of just inside my own head.

Caveman’s terse-communication style. Smaller win, but a real one: a plugin that strips the filler out of an agent’s responses — no recap of code it just showed you, no essay defending a simplification that’s already obvious, no “great question!” padding. It doesn’t change what gets built, but it changes how fast I can read the output and decide what to do next, and over a full day of agent sessions that adds up to real time back.

The claude-md-management plugin. A project’s CLAUDE.md is executable tribal knowledge — the operational realities, the gotchas, the “don’t do X, here’s why” that a new session needs and a stale file quietly stops providing. Left unmaintained, it rots the same way any onboarding doc rots: it drifts from what’s actually true, and a new session inherits confidently wrong context. A plugin that periodically checks the file against the current codebase and flags what’s stale is cheap insurance against that drift. I’ve made the underlying case for treating the file this way in your CLAUDE.md is the onboarding doc you never wrote.

Domain plugins: deep, but scoped to the project that needs them

The second pile is domain-specific — plugins that encode years of framework or vertical idiom I don’t want to reconstruct from a blog post every time I touch that stack. These are real, and they’re deep, but the discipline here is different: install them per project, not globally. Dragging Elixir-specific tooling into a Python repo doesn’t help — at best it’s inert weight, at worst it’s an agent trying to apply the wrong idiom to the wrong runtime.

The elixir-phoenix plugin. On the client engagements and personal projects running on the BEAM, this is the deepest single install I keep. Ash resource patterns, LiveView idioms (streams versus assigns, async mounts, the PubSub-subscribe-after-connected?/1 rule that trips up every agent that hasn’t seen it), Oban worker conventions, and an N+1 detector that actually understands the difference between a has_many that needs a separate query and a belongs_to that needs a join. I’ve written about a chunk of this idiom directly — twelve LiveView patterns that hold up in production and running an agent loop on Oban as a durable runtime are both things a generic coding agent will get subtly wrong without this kind of scaffolding, because the failure modes are BEAM-specific and nowhere near as intuitive as they look from a Rails or Node background.

The claude-seo plugin. Technical SEO, schema markup correctness, content-quality checks, and — new enough that most people haven’t built a habit around it yet — readability for AI-search and generative engine results, not just the classic ten blue links. I keep this scoped to content and marketing-site work specifically; it has nothing useful to say about a backend service repo, and installing it everywhere just adds noise to sessions where it doesn’t apply.

The marketing-skills plugin. Copywriting, positioning, launch-plan structure. I reach for this maybe one week in eight, when the task in front of me is genuinely go-to-market rather than code — and that’s exactly why it stays out of the default stack. It’s real expertise I don’t want to reconstruct from scratch when I need it, but it has no business being active during an engineering session where it’ll happily suggest a rewrite of a docstring in marketing voice.

The pattern across all three: depth is the point, and scope is the discipline. A domain plugin that’s genuinely good encodes something you’d otherwise have to relearn or reverse-engineer — that’s worth the install. It’s also worth uninstalling, or at minimum not enabling, the moment you’re not on that kind of project. The failure mode isn’t picking a bad domain plugin; it’s letting a good one bleed context into work it wasn’t built for.

Utility plugins: small, single-purpose, no ceremony

The third pile is the smallest per-item but still earns its keep — narrow tools that solve one recurring annoyance and then get out of the way.

A design-taste plugin like design-taste-frontend. Left to its own aesthetic judgment, a coding agent defaults to the same handful of generic patterns — the same gradient, the same card-with-shadow, the same spacing scale every AI-assisted landing page seems to land on. A design-taste plugin that actively blocks those defaults and pushes toward something with an actual point of view is worth keeping specifically because the failure mode it prevents is invisible until a real person looks at the page and it feels like every other AI-built site.

The dataviz skill. Similar idea, narrower scope: default chart output from an agent is functional and forgettable. A skill that encodes actual data-viz taste — when a bar chart beats a line chart, when to just use a table instead of forcing a visualization the data doesn’t support — saves a full review-and-redo cycle on anything involving a dashboard or report.

The commit-commands plugin. Not glamorous, but they save real minutes: consistent commit message formatting, a PR description scaffold that pulls the actual diff summary instead of a placeholder, review-comment triage. This is the kind of thing that’s genuinely one line of value per use, which is exactly why it should be a saved command rather than something I re-explain every time.

The update-config skill. Slightly meta — a plugin for configuring the harness itself. Useful specifically because hook and permission configuration is exactly the kind of thing you set up once, forget the syntax for, and need again three months later on a different project.

The keybindings-help skill. Small, personal, and entirely about shaving friction off the parts of the workflow that happen hundreds of times a day. Not a discipline, not domain expertise — just ergonomics, and I don’t pretend it’s more than that.

The obsidian plugin. An Obsidian-style link into a personal knowledge base, so an agent can pull in and write back durable notes instead of every insight evaporating at the end of the session. This is the same problem CLAUDE.md solves at the project level, one layer up — a persistent memory an agent actually reads instead of a wiki that only humans open. I went deep on the architecture for doing this well in building an LLM wiki your coding agent actually reads.

What doesn’t make the cut

If you want the full field before you start cutting, I catalogued 46 tools worth knowing elsewhere — that post is the breadth survey; this one is the subset that actually survived the filter above and stayed installed. Notice what’s not up there: nothing installed because it trended, nothing that duplicates a discipline a different plugin already covers, nothing domain-specific running outside the project it was built for. The failure mode I see most often — in my own stack early on, and in engineers I’ve worked with since — isn’t under-installing. It’s the opposite: a plugin folder that’s grown by accretion, full of things that seemed useful in the moment and now just add noise and context bloat to every session, including the ones where they don’t apply. Even an unused plugin isn’t free — it’s tokens spent on context nobody asked for, one more surface that can quietly drift out of date, one more thing to explain when a new teammate asks why it’s there.

The process category is where I’d tell anyone starting from zero to spend their first real effort — a brainstorm-first habit and a real debugging discipline change the shape of every session you’ll ever run, on any stack. The domain plugins are worth going deep on, but only exactly as deep as the projects you’re actually running, and only on those projects. Everything else is quality-of-life, worth having, not worth confusing for either of the two things above it.

If you’re standing up this kind of workflow across a team rather than just for yourself — deciding which disciplines get codified, which stay person-specific, and where the line is between a real productivity investment and tool sprawl — that’s a conversation I have often in fractional engineering leadership engagements.