--- title: "Best Claude Code Plugins, Skills & MCP Servers (2026) | TurboDocx" description: "The 7 Claude Code plugins, skills, and MCP servers I use daily — plus how they compare to gstack. What each does and how they fit together." url: "https://www.turbodocx.com/blog/best-claude-code-skills-plugins-mcp-servers" --- # The Best Claude Code Plugins, Skills & MCP Servers I Use Every Day > Seven tools that turn Claude Code from a smart assistant into a full engineering team. What each one does, when to reach for it, and how they fit together. By Nicolas Fry (Founder & CEO, TurboDocx). Published March 11, 2026. 10 min read. Category: Developer Productivity. I wrote about how I use Claude Code to ship features in one session, covering the Director/Manager/Team mental model and the four-step workflow that changed how I build software. But that post covers the _methodology_. This one covers the _toolkit_. A Director of Engineering is only as good as the team they hire. These seven plugins, skills, and MCP servers are that team. Each one handles a specific job, from feature architecture to live documentation lookup, and together they turn a single Claude Code session into something that feels like an entire engineering org. A [well-structured CLAUDE.md](https://www.turbodocx.com/blog/how-to-write-claude-md-best-practices.md) is the foundation that makes all of them effective. | Tool | Type | What It Does | Best For | | --- | --- | --- | --- | | feature-dev | Plugin | Guided 7-phase feature development with multi-agent exploration | New features | | frontend-design | Plugin | Production-grade UI that avoids generic AI aesthetics | User-facing work | | /batch | Built-in | Parallel execution across isolated worktrees with auto PR creation | Multi-file changes | | /simplify | Built-in | Three parallel review agents for reuse, quality, and efficiency | Post-implementation | | /code-review | Plugin | Four independent reviewers with confidence scoring | Pre-merge gate | | Context7 | MCP Server | Live, version-specific library documentation from Upstash | Third-party libraries | | Context Hub | MCP Server | Curated API specs with agent annotations from Andrew Ng's team | API integrations | ## Official Skills (Build Phase) ### feature-dev (Plugin) This is the skill that turns a feature brief into working code. With over 89,000 installs, it's the most popular Claude Code plugin for a reason: it imposes the same structured process that senior engineers use instinctively. When you invoke `/feature-dev`, Claude doesn't just start writing code. It runs a seven-phase workflow: requirements gathering, codebase exploration (using parallel agents to study your architecture, existing patterns, and conventions), architecture design, implementation, testing, review, and documentation. It's the difference between asking someone to "build a thing" and handing them a rigorous engineering process. **When to use it:** Any feature larger than a quick fix. If you're adding a new page, building an integration, or creating a component system, feature-dev is the right starting point. For trivial changes (typo fixes, config tweaks, single-line edits) it's smart enough to skip the full workflow. ### frontend-design (Plugin) Every developer who's used AI for frontend work has seen the result: perfectly functional code that looks like every other AI-generated page. Same layouts, same gradients, same generic feel. frontend-design exists to fix that. The skill guides Claude through four design dimensions (purpose, tone, constraints, and differentiation) before writing a single line of CSS. It pushes for unexpected font pairings, asymmetric layouts, orchestrated scroll-triggered animations, and layered visual depth. The output feels intentional and branded, not templated. Think of it as a design team in your pocket. It doesn't just build what you describe, it gives you mockups and alternative suggestions, speeding up the entire UX cycle. Instead of going back and forth with a designer for days, you iterate on layouts, spacing, and interaction patterns in minutes. I pair this with feature-dev for full-stack features: feature-dev handles the architecture and backend logic, frontend-design handles the interface layer. They complement each other naturally: one cares about how it works, the other cares about how it feels. ### Worth knowing about: Garry Tan's gstack Y Combinator CEO Garry Tan open-sourced [gstack](https://github.com/garrytan/gstack), six Claude Code skills that bundle planning, review, and shipping into one installable package. Where our toolkit separates building (feature-dev, frontend-design) from review (/simplify, /code-review), gstack takes a different angle: CEO-level product thinking, automated PR shipping, and browser-based QA. They're complementary, not competitive. I wrote a full comparison of gstack vs. our approach, and you can see how the Director/Manager/Team model maps to both. ## Built-In Commands (Orchestration & Quality) ### /batch (Built-in) `/batch` is the command that makes Claude Code feel like it has a team behind it. Give it a description of what needs to change, and it decomposes the work into 5-30 independent units, spins up isolated git worktrees for each, executes them in parallel, and creates pull requests automatically. The key insight is the **isolation model**. Each unit runs in its own worktree with no context bleed from the others. This means a failure in one unit doesn't contaminate the rest. It's the same principle I use when running multiple features in parallel with worktrees, but automated. ``` # Refactor across the entire codebase /batch replace all lodash imports with native equivalents # Add types to an untyped codebase /batch add TypeScript type annotations to all untyped function parameters # Build out a feature across multiple files /batch add comprehensive error handling to all API route handlers ``` **When to use it:** Any task with independent sub-problems: multi-file refactors, migration scripts, test suite generation, or [workflow automations](https://www.turbodocx.com/use-cases/automators.md) that touch many endpoints. If the units of work don't depend on each other, /batch can parallelize them. ### /simplify (Built-in) After every implementation, before I even think about committing, I run `/simplify`. It spawns three parallel review agents that look at your changed files from different angles: - **Reuse Checker:** Finds duplicate logic, missed abstractions, and opportunities to use existing utilities. - **Quality Checker:** Catches logic errors, missing edge cases, and integration issues. - **Efficiency Checker:** Spots unnecessary iterations, missed concurrency, and redundant operations. In my experience, /simplify catches three to five real issues per feature branch. Not cosmetic nitpicks, but the kind of bugs that slip through manual review and surface in production two weeks later. I treat it like a senior staff engineer reviewing every PR before it ships. ### /code-review (Plugin) While /simplify is your post-implementation sanity check, /code-review is the final gate before merge. It runs four independent agents in parallel, each analyzing from a different angle: two agents audit for CLAUDE.md compliance (redundancy for thoroughness), one scans for obvious bugs in changes, and one analyzes git blame and history for context-based issues. What makes it powerful is the **confidence scoring system**. Every finding gets a score from 0-100, and only issues above the threshold (default 80) make it into the report. This filters out the noise that plagues traditional linters and gives you a focused list of things that actually matter: security vulnerabilities, performance regressions, [API contract violations](https://www.turbodocx.com/resources/api-integration-best-practices.md). **How to install:** /code-review is a free plugin from Anthropic's [official plugin marketplace](https://github.com/anthropics/claude-plugins-official). Install it and the command is available in any Claude Code session, with no plan gate required. ## MCP Servers (Context & Documentation) Skills handle code generation. MCP (Model Context Protocol) servers handle _knowledge_. They give Claude Code access to external tools, databases, and live documentation that would otherwise be stale or missing from its training data. These two solve the most common frustration with AI coding assistants: outdated API references and hallucinated parameters. ### Context7 (MCP Server) Built by [Upstash](https://github.com/upstash/context7) (open source), Context7 delivers up-to-date, version-specific library documentation directly into your Claude Code session. Instead of relying on training data that might be months old, Claude gets the actual docs for the exact version of React, Next.js, Prisma, or whatever library you're using. It exposes two core tools: `resolve-library-id` to look up a library, and `query-docs` to fetch specific documentation. When Claude uses Context7, it stops guessing at API signatures and starts referencing the actual source of truth. **When to use it:** Any work involving third-party libraries, especially fast-moving ones where APIs change between versions. If you've ever had Claude write code using a deprecated method or a parameter that doesn't exist in your version, Context7 is the fix. ### Context Hub (MCP Server) Built by [Andrew Ng's team](https://www.marktechpost.com/2026/03/09/andrew-ngs-team-releases-context-hub-an-open-source-tool-that-gives-your-coding-agent-the-up-to-date-api-documentation-it-needs/) (open source), Context Hub tackles a related but different problem. While Context7 focuses on library documentation, Context Hub provides curated, versioned **API specifications**, the kind of documentation you need when you're consuming external services, not just importing packages. The registry currently covers 68+ APIs, and it's growing. What sets it apart is the **agent annotation system**: when Claude discovers a workaround or undocumented behavior during a coding session, it can save that note back to Context Hub. Over time, the documentation gets smarter with every session. It's a feedback loop between your AI coding agent and the docs it relies on. This is particularly valuable when building [API integrations](https://www.turbodocx.com/developers.md), such as consuming payment processors, CRM APIs, or services like our own [TurboDocx document generation API](https://www.turbodocx.com/products/api-and-sdk.md). Context Hub ensures Claude uses the current API spec, not whatever was in its training data. ## How They Work Together These seven tools aren't isolated utilities. They map directly to the Director/Manager/Team model from my workflow post: 1. **You write the brief (Director).** Define the problem, acceptance criteria, and constraints. Your [CLAUDE.md](https://www.turbodocx.com/blog/how-to-write-claude-md-best-practices.md) provides the codebase context. 2. **/batch orchestrates the work (Engineering Manager).** Decomposes into parallel units. Each unit can use **feature-dev** for architecture, **frontend-design** for UI, and **Context7** + **Context Hub** for live documentation. 3. **/simplify reviews the output (Staff Engineer).** Three parallel agents catch reuse opportunities, quality issues, and efficiency problems before you even look at the diff. 4. **/code-review is the final gate (Security, QA, Deep Staff Review).** Four independent agents with confidence scoring ensure nothing ships that shouldn't: security issues, performance regressions, standards violations. The beauty of this stack is that each tool has a clear lane. There's no overlap, no redundancy. Feature-dev and frontend-design handle the _building_. Context7 and Context Hub handle the _knowledge_. /simplify and /code-review handle the _quality_. And /batch ties it all together. It's the same separation of concerns we apply when building software like our [open-source tools](https://www.turbodocx.com/blog/the-power-of-maintaining-open-source.md), just applied to the development process itself. Garry Tan's [gstack](https://github.com/garrytan/gstack) takes a similar role-based approach with different packaging, bundling planning, review, and shipping into a single skill set rather than separating build from review. ## Related Resources - [How to Write a CLAUDE.md That Actually Works](https://www.turbodocx.com/blog/how-to-write-claude-md-best-practices.md): The foundation that makes every tool on this list effective. Structure, progressive disclosure, and best practices. - [API Integration Best Practices](https://www.turbodocx.com/resources/api-integration-best-practices.md): Production-ready patterns for authentication, error handling, webhooks, and rate limiting. ## Build Faster with the Right Toolkit These are the same tools we use to build TurboDocx. See how document automation and e-signatures can accelerate your team. [Schedule a demo](https://www.turbodocx.com/demo) or [explore the API](https://www.turbodocx.com/products/api-and-sdk.md).