3 Claude Code plugins for development, commits and review

Which Claude Code plugins should you choose?

This selection combines three distinct jobs with publicly inspectable sources. It is not a ranking against every available plugin. Start with the step you need: a full feature workflow may be excessive for a typo, while a finished change needs a careful handoff rather than another design session.

feature-dev: develop a feature

Explore relevant code, clarify requirements, choose an approach, implement, and review. Useful when the task crosses several files or decisions.

commit-commands: hand over the change

Create commits or run a combined commit, push, and PR workflow. Inspect the files before invoking a command that publishes changes.

code-review: examine an existing PR

Review the diff and relevant CLAUDE.md guidance with several agents. It belongs after PR creation, not before the first local commit.

• Anthropic: official plugin marketplace ↗
• DottorLone: skills, MCP and plugins →

How to install plugins in Claude Code

These steps assume a working Claude Code terminal installation. Run the shell commands from your project directory. GitHub operations also require Git, an origin remote, and GitHub CLI, gh, authenticated for that repository.

Local scope enables a plugin for you in this repository; it is not a security sandbox. Start a new session after installation and check the full command names in the / menu. The examples use plugin prefixes.

If the official marketplace is missing, first run claude plugin marketplace add anthropics/claude-plugins-official. You can also install through the /plugin panel and choose local scope.

• Claude Code: plugin installation and scope ↗
• Claude Code: plugin security and trust ↗

claude plugin install feature-dev@claude-plugins-official --scope local
claude plugin install commit-commands@claude-plugins-official --scope local
claude plugin install code-review@claude-plugins-official --scope local
claude plugin list

1. feature-dev: turn the idea into a bounded change

The documented workflow has seven phases, with agents for exploration and architecture, clarification questions, and a choice before implementation. I would use that structure for a feature involving data and UI, and skip it for a spelling fix.

Our example adds a category filter to a guide list. The following prompt is an original example for readers to try, not a recorded Claude session.

• feature-dev: workflow README ↗
• feature-dev: command instructions ↗
• DottorLone: turn a vague request into a task →

/feature-dev:feature-dev Add a category filter to the guide list.

Let readers choose All, Everyday, or Development and see matching guides.
Reuse the existing data and components. No backend or new dependencies.
Support keyboard use and mobile screens.
Keep article URLs and canonical links unchanged.
Before implementation, explain affected files, open questions, and your approach.
This request covers development and checks, not commits, pushes, or deployment.

Verify behaviour before the handoff

Use three synthetic guide entries with known categories. These are proposed test data, and the counts below are expected outcomes. Switching back to All matters: a filter can work on the first click and leave stale state on the next transition.

1. Check initial loading, every transition, guide order, and article links.
2. Use Tab and the keys appropriate to the chosen control; check visible focus and selection.
3. Try desktop and mobile widths and inspect the browser console.
4. Run the build and tests required by your README; read every changed file.
5. Record failed and unperformed checks as well as successful ones.

• DottorLone: review AI-generated code →

Guide entries:
- Simple prompts: Everyday
- Code review: Development
- Chat privacy: Everyday

All          -> 3 guides
Development  -> 1 guide: Code review
Everyday     -> 2 guides: Simple prompts, Chat privacy
All          -> 3 guides again, in the original order

2. commit-commands: open a PR with an inspected diff

The plugin separates making a commit from commit-push-pr, which also pushes to origin and creates a PR with gh. A proposed commit message is a different request: the commit command is intended to create the commit.

Create a working branch first. Inspect Git status, the full diff, and staged files; exclude unrelated edits, local files, and secrets before authorising the combined command.

• commit-commands: commands and prerequisites ↗
• commit-push-pr: operation sequence ↗

/commit-commands:commit-push-pr

3. code-review: examine the open pull request

From the branch associated with the PR, invoke the review command. Its checked instructions skip closed, draft, trivial PRs and PRs with a previous Claude comment. A skipped review is not a passed review.

In the checked command, omitting --comment keeps the findings in the terminal. Adding --comment enables publishing on GitHub. Inspect the installed version before using that mode.

Compare findings with your filter counts and actual keyboard and mobile checks. An empty findings list does not prove correct behaviour; diff review, build, and interaction checks provide different evidence.

• code-review: usage and GitHub requirements ↗
• code-review: skip conditions and --comment ↗

/code-review:code-review

Decide whether the workflow helps you

Try a small feature and record Claude Code, plugin, and model versions. Compare expected and actual changed files, successful behaviour checks, confirmed findings, and manual corrections. More agents or more comments do not by themselves establish a better result.

We did not measure time, tokens, or cost. Check your plan conditions and observe usage during a short trial, including the time you spend answering questions and verifying findings. You can stop before opening a PR during a local experiment, or use only code-review when a PR already exists.

Feature and expected behaviour: ...
Claude Code / plugin / model versions: ...
Expected and actual changed files: ...
Build and tests, with outcomes: ...
Desktop / mobile / keyboard checks: ...
Confirmed review findings: ...
Manual corrections: ...
Observed time and account usage: ...
Decision: reuse / adapt / leave out

Frequently asked questions about Claude Code plugins

Which plugin should I start with?

Consider feature-dev for a new feature, commit-commands for handing over verified changes, and code-review for examining an open PR. You do not need all three to try one step.

How do I install these three plugins?

From your project directory, use claude plugin install with the plugin name, the claude-plugins-official marketplace and the desired scope. The installation section gives complete local-scope commands.

Does code-review work on draft PRs?

The checked instructions skip draft PRs. Keep unfinished work in draft and continue local checks; invoke the review when the PR is ready.

Can I use them in a regular Claude chat?

These commands target terminal Claude Code. Check the documentation and component availability for Claude chat, Cowork or other surfaces rather than assuming the same installation and commands apply.

• Go to the three plugin installation commands →

Sources and limits

Documentation checked on October 30, 2026: Claude Code installation and scope documentation, plus the READMEs and command files in anthropics/claude-plugins-official linked above. The source main branch can change; compare it with your installed version.

The filter scenario and its verification criteria are an original proposed exercise. We did not install or run the plugins for this article, and claim no measured speedup, fixed cost, or bug-detection rate. This guide targets terminal Claude Code; check the relevant documentation before applying it to another Claude surface.

• Original guide in Italian →