Leo Mahendra Dev

my top claude plugins as of now

Leo Mahendra Dev ·

In the first post I wrote about what a plugin is, how a marketplace works, and why switching on everything is a bad idea. At the end of that post I gave a promise, so here it is, the actual plugins. I went through the official marketplace and the lists which people are writing about, and I tried to sort them with one question only. Not which is the most popular, but for which job I will really open this one.

Because see, when we open the Discover tab, there are so many names there. Every name looks useful. Every description sounds like it will save our day. And then we install five, six of them in the same evening, and next week we are wondering why the usage is finishing so fast. So this post is to stop that. And I am also adding the four plugins which I use myself, so you can see them working in a real setup.

Quick reminder before we start. Most of these come from claude-plugins-official, and Claude Code registers it for us the first time we start it in a terminal. So the install command is always the same shape:

/plugin install <plugin-name>@claude-plugins-official

If some plugin is not showing, refresh the catalog with /plugin marketplace update claude-plugins-official. And remember the rule from the part 1, every active plugin adds weight to every message. So read each plugin below with this in mind, will I use this in at least half of my sessions, or only on some days.

Not sure which one, pick your situation

Before the long list, here is a small picker I made. Tap the thing which you are about to do, and it shows the plugin which fits, with the command also. If your situation is not there, then go down and read the groups.

What are you doing today?

Tap a situation above.

The everyday group

These are small, easy to understand, and useful in a normal week. If we install only few plugins, then start from here. I am also tagging each one as light, medium or heavier. That tag is my own feeling about how many parts it brings, it is not an official number.

commit-commands

lightgit

It gives us commands for the git routine, commit, push, and open a pull request. This is the plugin which quietly saves few minutes every single day. We stop typing the same commit flow again and again, and we stop writing a boring message by hand.

Use it when: we commit often. Watch for: read the commit message before it goes out. It is our history, not Claude history.

/plugin install commit-commands@claude-plugins-official

frontend-design

lightUI

This one is for a problem which we all see. The pages made by AI are looking all the same, same layout, same colors, same fonts. This plugin guides Claude to make more distinctive, production grade interfaces. It comes as a skill, so it is not a heavy plugin.

Use it when: we build web UI, a landing page, a React screen or even a blog widget. Watch for: it pushes its own style, so still tell Claude our colors and our brand, or else we get its taste and not ours.

/plugin install frontend-design@claude-plugins-official

Language server (LSP) plugins

lightcode intelligence

The official list has LSP plugins for several languages, like TypeScript, Python (Pyright) and Rust (rust-analyzer). They give Claude real code intelligence, so it understands the types and definitions and does not guess from plain text. For anyone who works in Python, Rust and React like me, these are the first ones I would look at.

Use it when: the project is big enough that Claude keeps getting a function signature wrong. Setup: open /plugin, go to Discover, and pick the one for your language. The install form follows the same name@marketplace pattern, for example swift-lsp@claude-plugins-official. Install only the languages which you really use, not all of them.

context7

mediumdocs

Libraries are changing fast, and Claude can remember an old version of the API. This plugin is used to pull the current library documentation into the session, so the answer matches the version which we actually installed. For Django, React or any framework which updates often, this can save a lot of wrong code.

Use it when: we work with a framework which changes quickly. Watch for: it connects to an outside service, so check what it reaches before enabling it on a private project.

/plugin install context7@claude-plugins-official

The review and planning group

These plugins bring several agents together. They are powerful, no doubt, but because they run more than one helper, I would use them at the right moment and not all day. This is my own advice, not a number from the docs.

code-review

heavierquality gate

It reviews our changes with several agents running in parallel, and each finding gets a confidence score, so the weak and noisy comments are filtered out. Think of it like a check right before the merge.

Use it when: a change is ready and we want a second pair of eyes. Not for: every small edit. Tip: keep it off until the day we need it.

/plugin install code-review@claude-plugins-official

pr-review-toolkit

heavierteams

A bigger review set for teams which run proper pull request reviews. It has specialised agents, like one for tests, one for silent failures and one for type design.

Use it when: we work in a team with real PR habits. If we are solo developer then code-review is usually enough, and this one is too much.

/plugin install pr-review-toolkit@claude-plugins-official

feature-dev

mediumplanning

A guided flow for building a new feature in phases, with an explorer, an architect and a reviewer agent. Good when we are staring at a big feature and do not know from where to begin.

Use it when: starting something new and large. Not for: a quick bug fix, there it is too much ceremony.

/plugin install feature-dev@claude-plugins-official

The connect to outside world group

These plugins mostly wire Claude to other tools. They are useful exactly when we work in that tool, and they are dead weight when we do not. So the question is only one, do I really live inside that tool.

github

mediumrepo context

Brings the repository and pull request context into Claude. Handy when our work lives in issues and PRs. Watch for: it signs in to our account, so check which repos it can see.

/plugin install github@claude-plugins-official

supabase, figma, sentry, firebase

mediumservices

Each one connects Claude to one service, a backend database, a design file, error monitoring, a hosting backend. If we do not use that service, skip it, simple. If we do use it, then it saves the copy paste between tabs.

/plugin install supabase@claude-plugins-official
/plugin install figma@claude-plugins-official
/plugin install sentry@claude-plugins-official
/plugin install firebase@claude-plugins-official

The plugins I use myself

Now the real part. These are the four plugins which I use in my own work, playwright, caveman, ponytail and UI UX Pro Max. Only playwright is in the official marketplace. The other three come from their own marketplaces, so the commands are little different, we need to add the marketplace first and then install. Everything below is taken from their own pages and readme, but these things update fast, so check the page once before you install.

playwright

mediumofficialbrowser testing

This is a browser automation and end to end testing server made by Microsoft. With this Claude can open a web page, click things, fill forms and take screenshots, so we get proof that the page really works and not just code which looks right. For me this is the one I switch on when I build a UI and want to see it run.

Use it when: we want Claude to test a page in a real browser. Watch for: the marketplace itself says Anthropic does not control or verify the third party servers inside it, so trust it before install. And keep it off on the days when we are not testing any page.

/plugin install playwright@claude-plugins-official

caveman

third partytalking style

This one changes how Claude talks. Its idea is to make Claude reply in very short caveman style, so the answers are shorter and we spend less. The page claims a big saving in tokens, but the same page also says that number is not verified, so measure it on your own work with the /caveman-stats command and do not take it as a promise.

It has modes, caveman, megacave, ultracave, and also off and manual. Type /caveman to turn it on in the current window, and say "stop caveman" to stop. The mode is per window. A default mode can be set in ~/.config/caveman/config.json or in a project file called .caveman.json.

Use it when: we just want quick short answers, like running small tasks. Not for: learning or writing a blog, because there we want full explanations. Watch for: restart Claude Code after install or update, and scripted runs start with it off unless we enable it.

/plugin marketplace add JuliusBrussee/caveman
/plugin install caveman@caveman

To update, use the full name, because the short name alone fails:

claude plugin update caveman@caveman

ponytail

third partyless code

Caveman changes how Claude talks, and ponytail changes how Claude writes code. Its idea is the best code is the code we never wrote. It tells the agent to write only what the task needs, and to first check for existing code and the built in features of the platform before writing something new. The page says it is lazy about the solution but never about reading, and it does not cut validation at trust boundaries, data loss handling, security and accessibility.

The commands are simple. /ponytail with lite, full or ultra sets the intensity, and /ponytail off turns it off. Then there are /ponytail-review to review the current diff, /ponytail-audit to do the same on the whole repo, /ponytail-debt to collect the shortcut comments, and /ponytail-gain to see the scoreboard. In Claude Code there is also a status band above the prompt, which we can hide with /ponytail band off.

Use it when: we are building features and Claude is writing too much code. Watch for: a lazy style is not good for every job, so for a big new design we can switch it off. The page does not explain how to uninstall it, so use /plugin uninstall ponytail@ponytail from the normal plugin commands.

/plugin marketplace add DietrichGebert/ponytail
/plugin install ponytail@ponytail

UI UX Pro Max

third partydesign

This is a design skill, open source, which gives Claude design knowledge for building UI. It can produce a design system for the project, with the page pattern, UI style, color palette, typography, effects, the anti patterns to avoid, and a checklist before delivery. It also has guidelines for 22 stacks, like React, Next.js, Vue, Svelte, Flutter, SwiftUI and Tailwind. It can save the result as files under a design-system/ folder.

In Claude Code it activates automatically when we ask for UI or UX work in normal chat, like build a landing page. The slash command version is for some other tools, not for Claude Code. It needs Python 3 on the machine for its scripts, and the page says the scripts use only the standard library and make no network calls. Also, the page says its results are guidance, they do not rewrite the app by themselves.

Use it when: we start a new UI and want a proper design direction. Watch for: it does a similar job like frontend-design, so do not run both together, choose one. That is my own advice.

/plugin marketplace add nextlevelbuilder/ui-ux-pro-max-skill
/plugin install ui-ux-pro-max@ui-ux-pro-max-skill

There is also a CLI way, npx ui-ux-pro-max-cli init --ai claude, run from the project folder.

One small thing I noticed. Caveman and ponytail are not doing the same job, one is for how Claude talks and the other is for how Claude codes, so they can work together. But playwright and UI UX Pro Max are for UI days only. So my own rhythm is simple, on a UI day I switch on UI UX Pro Max and playwright, and on a normal coding day I keep ponytail, and caveman only when I want short answers.

What about the very popular big packs

We will also see community packs with huge install numbers, for example Superpowers, which is skills focused and shows hundreds of thousands of installs on the lists I read. But popular does not mean light. A pack with many skills puts many descriptions inside our context. If we try one, then check /context before and after, and keep it only if it clearly earns its weight. To find community plugins, add anthropics/claude-plugins-community as a marketplace, like I showed in part 1.

Team or only me, a word on scope

One more thing which people forget. When we install, we choose where it applies. User scope means only me, in every project. Project scope means everyone who opens that repo, because it is written in the .claude/settings.json file. Local scope means only this repo and only me. If we are working in a team and one person enables five heavy plugins in project scope, then everybody pays for it. So for team use, keep project scope for the small useful plugins only, and let each person add the heavy ones by themselves when needed.

How I would run them in a normal week

Using my own four plus the small ones, this is the rhythm I would follow:

  1. commit-commands – every day, it is small and useful.
  2. ponytail – on the coding days when I want less code from Claude.
  3. caveman – only when I want short answers. I switch it off when I need explanations.
  4. ui-ux-pro-max and playwright – only on UI days, one for the design and one for testing the page.

And on demand, switched on for the day and switched off after, code-review before a merge, feature-dev when starting something big, github when the job really needs it. That is it. Few plugins on, the rest sleeping.

Turning a plugin on or off is quick: /plugin disable name@marketplace, then /reload-plugins. Run /context any time to see what the plugins are costing us.

A short checklist before you press install

  • Is it from the official marketplace? If not (like caveman, ponytail and UI UX Pro Max), who published it, and did I look at what it ships?
  • Does it bring hooks or an MCP server? Those can run things and reach outside services.
  • Will I use it in at least half of my sessions? If not, install it but keep it off by default.
  • After installing, did I run /context to see the cost?
  • Do I need it for the whole team (project scope) or only for me (user scope)?

Common mistakes I want you to avoid

First mistake is installing a plugin because a video said so. Second is installing five plugins which do almost the same job, like three different review plugins, and then using none of them. Third is forgetting that the plugin is still on after the work is finished. And fourth is never checking /context, so we never know what is eating the usage. If we avoid only these four, we are already ahead of most people.

That is the whole list. The plugin names will keep changing, new ones will come and some will go, but the questions in the checklist stay the same. If you remember only one thing from these two posts, let it be this. Plugins are tools for habits, and every tool which we leave switched on is paid in every message.

References: Claude Code docs (plugins overview), claude-plugins-official directory listings, composio.dev and claudify.tech plugin roundups, bito.ai review of official plugins, and pyshine.com directory notes, and the readme pages of caveman (JuliusBrussee), ponytail (DietrichGebert), UI UX Pro Max (nextlevelbuilder) and the playwright listing in claude-plugins-official. Plugin lists change often, so check the Discover tab in /plugin for what exists today.