60-Second Impulse

Impulse: Claude Code: Which Plugins Do We Need? Which Ones Belong in the Repo?

May 15, 2026 1 min read
Portrait of Martin Zoeller

Martin Zoeller

Claude Code: Which plugins do we need? Which ones belong in the repo?

Claude Code plugins cannot all be treated the same. Some can safely be checked into the repo; others are better left out — and the difference lies in what they do to the way people work.

If, like me, you deal with this topic every day, the following names will not be new to you: Figma for pixel-perfect design implementations, Serena for faster code navigation, context7 against API hallucinations, or Superpowers for… pretty much everything.

The interesting question is: which ones do we need? To answer that, I roughly divide plugins into two categories:

  1. Plugins where the team agrees that they make their work easier without any real downside. One example: if your UI/UX designers create beautiful Figma designs, every engineer saves time as soon as Claude Code can turn those designs into pixel-perfect code. No more manually looking up spacing or exact colors.
  2. Plugins that fundamentally influence how Claude Code works. One example: with Superpowers, new features can be planned in great detail. Before the first line of code is written, everything is poured into Markdown files in minute detail — regardless of whether the engineer already has a clear path in mind or not. That costs time, and it is not the right choice for everyone. The implementation is probably watertight in the end, but working with the tool changes fundamentally.

Finding consensus on plugins in the first category is fairly easy and probably happens automatically during the first weeks of working with Claude Code. Every now and then a new plugin comes out, your team tries it, and either it is a no-brainer, or it is not.

The plugins in the second category are not no-brainers, because they influence how an engineer works with the tool. Put very simply: I do not know two engineers who work the same way. That means you must not force your engineers to use them, and you also must not force consensus in the team.

Both plugin categories can still be checked into the repo, since without enterprise and MDM theater, you have no way to force or prevent the installation of certain plugins on laptops anyway. Checked-in settings are a convenience function, not policy, and engineers can politely decline.

Bonus tip: how do I get engineers to use plugins as well as possible? By creating a space where they can exchange ideas about these kinds of meta topics openly (!).