10 Claude Code Plugins to 10X Your AI Development Projects

I get better output from Claude Code by adding fewer tools, not more. Piling on MCP servers rarely helps, but the right CLI tools and skills do. With picks like Supabase CLI, Playwright, GitHub CLI, and the GSD framework, I built a stack that handles code, deploys, research, and browser work on its own.

When I first found Claude Code, I tried to connect every MCP server I could find. Within a week, the agent felt slower and less decisive, and it often picked the wrong tool for the job. The fix was almost always a smaller, more careful toolset.

CLI vs. MCP: Why the Terminal Wins

Claude Code is a terminal-native agent. It runs in my shell, reads my file system, and runs commands directly. That design shapes how I choose to extend it.

MCP (Model Context Protocol) servers are external processes. Claude talks to them over a local socket or HTTP. They add overhead: a server to manage, a protocol layer to cross, and one more thing that can fail without warning. For read-heavy jobs like browsing the web or calling an outside API, MCP servers work fine. But for dev work that needs speed and a tight local fit, CLI tools win almost every time.

When a CLI tool sits in my path or a project’s node_modules, Claude runs it the way I would: by typing a command. There is no extra process, no socket to watch, no layer between the agent and the result. The tool does its job, and Claude gets a clean stdout/stderr reply to reason about.

The best CLI tools also ship with their own Claude Code skills. These are structured Markdown files that teach the agent how and when to use the tool, what the output looks like, and which failures to watch for. I always check for a companion skill before I write my own instructions.

One caveat I take seriously: more tools do confuse the agent. Every extra capability adds another path Claude has to weigh when it plans a task. So I keep my active toolset small. I install globally only what I use in every project, and the rest goes in per project. For a wider view of community tools, the five open source repos that extend Claude Code most effectively are worth a bookmark before I start installing.

The 10 Essential Plugins and Tools

Supabase CLI - The Foundation

Supabase CLI replaces the Supabase MCP server, and for agent work it is the better pick. I install it once with npm install -g supabase and sign in. After that, Claude can build and manage full PostgreSQL databases, set up row-level security, run migrations, and even start vector stores for RAG pipelines, all from plain language.

My favorite use is pairing it with pgvector. I tell Claude to create a Supabase project, add a documents table with vector embeddings, and write the ingestion script. It does all three steps in order, checking the CLI output after each one to confirm success before it moves on.

Note: Supabase has a free tier. Production deploys and some features need a paid account.

Skill Creator - The Architect

The Skill Creator is Anthropic’s meta-tool for the Claude Code ecosystem. It helps me build, change, and measure other skills, so think of it as a build-and-test loop for agent behavior.

The feature that sets it apart is A/B testing. I can create two versions of a skill, say two ways to write a blog post or run a deploy check. Skill Creator runs both against a test set and compares the output. That is how I avoid tuning a skill on vibes instead of evidence.

I call it with /skillcreator in any Claude Code session, or I just describe what I want in plain language. It reads my existing skill files, learns the pattern, and writes or edits skill Markdown to match.

GSD Framework - The Orchestrator

GSD (Get Shit Done) is an orchestration framework that sits on top of Claude Code. It changes how I manage complex projects. The core idea is spec-driven development: before I write a line of code, I produce a detailed spec, break it into phases, and run each phase in its own fresh context window.

This fixes one of the most common failures in long Claude Code sessions: context rot. With context rot, the agent slowly loses track of earlier decisions. It starts to contradict itself, and it may not notice that a file it wrote in step 3 no longer matches the code it writes in step 12. By giving each phase its own sub-agents with fresh contexts , GSD keeps every unit of work small, focused, and reliable.

The workflow starts in a high-level plan mode. There, Claude and I define the architecture together. Then it shifts into a strict phase-by-phase build. At each step, Claude knows what it is building, what it has already built, and what success looks like.

NotebookLM-PI - The Researcher

NotebookLM-PI is a Python CLI. It pipes Google’s NotebookLM straight into my Claude Code terminal session. If I have used NotebookLM’s Deep Research or audio overview features, I already know its reasoning engine is unusually good at pulling sense from large document sets. This tool brings that engine to the command line.

The value play is to offload research-heavy tasks to NotebookLM’s free tier. Claude Code stays in the driver’s seat for the build. I ask Claude to query NotebookLM about a set of PDFs I have uploaded. It gets back a structured summary as text, then uses that summary to drive the real code or content. Two reasoning systems work in sequence instead of one doing everything.

Setup is a CLI-based OAuth login, then plain language queries. The tool returns clean text that Claude can reason about and act on right away.

Obsidian Vault Integration - The Personal Assistant

Obsidian is a Markdown-based note tool built around a Vault. A Vault is just a folder of linked notes. When I run Claude Code inside a Vault folder, the agent turns into a real personal assistant. It can read, write, search, and cross-link my notes with the same conventions I use by hand.

The setup is tiny: open a terminal in my Vault folder and start a Claude Code session. No MCP server needed. Claude can read every note, follow [[wikilinks]] to related notes, create new notes with the right metadata, and update indexes on its own.

The key habit is to tell Claude, in the agent rules I keep checked into the repo , to follow Obsidian conventions. I ask it to use [[note-name]] syntax for internal links. I tell it to add tags in frontmatter from my existing tag list. I have it place new notes in the right subfolder by topic. Without these notes, Claude writes correct Markdown that does not fit the rest of my vault.

Vercel CLI - The Deployer

Vercel CLI brings one-command deploys into the plain language workflow. I install it with npm install -g vercel and sign in once. After that, Claude can deploy any frontend project to a preview URL or production, all without leaving the terminal.

The more useful pattern is the agent loop. After Claude makes a code change, it runs vercel --prod and waits for the deploy to finish. It checks the deploy status endpoint, then runs a smoke test against the live URL. If the smoke test fails, it rolls back on its own. A multi-step manual chore becomes a full deploy-verify-rollback cycle.

Note: Vercel needs an account. Production deploys past the free tier limits need a paid plan.

Playwright CLI - The Automation Agent

Playwright is Microsoft’s browser automation library, and its CLI makes it callable straight from Claude Code. The agent can launch a headless browser, open any URL, work with UI elements, fill forms, click buttons, and pull data. Plain language instructions drive all of it.

What I value most in Playwright is the show command. It opens a visible browser window next to the headless run. I can watch what the agent does in real time, and that makes debugging much faster. When Claude runs a long form submission or scrapes a paged table, seeing the browser state beats reading a stack trace.

I use it for UI tests after each deploy, for pulling structured data from sites with no API, and for filling forms inside a larger automated workflow.

Install: npm install -g @playwright/test && playwright install

GitHub CLI - The Workflow King

GitHub CLI changes how Claude Code works with Git and GitHub more than almost any other tool. Without it, every PR, issue, push, and review needs manual steps or a fragile MCP server link. With gh installed, Claude handles the full Git workflow from plain language.

I ask it to create a pull request for this branch with a summary of the changes. It writes the PR description, applies labels, and opens it. It pulls context straight from the diff and commit history. It pairs well with Vercel CLI. Claude pushes code, opens a PR, deploys a preview, adds the preview URL as a PR comment, and waits for CI to pass. The whole loop, from write this feature to PR ready for review, can run on its own.

No paid account required beyond a standard GitHub account.

Firecrawl - The Web Scraper

Firecrawl is a web scraping API and CLI built for AI agents. Standard scrapers return raw HTML, while Firecrawl returns clean, structured Markdown that an LLM can reason about right away. The gap in output quality is large.

Its four core commands cover most research work. scrape handles a single URL. crawl takes a whole site. map builds a sitemap. search runs full-text search across crawled content. When Claude needs current, factual web data, like rival research, docs lookup, or news, Firecrawl is the right tool.

Note: Firecrawl needs an API key, and heavy use needs a paid tier.

Excalidraw Diagram Skill - The Visualizer

The Excalidraw Diagram Skill , built by Cole Med, teaches Claude Code to make technical diagrams and architecture charts as Excalidraw files from plain language. Manual diagramming is slow and dull, but this skill turns it into a one-sentence task.

Because the skill can see my project’s codebase, it draws diagrams that match my real architecture, not generic boxes. I ask for a data flow diagram for the authentication service. It reads the right files, learns the real parts and links, and gives me an Excalidraw file I can open and edit at once. For docs, talks, and architecture reviews, this saves me hours.

Finding the Sweet Spot

More tools do not give better results. Every tool I add is one more option the agent must weigh. It is one more source of confusion when two tools could handle the same task. It is one more thing that can fail mid-session and derail a long workflow.

My rule is simple: install globally only what I use in every project. For me, that means GitHub CLI and maybe Playwright. The rest, like Supabase CLI, Vercel, and Firecrawl, goes in per project. I document each one in the project’s CLAUDE.md so the agent knows what is there and when to use it.

A starter stack for three common use cases:

And a reference table for all ten tools covered here:

Tools that require paid accounts or API keys: Firecrawl (free tier limited), Vercel (free tier available, paid for production scale), and Supabase (free tier available, paid for production projects and advanced features).

No single tool here will fix a bad workflow. Keeping my stack deliberate counts for more than any one pick. A Claude Code session with three well-chosen, well-documented tools beats one with fifteen poorly-fitted ones. I pick the stack that matches my real workflow, document it in the project’s CLAUDE.md, and give the agent a clean, focused scope.