Claude Code Workflows: a recipe plugin that agrees on scope before writing code

Three plugins, and you are told to install exactly one

The marketplace carries three workflow plugins: `dev-workflows` for backend, API, CLI and general changes, `dev-workflows-frontend` for React and TypeScript work, and `dev-workflows-fullstack` for both at once. The install command names the plugin in its argument:

# Backend or general
/plugin install dev-workflows@claude-code-workflows
/recipe-implement "Add rate limiting to the public API"

# Frontend
/plugin install dev-workflows-frontend@claude-code-workflows
/recipe-front-design "Add account recovery screens"

# Full-stack
/plugin install dev-workflows-fullstack@claude-code-workflows
/recipe-fullstack-implement "Add user authentication with JWT + login form"

Installing more than one is the mistake the README warns about, because `dev-workflows-fullstack` already contains the backend and the frontend workflows. There is a migration path for anyone who used the full-stack recipes from `dev-workflows` before that split existed: move to `dev-workflows-fullstack`. The marketplace itself is added first with `/plugin marketplace add shinpr/claude-code-workflows`, and if the install asks for `/reload-plugins`, that has to happen before a recipe runs.

The route is chosen by decision count, not file count

The flowchart behind every recipe asks one question: is there one evident implementation path? If yes, the change goes straight to a task cycle and finishes. If no, it goes through inspection, design and review, an approval stop on the implementation scope, and then per task: implement, verify, quality-check, commit.

The routing rule is written in terms of decisions rather than size. A change with one outcome that follows an existing pattern inside one responsibility takes the short path. A change that crosses responsibilities, or that needs a decision worth remembering, gets a reviewed Design Doc and a Work Plan first, and adds a PRD, a UI Spec or an ADR when one of its decisions calls for that.

What counts as a decision is left to you, which is the part worth thinking about before you pick a recipe. A twenty file refactor with one decision may take the short route, and a three file change with three product decisions will not.

Review findings do not turn into work on their own

The final stage is an independent implementation and security review, and the flowchart gives it exactly three exits. A correction sends the task back to the per-task loop. A changed boundary sends the whole thing back to agreeing on outcome and exclusions. A pass ends it.

The middle exit is the interesting one, because it is the only path where the agreement itself is reopened. The README is clear that review suggestions do not become work automatically: the main session decides which findings belong to the agreed outcome and declines the rest with a reason.

So the review is advisory by design. A finding is not a ticket, and a reviewer that disagrees with the agreed scope has to argue for it rather than edit the branch. The boundary change loop is the escape hatch for when the scope really was wrong.

Lite mode drops the security review and keeps the final one

Lite mode is requested in the request itself, with any recipe:

/recipe-implement "Lite mode. Add rate limiting to the public API"

The phases and the approval stops stay. What changes is the depth of checking. Design Docs are not checked against the repository or against each other. The separate security review is skipped. Repository quality checks run once after the last task instead of before every commit. The final code review still runs.

Two details decide how useful it is in practice. Lite mode stays on for the rest of the session until you ask Claude to drop it, so it is a session-level setting rather than a per-invocation flag. And because the final review survives, the mode reduces the cost of the middle of the process rather than the accountability at the end of it.

Project scope turns the plugin choice into a committed file

For a team, the install can be scoped to the project rather than to a user, and the result is a file in the repository:

claude plugin marketplace add shinpr/claude-code-workflows --scope project
claude plugin install dev-workflows-fullstack@claude-code-workflows --scope project

Claude Code supports project-scoped marketplaces and plugins, and the recommendation is to commit the resulting `.claude/settings.json` so contributors are prompted to use the same workflow plugin when they open the repository.

Notice the syntax difference. Inside a session the commands are slash commands, `/plugin marketplace add` and `/plugin install`. Scoped installs are spelled as shell commands, `claude plugin marketplace add` and `claude plugin install`. Both forms appear in the same Quick Start section, and the second one is the one to run from a terminal if you are setting a team default.

A private package whose only dev dependency is a git hook

The manifest is small because the content is not JavaScript in the usual sense. `claude-code-workflows` is `"private": true`, version 0.28.0, `"type": "module"`, `engines` at Node 22 or newer, and `[email protected]` as the package manager. Its single devDependency is `lefthook` at ^2.1.6, and the `prepare` script runs `lefthook install`, so a clone wires its git hooks automatically.

Two scripts keep the plugin directories honest: `sync` runs `scripts/sync-plugins.mjs`, and `sync:check` runs the same file with `--check`. That check script is the shape of a continuous integration guard against the three plugin directories drifting apart, which is the failure mode a copy-based layout invites.

The rest of the tree is content: `.claude-plugin/` at the root, `agents/`, `skills/`, `dev-skills/`, the three `dev-workflows*` directories, `scripts/`, `lefthook.yml`, a `.nvmrc`, and six README translations covering Simplified Chinese, Japanese, Spanish, Korean and Brazilian Portuguese.

v0.28.0 is dated after the last recorded push

The release line moves fast and the dates do not line up neatly. v0.27.4 and v0.27.5 were both tagged on 2026-09-24, the later one at 22:03, which is the same timestamp as the last recorded push. Then v0.28.0 appears dated 2026-10-01, a week after that push, while the version in `package.json` already reads 0.28.0.

So the manifest and the newest tag agree on the version, and the tag date is later than the last commit date. That combination is what you get when a release is published from an existing commit rather than from a fresh release commit, which is worth knowing before you use tag dates to reason about how fresh an install is.

For context on scale, the repository is MIT licensed and not archived, and the workflow plugins are the deliverable while the npm package is only the local build harness that keeps the plugin copies in sync and installs the hooks.

Editorial conclusion

The plugins fit work where a side finding could quietly grow into a rewrite, where a design can be internally consistent and still miss what was asked, and where a green test is not the same as a proven claim. They do not fit small edits, and the README says so plainly, pointing back to plain Claude Code for routine changes and throwaway prototypes. Before installing, decide which of the three plugins you want, because you are told to install exactly one, and decide whether the extra agent calls are worth it on your change sizes, since lite mode only removes some of the checks and never the final review.

Frequently asked questions

Official sources

1. Official README
2. Project repository
3. Release notes