claude-code-workflows: A Plugin That Makes Claude Code Agree on the Outcome Before It Codes
Production-ready development workflows for Claude Code, powered by specialized AI agents.
At a glance
- What is it?
- A Claude Code plugin that adds staged design, verification, and independent review to AI-assisted development. It targets non-trivial changes where scope agreement matters more than raw exploration.
- Who is it for?
- Adopt this plugin if your team uses Claude Code for backend, frontend, or full-stack changes that cross responsibilities or need durable design decisions, and you are willing to accept extra agent calls and artifact overhead. Do not use it for throwaway experiments, prototypes, or small changes where the outcome and safe boundary are already clear; the README explicitly says to use Claude Code directly in those cases.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly JavaScript, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The Problem: Exploration Without Convergence
Claude Code can explore a codebase deeply. The README makes the harder problem explicit: convergence. On a non-trivial task, Claude may find a real inconsistency in token handling while designing an account-recovery flow, then spend most of its effort on that side finding, leaving the requested recovery behavior vague. This plugin exists to keep that exploration pointed at an agreed result. The intended user is a developer or team using Claude Code for real changes where the outcome needs agreement before implementation starts. It is not for trivial edits or prototypes. The README is direct: use Claude Code directly when the outcome and safe implementation boundary are already clear.
How the Workflow Forces Agreement
The core mechanism is a staged pipeline that starts with agreeing on the outcome and exclusions. The flow chart in the README shows a decision point: if there is one evident implementation path, Claude goes into a direct task cycle. If not, it moves to inspect, design, and review, then to an approved implementation scope. After that, each task goes through implement, verify, quality-check, and commit. On larger changes, an independent review checks the finished implementation against the agreed result, looks for unnecessary changes, and flags functional, reliability, or security problems. The key design choice is that the number of product and design decisions determines the route, not file count or amount of implementation work. A small change that follows an existing pattern within one responsibility gets the direct cycle. A medium change that crosses responsibilities or needs a lasting design decision gets a reviewed Design Doc, possibly a UI Spec or ADR, an integration or E2E proof, and a reviewed Work Plan. Large changes with multiple independent outcomes get a PRD as well.
Getting It Running: Marketplace and Plugin Installation
The setup requires a Claude Code release with plugin marketplace support. You start Claude Code, then add the marketplace with a slash command: `/plugin marketplace add shinpr/claude-code-workflows`. Then you install one workflow plugin. For backend or general changes, install `dev-workflows` and invoke `/recipe-implement`. For frontend, install `dev-workflows-frontend` and use `/recipe-front-design`. For full-stack, install `dev-workflows-fullstack` and use `/recipe-fullstack-implement`. The README warns to install only one workflow plugin, because `dev-workflows-fullstack` already contains the backend and frontend workflows. If you previously used full-stack recipes from `dev-workflows`, you must migrate to `dev-workflows-fullstack`. For team setup, you can add the marketplace and plugin with `--scope project`, which commits a `.claude/settings.json` so contributors are prompted to use the same plugin.
What the Recipes Actually Do
The plugin exposes a set of slash commands that map to different stages. `/recipe-implement` delivers a backend, API, CLI, or general change end to end. `/recipe-design` stops after design. For frontend, there is a three-stage path: `/recipe-front-design`, then `/recipe-front-plan`, then `/recipe-front-build`. The full-stack command combines backend and React frontend delivery. There is also `/recipe-review` for reviewing a completed implementation against the agreed outcome, `/recipe-quality-profile` for setting repository-specific quality rules, `/recipe-diagnose` for investigating a problem before choosing a fix, and `/recipe-reverse-engineer` for documenting an existing system from its code. The README gives a concrete example: `/recipe-implement "Add rate limiting to the public API"`. The staged frontend path is explicit: `/recipe-front-design` stops after the UI Spec and Design Doc are reviewed and approved, and you run the next commands when ready.
The Real Trade-Off: Artifacts and Agent Calls
The README is honest about the cost. The workflow adds agent calls and artifacts, so it should earn that cost. That is a genuine limitation. For a change that is small and follows an existing pattern, the direct cycle still includes focused and repository checks plus a security review. For anything larger, you are paying for design docs, UI specs, ADRs, integration proofs, and a reviewed work plan. If your team is comfortable with Claude making implementation decisions without review, or if you only need a quick fix, this plugin is the wrong tool. The README explicitly lists throwaway experiments and prototypes as cases where you should use Claude Code directly. The overhead is not just time; it is also the risk that the generated artifacts become the source of truth instead of the actual code. The workflow tries to mitigate that by requiring observable evidence for decision-changing design premises, but the process still depends on the quality of the review prompts.
A Real Alternative: Unstructured Claude Code Use
The obvious alternative is using Claude Code without any workflow plugin. The README itself frames this as the default for clear-cut tasks. The difference is in where control sits. With plain Claude Code, you give a prompt and let the model explore, design, and implement in one pass, and you review the final diff. With this plugin, you interleave explicit agreements, design documents, and independent reviews at defined stages. The trade-off is that plain Claude Code is faster and cheaper for small tasks but can drift on non-trivial ones. The plugin trades speed and autonomy for convergence and verification. Another alternative is a manual process where you write your own design doc and review checklist outside Claude Code, but that does not give you the packaged commands or the independent review step. The plugin's value is that the process is reproducible across repositories without prescribing Claude's steps.
Maintenance and Licensing
The repository is under the MIT license, which means you can use, modify, and redistribute it freely, but the README does not discuss maintenance obligations. The project has a release history with versions like v0.25.1 and v0.25.0, and the last push was in August 2026, so it appears actively maintained. However, you should check the release notes for breaking changes, especially around the migration from `dev-workflows` full-stack recipes to `dev-workflows-fullstack`. The plugin depends on Claude Code's plugin marketplace support, which means upgrades to Claude Code itself could affect compatibility. The README mentions that if the install tells you to run `/reload-plugins`, you should do so before invoking the recipe. That is a concrete maintenance step. You should also commit the `.claude/settings.json` to keep the team on the same plugin version, which is a maintenance decision in itself.
What to Verify Before You Trust the Review Step
The independent review is the most interesting part of this workflow, but the README does not specify what the review actually checks beyond the stated categories: agreed result, no unnecessary changes, and no serious functional, reliability, or security problems. That is a meaningful gap. The review is only as good as the prompts and the model's judgement at that moment. You should read the actual workflow files in the repository before relying on them for security-sensitive work. The README also says that generating an artifact does not advance the workflow on its own, and that decision-changing design premises are resolved with observable evidence using a bounded probe only when it is the smallest sufficient proof. That is a constraint you should verify in practice. For a security review, you cannot assume the plugin catches everything; you still need human review of the final diff, especially for authentication, authorization, and data handling.
Editorial conclusion
Adopt this plugin if your team uses Claude Code for backend, frontend, or full-stack changes that cross responsibilities or need durable design decisions, and you are willing to accept extra agent calls and artifact overhead. Do not use it for throwaway experiments, prototypes, or small changes where the outcome and safe boundary are already clear; the README explicitly says to use Claude Code directly in those cases. Before adopting, verify that your Claude Code release supports plugin marketplaces, commit the project-scoped settings so contributors share the same workflow, and confirm that the independent review step matches your team's definition of acceptable verification. The plugin is MIT-licensed, but you must read the full workflow files and the Claude Code plugin documentation to understand exactly what the review checks and what it can miss.
Community notes