claude-workflow-v2: A Claude Code Plugin That Ships 7 Agents, 26 Commands, 14 Skills and 14 Hooks

The problem is not Claude Code, it is the setup work around it

A Claude Code session starts with almost nothing configured. You get a model, a filesystem, and whatever instructions you have written into a project file. Everything else (a reviewer that checks your diff, a commit message generator, a command that runs the build before you push) has to be authored, named, and wired up per repository. That is repetitive work, and it is the work this project tries to remove.

The README describes the target user indirectly. The installation options include an Agent SDK snippet, a per-session CLI flag, and a skills.sh path that the README says works with Claude Code, Cursor, Codex, Windsurf, Cline and "35+ other AI agents". That breadth is the actual pitch: one definition of a skill, consumed by several different coding agents. If you only ever use Claude Code, the multi-agent angle does nothing for you and the npm installer is the shorter path.

The repository is Python, MIT-licensed, not archived, and the last push recorded is 2026-08-25. No releases were retrieved, which matters later.

Four install paths, and they do not install the same thing

The README lists five options, but they collapse into two distinct payloads. The skills.sh route runs `npx skills add CloudAI-X/claude-workflow-v2` and, per the README, "Installs skills to Claude Code, Cursor, Codex, Windsurf, Cline, and 35+ other AI agents automatically." That is skills only. The npm route runs `npx install-claude-workflow-v2@latest` and the README says it "Installs the complete plugin: agents, commands, skills, and hooks."

If you want the 26 slash commands and the 14 hooks, the skills.sh path is the wrong one. That distinction is stated in the README but it is easy to miss because both commands start with `npx` and both are presented as ways to get the project running.

The remaining options are for local use. `git clone https://github.com/CloudAI-X/claude-workflow-v2.git` followed by `claude --plugin-dir ./claude-workflow-v2` loads the plugin for one session. The README also gives `claude plugin install ./claude-workflow-v2` for a local directory install, and `claude plugin install project-starter` from a marketplace, with the caveat "when available". The Agent SDK path passes `plugins: [{ type: "local", path: "./claude-workflow-v2" }]` into `query()` from `@anthropic-ai/claude-agent-sdk`.

Verification is a single command. The README says to run `/plugin`, tab to Installed, and confirm `project-starter` appears, then tab to Errors and confirm it is empty. Note the naming: the repository is claude-workflow-v2, the plugin identifies as project-starter, and every command is prefixed `/project-starter:`. If you clone into a differently named directory, the `--plugin-dir` argument changes but the command prefix does not.

What the plugin actually contains: counts, categories, and one mechanism

The README gives a component table: 7 agents, 26 commands, 14 skills, 14 hooks. Those counts are the most concrete thing in the material, and they are also the least useful on their own. What matters is how each category is triggered.

Agents are subagents that the README says "spawn automatically based on your request". The examples show a debugger agent activating on a 401 error report, a code-reviewer on "Review my changes", and an orchestrator on "Add authentication to the API", where the orchestrator decomposes the request and spawns architect, test-architect and docs-writer. Automatic dispatch means you do not choose the agent; the prompt does. That is convenient when the match is right and opaque when it is not.

Commands are explicit. They are typed as `/project-starter:<command>` and the README groups them into output styles (architect, rapid, mentor, review), git workflow (commit, commit-push-pr, quick-fix, add-tests, lint-fix, sync-branch, summarize-changes), and verification (verify-changes, validate-build). The output styles are the interesting category because they change how the model responds rather than what it does: architect is described as "architecture before code", rapid as "ship quickly, iterate".

Skills load context on demand. The README's examples show a designing-architecture skill firing on a structuring question and an optimizing-performance skill firing on a speed question. Hooks are the only component that runs without a prompt, and they are the one to scrutinise before installing.

The hooks are the part that touches your files

Three hook behaviours are described. A pre-edit security hook blocks writes when it detects a secret; the README's example output shows a file and line, a pattern labelled as an API key, and the instruction "Remove the secret and use environment variables." A post-edit formatter hook runs after writes; the example shows prettier on a .tsx file and black on a .py file. A notification hook fires desktop alerts, with the README naming two events: "Claude needs input" and "Task complete".

This is where the README stops being a specification. It does not state which files under the hooks directory implement each behaviour, what the secret-detection patterns are beyond the single `sk-` style example, whether the formatter hook detects the project's toolchain or is configured per language, or whether either hook can be disabled individually. The pre-edit block is the highest-consequence behaviour in the whole plugin: a false positive stops an edit, and a false negative writes a credential. Neither failure mode is documented.

A reasonable position is that the hook set is the reason to install the full plugin rather than the skills-only path, and simultaneously the reason to read the source before doing so. The README tells you the hooks exist and shows sample output. It does not tell you their matching rules.

Verification is the most defensible feature and the least specified

The `/project-starter:verify-changes` command is described as "Multi-subagent adversarial verification". The example output shows four named checks (build-validator, test-runner, lint-checker, security-scanner) with results, including a non-blocking warning on lint and a clean security result. The word adversarial is doing real work in that description: the design intent appears to be that verification is performed by agents other than the one that wrote the code.

What is missing is the contract. Does verify-changes fail the workflow on a security-scanner finding, or does it report and continue? The example shows a lint warning explicitly marked "non-blocking", which implies blocking is a category, but the README does not say which categories block. Does it run the project's own test command or its own? Nothing in the material answers this.

There is a related command, `/project-starter:validate-build`, listed under Verification with the purpose truncated in the README at "Build process valida". If you are evaluating this plugin on the strength of its verification story, that truncation is a signal that the command reference is not fully maintained, and you should read the command files rather than the table.

Where it is the wrong tool, and what to use instead

The clearest failure case is a repository with strong existing conventions. If your project already has a CLAUDE.md, a pre-commit framework, a CI pipeline that runs lint and tests, and a house style for commit messages, this plugin duplicates all of it. The hooks would run formatters alongside your pre-commit hooks, and the commit command would generate messages in conventional-commit format regardless of what your team uses. Two systems writing to the same working tree is a conflict you have to resolve by disabling one.

The honest alternative is not another plugin. It is a hand-written CLAUDE.md plus a small number of custom slash commands in `.claude/commands/`, which is the mechanism Claude Code already provides. The difference in approach is scope and control: a CLAUDE.md is prose that the model reads every session and that you can edit in thirty seconds, while claude-workflow-v2 is a distributed package of 61 components (7 agents, 26 commands, 14 skills, 14 hooks) that you adopt wholesale and then prune. For a single-repository team with settled conventions, the hand-written file is smaller, has no install step, and cannot break on an upstream change. For someone working across several repositories or several agents, the package earns its size.

A second case where it is wrong: any environment where you cannot review executable hook scripts before they run. The plugin installs automation that fires on file edits. If your workflow requires change review for tooling, the skills-only installation via skills.sh is the narrower option, since the README associates hooks with the full plugin path.

Maintenance, versioning and the licence

The licence is MIT, stated in the README badge and in the repository metadata. MIT permits use, modification and redistribution with the licence text retained. That is permissive and unremarkable; it also means no warranty, and nothing in this material suggests the authors offer support. This is not legal advice, and if you redistribute the plugin inside a product you should read the licence text rather than a badge.

Maintenance is the sharper question. No releases were retrieved for this repository, and the README itself hedges on the marketplace install with "when available". The two automated install paths, `npx skills add CloudAI-X/claude-workflow-v2` and `npx install-claude-workflow-v2@latest`, both resolve against the current state of the project rather than a tagged version. The `@latest` suffix in the second command is explicit about that. There is no documented version to pin, so an upgrade is whatever the next push contains.

The upgrade cost follows from the component count. With 26 commands and 14 hooks, an upstream change can alter a command you have built habits around, or change a hook's matching rules, without a version boundary to notice it. The README's own compatibility badge specifies Claude Code v1.0.33 or later, which is the only version constraint given anywhere in the material. If you need reproducibility, the `git clone` plus `--plugin-dir` path at least lets you pin a commit yourself, which the npm installer does not.

Editorial conclusion

Adopt claude-workflow-v2 if you already run Claude Code daily and want a pre-built set of slash commands and subagents without writing them yourself, and if you are willing to read the hook scripts before enabling them because a pre-edit secret scanner and post-edit formatters run against your working tree. Do not adopt it if you need a documented, versioned release to pin against: the repository shows no releases, so the npm installer and the git clone both track the main branch. Before installing, verify three things in the repository itself: which files under the hooks directory actually execute on pre-edit and post-edit events, what the security hook matches against, and whether the plugin directory name you pass to --plugin-dir matches the /project-starter: command prefix you expect to type.

Official sources

1. CloudAI-X/claude-workflow-v2 on GitHub
2. Issues
3. License: MIT
4. README