Plugin lists are usually aggregation dressed as experience — someone read the marketplace and ranked the descriptions. This one is inventory. My installed_plugins.json currently holds 24 plugins, and the honest number that earns daily use is about nine. The gap between those two numbers is the actual lesson of this post: plugins are cheap to install and expensive to benefit from, and the ones that stay are the ones that remove a recurring cost, not the ones with the best demo.
Here is what survives in my daily setup, what each one actually does in my workflow, and — just as useful — the installed-but-idle ones I would not miss.
First, what a plugin actually is
Worth thirty seconds, because the marketplace flattens three different things into one word. A Claude Code plugin can bundle skills (instruction sets the agent loads for specific task types), MCP servers (live connections to external systems), slash commands, and hooks. Install is trivial — /plugin in a session, pick a marketplace, pick a plugin. The cost is never the install. The cost is context: every active plugin adds surface the agent has to consider, which is why my list shrinks more often than it grows. My rule for this piece was simple: if I could not point to a moment in the last two weeks where the plugin did real work, it does not get called "daily" here.
The daily nine
1 and 2. PHP LSP and TypeScript LSP — the sleepers nobody writes posts about. Language-server plugins give the agent real code intelligence: go-to-definition, references, diagnostics. Without them, Claude navigates your codebase by grep and inference; with them, it navigates the way your IDE does. On a Laravel codebase the PHP LSP is the difference between "search for where this method might be used" and knowing. These two are the least glamorous and highest-yield entries on this list, and the reason they are underrated is precisely that they produce no visible output — just quietly better edits.
3. Context7 — current documentation on demand. Pulls version-specific library docs into context instead of letting the model work from training-data memories of an API that has since changed. It matters most exactly where you would predict: fast-moving packages and framework majors. When I am on unfamiliar library ground, this is the difference between confident-wrong and checked-right.
4. Superpowers — process enforcement. A bundle of workflow skills: brainstorming before building, test-driven development, systematic debugging, verification before claiming completion. Installing it changes the shape of sessions — the agent starts gating its own work instead of sprinting to plausible output. I dismissed it early as ceremony; I now think of it as the closest thing to encoding senior-engineer habits into the tool. I reviewed it at length in my Superpowers plugin deep dive.
5. Code Review — the pre-merge gate. Runs a structured review over a diff, a branch, or a PR, with findings ranked by severity and verified before they are reported. I run it before merging anything nontrivial on this site, and its hit rate on real correctness bugs — not style nits — has kept it in the rotation. Paired with the next entry, it forms the quality half of my workflow.
6. Code Simplifier — the cleanup pass. Same muscle, different target: reuse, dead abstraction, needless complexity in code that already works. I run it after features land, not during, so it never argues with in-progress design.
7. Commit Commands — mechanical git, delegated. Conventional commits, push, PR creation, plus a tidy command for cleaning branches whose remotes are gone. Small, boring, used constantly. This is the category of plugin I most recommend to skeptics because the value shows up on day one and never regresses.
8. Codex — the adversarial second opinion. Yes, the OpenAI plugin, inside Claude Code. It delegates review to a different model family in a separate process, and the disagreements are the product: where Claude and Codex both flag a spot, it is nearly always real; where they disagree, I have learned something about the ambiguity in my own code. I wrote up the pattern in running Codex as an adversarial reviewer inside Claude Code.
9. Frontend Design — the anti-generic pass. Design-focused skills that push generated UI away from the same-looking Tailwind defaults every model produces cold. On a blog whose theme I actually care about, this plus a token layer is what keeps agent-built components on-brand instead of merely correct.
The project-level layer most plugin lists skip
The highest-value "plugin" in my daily work is not from a marketplace at all. This repository's .mcp.json wires in Laravel Boost — an MCP server exposing the application's routes, database schema, config, logs, and a tinker execution surface to the agent. Project-scoped MCP configuration means every session in this repo starts already knowing the application, and it travels with the repo, so any machine — and any teammate — gets it for free.
That is the pattern I would push you toward more than any specific marketplace pick: user-level plugins for your general workflow, project-level MCP for each codebase's ground truth. The combination is what makes Claude Code feel resident in a project rather than visiting.
The honest bench: installed, not daily
Transparency, since this post's whole premise is inventory. Also living in my plugin file: Playwright and Chrome DevTools MCP (real use, but session-specific — browser verification days, not every day), Feature Dev (good on greenfield, idle on maintenance weeks), Skill Creator (bursty — heavily used when I am building skills, silent otherwise), claude-mem, security guidance, Postman, Supabase, a Go LSP for a language I touch quarterly, and a couple of experiments (Ralph Wiggum's loop pattern, canvas) that were worth trying and have not paid rent since.
None of these are bad. They are situational, and the distinction between situational and daily is exactly what marketplace install counts cannot tell you. Install counts measure curiosity, not retention.
How to build your own daily list
Skip the "top plugins" search — including, frankly, mine — as anything more than a menu. The selection method that works:
- Log your friction for one week. Every time you leave the terminal, repeat yourself to the agent, or fix the same class of agent mistake, write it down.
- Map each friction to one plugin. LSPs for bad navigation, Context7 for stale API knowledge, commit tooling for git ceremony, review plugins for quality anxiety.
- Install one at a time. Two weeks each. A plugin that has not visibly earned its context cost in two weeks gets removed — removal discipline matters more than selection discipline, because plugin cost is paid in every session whether used or not.
The plugins-vs-skills boundary confuses people starting out; skills are the deeper end of the same pool, and my guide to the Claude Code skills worth installing covers that layer with the same inventory-first approach. For the wider tooling picture — skills, plugins, and the CLI tools that sit beside them — the top 10 stack rundown is the hub piece.
A good plugin stack ends up personal the way a good editor config is personal: nine tools nobody else would pick in that exact combination, each one there because of a specific scar. Mine took months of install-and-remove cycles to settle. Yours will look different, and that is the point.
The other half of my own stack is the skills layer, and that one I keep public: the skills I have built and maintained for real workflows live at my agent skills marketplace. The same selection rule applies there — read it, run it for two weeks, delete it without ceremony when it stops earning its context.
