Multi-Agent Harnesses and Catalogues: Ruflo, wshobson/agents, SuperClaude, Task Master and CCPM

Multi-agent harnesses and catalogues add task graphs, specialist subagents and issue tracking on top of Claude Code, Codex and Cursor. CCPM and Task Master turn a PRD into dependency-ordered tasks, wshobson/agents supplies specialist subagents and orchestrators à la carte, SuperClaude is a command menu for Claude Code only, and Ruflo is research-grade: powerful, large and hard to audit.

You have a two-page PRD for a user profile page, four agents you could run at once, and a sprint board that has to show real progress. Last time you tried this, two agents rewrote the same form component, nobody could tell which commit belonged to which ticket, and an MCP server loaded 21,000 tokens of tool schemas before the first prompt. You need the fan-out without the mess.

This page is for the developer who runs the agents and the tech lead who owns the board and the merge gate. It runs one orchestrator end to end, then builds the full PRD → task graph → parallel agents → GitHub issues workflow from the tools that do each step best.

Versions and popularity on this page

Checked on 2026-09-26 against each project’s README on GitHub, the npm and PyPI registries, and the installed Claude Code 2.1.283 and codex-cli 0.157.1. GitHub stars read on 2026-09-26 (attention, not usage): ruvnet/ruflo 73.3k (npm ruflo 3.46.1, 2026-09-26), wshobson/agents 40.0k (plugin full-stack-orchestration 1.3.1), eyaltoledano/claude-task-master 28.1k (npm task-master-ai 0.43.1, 2026-03-31), SuperClaude-Org/SuperClaude_Framework 23.9k (PyPI superclaude 4.3.0, 2026-03-22) and automazeio/ccpm 8.4k. cursor.com was unreachable from the writing environment, so every Cursor step below comes from the project’s own README, not from a test.

What you’ll walk away with from multi-agent harnesses

• A decision table for the five tools, with the right package names and context costs, plus a working /full-stack-orchestration:full-stack-feature run with its two approval checkpoints and the nine numbered files plus state.json it leaves behind.
• A team workflow from PRD to task graph, GitHub issues, parallel agents and merge, with four copy-paste prompts and a traps list built from the package names, tool names and paths that tutorials get wrong.

Which multi-agent harness solves which problem?

The five do different jobs: two plan work, one supplies workers, one is a prompt menu and one is a whole runtime.

Tool	What it adds	Install from	Claude Code / Codex / Cursor	Context cost	Status on 2026-09-26	Pick it when
CCPM	One Agent Skill: PRD → epic → tasks → GitHub issues → parallel agents	git clone of automazeio/ccpm, then link skill/ccpm/	Yes / Yes / Yes (all three named in the README)	One skill description until it fires	Active; the old /pm:* commands live only on the v1 branch	Issues must be the source of truth and every commit must trace to one
Task Master	MCP server and CLI: PRD → dependency-aware task graph, next task	npm task-master-ai	Yes / Yes (any MCP client) / Yes	~21,000 tokens for all 36 tools, ~5,000 in core mode (README, vendor-stated)	Last npm release 2026-03-31	You want a task graph any agent can query, without GitHub
wshobson/agents	Marketplace claude-code-workflows: 94 plugins, 202 agents, 16 orchestrators	/plugin marketplace add wshobson/agents	Yes / Yes / Yes (README)	~599 tokens for full-stack-orchestration (measured)	Active	You want specialist subagents or a ready orchestrator, one plugin at a time
SuperClaude	30 /sc:* commands and personas	PyPI superclaude (not npm)	Yes / No / No	Not measured (commands, not a plugin)	No release since 2026-03-22	You are a Claude Code user who wants a preset command menu
Ruflo (ex-claude-flow)	CLI, MCP server, hooks, daemon, swarms, vector memory, 39 plugins	npm ruflo or /plugin marketplace add ruvnet/ruflo	Yes / Yes / No	~579 tokens for ruflo-core, excluding its MCP tool schemas (measured)	Active, research-grade	You are experimenting with swarms and agent memory in a sandbox

“Measured” means claude plugin details on Claude Code 2.1.283, which reports a plugin’s always-on cost: the skill and agent descriptions loaded into every session. Hooks cost no model context; MCP tool schemas do, and details does not count them.

Before installing any of them, check whether the tool you already run covers the need. Claude Code ships subagents, /batch (5 to 30 worktree units) and --worktree; Codex and Cursor both ship subagents and worktrees. A harness earns its place when it adds something those lack: a durable task graph, issue traceability or a tested specialist prompt. The patterns themselves are on multi-agent orchestration patterns.

Run one orchestrator end to end: full-stack-feature

full-stack-orchestration is the wshobson/agents plugin that turns one sentence into a nine-step feature run with two human checkpoints. It is the fastest way to see what a harness does.

Install the plugin in Claude Code, Codex or Cursor

Claude Code

In a Claude Code session:

/plugin marketplace add wshobson/agents
/plugin install full-stack-orchestration@claude-code-workflows

Check its cost in a terminal before the first run:

claude plugin details full-stack-orchestration@claude-code-workflows

On 2.1.283 it reports one skill (full-stack-feature), four agents (deployment-engineer, security-auditor, performance-engineer, test-automator) and about 599 always-on tokens.

Codex

In a terminal:

codex plugin marketplace add wshobson/agents
codex plugin add full-stack-orchestration@claude-code-workflows

The marketplace registers as claude-code-workflows in Codex too. The project README shows npx codex-marketplace add wshobson/agents instead; that is a third-party npm package, and the native codex plugin marketplace add works without it.

wshobson’s own harness notes say Codex receives slash commands as skills and delegates to an agent only when the prompt names it. Codex caps a skill body at 8 KB; wshobson’s generator moves the rest of the ~20 KB command into references/details.md. Before the first run, ask Codex to quote the skill’s PHASE CHECKPOINT 2 section; if it cannot find it, the reference file did not load and the run will not stop where you expect.

Cursor

Per the wshobson/agents README, Cursor reads the repository’s .cursor-plugin/ marketplace: add wshobson/agents as a plugin marketplace, then run this in Agent chat:

/plugin install full-stack-orchestration

Cursor honours only a readonly: flag, not the per-agent tools: allowlist (the README’s capability matrix), so the security and performance agents run with the session’s full tool access. Keep them in a session whose permissions you have already reviewed.

Start the run

Copy-paste prompt: orchestrate a user profile page

/full-stack-orchestration:full-stack-feature user profile page with avatar upload, display name and bio editing, visible only to the signed-in owner --stack react/fastapi/postgres --api-style rest --complexity medium

The namespaced form always resolves; the bare /full-stack-feature works only when nothing else uses the name. The three flags come from the command’s own argument hint; leave --stack out and it auto-detects the stack from the repository.

What you should see

1. Pre-flight. The command creates .full-stack-feature/state.json. If one already exists with "status": "in_progress", it offers to resume or start fresh, so an interrupted run is not lost.

2. Requirements, one question at a time. It asks six questions, from the problem to dependencies, and writes 01-requirements.md with acceptance criteria as checkboxes. You verify against those later, so answer the second question with observable behaviour (“a 6 MB avatar is rejected with a 413 and a message”), not intent.

3. Design, then checkpoint 1. Two subagents write 02-database-design.md and 03-architecture.md. The run stops and offers Approve, Request changes or Pause. It must not continue until you choose Approve.

4. Implementation. Steps 4 to 6 write the database, backend and frontend changes, each summarised in its own numbered file.

5. Parallel validation, then checkpoint 2. Step 7 launches three agents at once: test-automator, security-auditor and performance-engineer. Their findings land in 07-testing.md with counts of critical, high and medium issues; critical and high findings are fixed before the second checkpoint.

6. Delivery. Step 8’s deployment-engineer writes CI changes, migration steps, feature-flag configuration, health checks, alerts and a runbook with rollback steps. Step 9 writes API docs, an architecture decision record and a handoff summary. state.json ends as "complete".

The nine numbered files plus state.json in .full-stack-feature/ are the run’s evidence trail. Commit them with the pull request, or delete them deliberately; do not let them drift into the next feature’s run.

Copy-paste prompt: review a checkpoint before you approve it

Before I answer this checkpoint, act as an independent reviewer. Read .full-stack-feature/01-requirements.md and every later file in .full-stack-feature/. List, with file and section references: (1) each acceptance criterion that has no test planned or written for it, (2) each design or implementation choice that contradicts a stated constraint or the out-of-scope list, (3) each assumption no answer of mine confirmed. Do not edit anything. If all three lists are empty, say so in one line.

Build the team workflow: PRD, task graph, parallel agents and GitHub issues

A team needs the plan to outlive the session, the work on the board, and each agent’s commits traced to a ticket. CCPM does that with GitHub issues, Task Master with a local task graph. The steps below use CCPM as the spine and show where Task Master and the wshobson agents slot in.

Install CCPM and Task Master

CCPM needs git and an authenticated gh (gh auth login) in a repository that has a GitHub remote. For real parent-child issues, install the extension its README names; without it, CCPM falls back to task lists.

# terminal, once per machine
git clone https://github.com/automazeio/ccpm.git ~/tools/ccpm
gh extension install yahsan2/gh-sub-issue

Claude Code

# terminal, in your project root
mkdir -p .claude/skills
ln -s ~/tools/ccpm/skill/ccpm .claude/skills/ccpm

# Task Master over MCP, in its 7-tool core mode
claude mcp add task-master-ai --scope user --env TASK_MASTER_TOOLS=core -- npx -y task-master-ai@0.43.1

Codex

CCPM’s README names Codex among its supported Agent Skills harnesses; point it at skill/ccpm/. Codex reads project skills from .agents/skills/:

# terminal, in your project root
mkdir -p .agents/skills
ln -s ~/tools/ccpm/skill/ccpm .agents/skills/ccpm

# Task Master over MCP, in its 7-tool core mode
codex mcp add task-master-ai --env TASK_MASTER_TOOLS=core -- npx -y task-master-ai@0.43.1

CCPM keeps its own files under .claude/prds/ and .claude/epics/ whichever agent runs it.

Cursor

CCPM’s README names Cursor among its supported Agent Skills harnesses. Cursor’s skill folders could not be re-verified on 2026-09-26, so link ~/tools/ccpm/skill/ccpm into the project skills folder that Cursor’s own Skills settings list, rather than a path from a tutorial. Then add Task Master to .cursor/mcp.json (the key is mcpServers, per Task Master’s README):

{
  "mcpServers": {
    "task-master-ai": {
      "command": "npx",
      "args": ["-y", "task-master-ai@0.43.1"],
      "env": { "TASK_MASTER_TOOLS": "core" }
    }
  }
}

Task Master’s README says to enable the server with its toggle in Cursor’s MCP settings after adding it.

The commands pin task-master-ai@0.43.1, current on 2026-09-26, so a new release arrives only when someone bumps it. Task Master calls its own model to parse PRDs; point it at the Claude Code CLI you are signed in to by saying “Change the main model to claude-code/sonnet” in chat (the README’s example). If you use a provider key instead, put it in the project’s .env, never in the MCP command line.

Run the workflow

1. Write the PRD with a brainstorm first. CCPM activates on plain language. It asks about the problem, users, success criteria, constraints and scope before it writes .claude/prds/<name>.md.

   Copy-paste prompt: start a PRD with CCPM

   I want to build a user profile page: signed-in users can upload an avatar (PNG or JPEG, max 5 MB), edit a display name (3-40 characters) and a bio (max 280 characters). Only the owner sees the edit controls; everyone else sees a read-only card. Out of scope: public profile URLs, social links, account deletion. Where do we start? Ask me one question at a time, and write every acceptance criterion as an observable behaviour a test can check.

2. Turn the PRD into a task graph. Say “parse the user-profile PRD” to get .claude/epics/user-profile/epic.md, then “break down the user-profile epic”. Each task file carries acceptance criteria, an effort estimate and three fields that decide what can run in parallel: depends_on, parallel and conflicts_with. CCPM caps an epic at 10 tasks by default.

   With Task Master instead, put the PRD at .taskmaster/docs/prd.txt and run the CLI, or ask the same in chat over MCP:

   # terminal, after npm install -g task-master-ai
   task-master init
   task-master parse-prd .taskmaster/docs/prd.txt
   task-master list
   task-master next
   task-master show 1,3,5

3. Review the graph before anything reaches GitHub. This is the cheapest place to catch two agents editing the same file; the tech lead signs off here.

   Copy-paste prompt: audit the task graph before sync

   Review every task file in .claude/epics/user-profile/ before we sync to GitHub. For each pair of tasks marked parallel: true, list the files or modules both are likely to touch, and flag any pair missing a conflicts_with entry. Flag any task whose acceptance criteria cannot be checked by an automated test, any task larger than one agent session, and any depends_on cycle. Propose the corrected frontmatter as a diff, but do not apply it.

4. Sync to GitHub. Say “sync the user-profile epic to GitHub”. CCPM creates an epic issue and one sub-issue per task, renames the local task files to their issue numbers (1235.md), writes a mapping file and creates a dedicated worktree at ../epic-user-profile/. From here, issue state is project state.

5. Launch the parallel agents. Say “start working on issue 1235”. CCPM analyses the issue into independent work streams, writes <N>-analysis.md, launches one agent per stream scoped to its own files, and has each commit as Issue #N: description. This is where the wshobson specialists earn their place: with full-stack-orchestration installed, ask for its test-automator or security-auditor agent by name on the streams that need them.

6. Track without spending tokens. “standup”, “what’s blocked” and “what’s next” run CCPM’s bash scripts over .claude/epics/, so the report is deterministic and costs no model call.

7. Merge behind the gate. Say “merge the user-profile epic” only after CI is green and the review in the next section passes. CCPM runs the tests, merges and cleans up the worktree; “close issue N” updates the local file and GitHub together.

CCPM runs all streams of one issue in the same worktree and relies on conflicts_with to keep them apart. When two streams must touch a shared file, split them into separate issues, or run them in separate worktrees with claude --worktree or Codex’s /worktree; the trade-offs are on parallel agents.

How do you prove parallel agent work without reading every line?

Fan-out multiplies output, so put these gates in place before the first sync:

• Acceptance criteria as tests. Every task file’s criteria map to at least one automated test, and the reviewer prompt in step 3 rejects criteria that cannot. A green CI run against those tests is the primary evidence; the agent’s “done” is a claim.
• Required CI checks on every pull request. Type check, lint and the test suite are required status checks in branch protection, so no agent and no CCPM “merge” can land red code.
• An independent reviewer. Run a review agent that did not write the code: the plugin’s security-auditor, Claude Code’s /code-review, or Codex’s /review. The step 7 findings in 07-testing.md count only when critical and high are zero.
• Traceability. Issue #N: commit prefixes, one issue per task and the epic issue on the pull request give an auditor the chain PRD → epic → task → issue → commit without anyone writing a report.
• Protected files. Tests, CI config and dependency manifests changed by an agent get a named human reviewer through CODEOWNERS; a weakened test is the most common way parallel work goes green while wrong.
• Named sign-offs. The tech lead approves the task graph (step 3) and checkpoint 1; the feature owner approves checkpoint 2 against the acceptance criteria; CI and the reviewer agent gate the merge.

The full pattern for turning these into a pull request that carries its own proof is on the evidence bundle, and the review side on reviewing agent pull requests.

Ruflo and SuperClaude: when the heavier or older option fits

Neither is part of the team workflow above: Ruflo replaces much of your harness, and SuperClaude predates the plugin era.

Ruflo: a research-grade meta-harness

Ruflo, renamed from claude-flow (npm publishes the same version under both names), calls itself an agent meta-harness for Claude Code and Codex. Its README lists two install paths with very different surface areas. The plugin track writes no files into your workspace; the CLI track writes .claude/, .claude-flow/, CLAUDE.md, helpers and settings.

	Plugin track (lite)	CLI track (npx ruflo@latest init)
What you get	Slash commands and agent definitions per plugin	The full loop: agents, commands, skills, MCP server, hooks, daemon
MCP tool names	mcp__plugin_ruflo-core_ruflo__memory_store	bare names such as memory_store, swarm_init

Claude Code

/plugin marketplace add ruvnet/ruflo
/plugin install ruflo-core@ruflo
/plugin install ruflo-swarm@ruflo

Codex

codex plugin marketplace add ruvnet/ruflo

The marketplace lists 39 ruflo-* plugins; install the ones you need with codex plugin add <plugin>@ruflo.

Cursor

Ruflo documents no Cursor install. Use the Claude Code or Codex track.

The CLI track’s own example, from the user guide:

# terminal, in a throwaway repository inside a sandbox
npx ruflo@latest init
npx ruflo@latest agent spawn -t coder --name my-coder
npx ruflo@latest hive-mind spawn "Implement user authentication"
npx ruflo@latest agent list

Treat it as research-grade: the README mentions 314 MCP tools, and its self-learning and speed claims are vendor-reported. Run it in a disposable sandbox with no production credentials (see permissions and sandboxing), measure the session with /context before and after, and do not put it on a team’s shared configuration until you have pinned a version and reviewed what init wrote.

SuperClaude: a command menu for Claude Code

SuperClaude installs 30 /sc:* commands and a set of personas into Claude Code. It does not support Codex or Cursor.

# terminal
pipx install superclaude
superclaude install          # writes the commands to ~/.claude/commands/sc/
superclaude install --list
superclaude doctor

In a session you chain commands such as /sc:brainstorm, /sc:design, /sc:implement and /sc:test, each with free text; per-command flags are in the project’s docs/user-guide/commands.md.

SuperClaude has had no PyPI release since 4.3.0 on 2026-03-22, and the README’s /plugin install superclaude for v5 is marked “not yet available”. It is a reasonable preset menu for a single Claude Code user; for a team, a maintained plugin from the discipline packs or the orchestrator above is the safer default.

Traps in multi-agent harness installs

Package names, tool names and paths that tutorials get wrong

• SuperClaude is on PyPI, not npm. npm superclaude is a different project (Git commit tooling), and @bifrost_inc/superclaude, which the README’s npm badge still points to, stopped at 4.0.7. Install with pipx install superclaude.
• Task Master’s package is task-master-ai. npm task-master is an unrelated Grunt helper, and claude-task-master is the author’s old name, last published 2025-03-26. The CLI binary is task-master.
• claude-flow and ruflo are the same code. Old npx claude-flow@alpha tutorials still run, but their MCP tool names (swarm_init) do not exist on the plugin track (mcp__plugin_ruflo-core_ruflo__swarm_init). Pick one track per project.
• CCPM’s /pm:* commands are gone from main. They survive only on the v1 branch; the current skill is driven by plain-language requests.
• Task Master’s default loads every tool. Without TASK_MASTER_TOOLS, all 36 tools load (about 21,000 tokens, per its README). Set core or standard explicitly.

What breaks when you run parallel agents from a harness?

Symptom	Cause	Recovery
Two agents’ commits fight over the same file	Missing conflicts_with, or streams sharing one worktree	Stop both streams, keep the better commit, add conflicts_with to both tasks, and rerun one stream at a time or in separate worktrees
The orchestrator skipped checkpoint 1	In Codex, references/details.md did not load (8 KB skill cap), or the plugin’s agents are missing	Ask the agent to quote the checkpoint section; reinstall the plugin; in Codex name the agent in the prompt
sync created issues but no sub-issues	The gh-sub-issue extension is not installed	gh extension install yahsan2/gh-sub-issue, then resync; CCPM fell back to task lists in the epic body
sync fails with an authentication error	gh is not logged in, or the token cannot create issues	Run gh auth status; use a fine-grained token limited to this repository with Issues write, not an organisation-wide token
Task Master shows 0 tools enabled	The editor did not restart, or the provider is not configured	Restart the editor; set the main model to claude-code/sonnet or add a key to .env
Context is nearly full before the first prompt	Task Master in all mode, Ruflo’s MCP server, or several plugins together	/context in Claude Code; switch Task Master to core; uninstall plugins you are not using this week
An in-progress full-stack-feature run resumes the wrong feature	An old .full-stack-feature/state.json is still in the tree	Choose Start fresh, which archives the old session; commit or delete the folder after each feature
Ruflo commands from a tutorial fail with “unknown tool”	Tutorial written for the other install track	Match the tool names to your track (see the table above), or switch tracks

When a parallel run goes wrong, read git log --oneline on the epic branch before anything else. Commits are the ground truth; the standup and the agents’ summaries are claims.

Where to go next with multi-agent harnesses

Multi-agent orchestration patterns Fan-out, pipelines and planner, workers and judge: when each pays off.

Parallel agents Worktree managers and multiplexers for running several agents at once.

From issue to pull request The pipeline an issue follows once an agent picks it up.

Spec-driven frameworks compared Spec Kit, OpenSpec and BMAD, when the PRD itself needs more structure.

Autonomous loops GSD Core, Ralph loops and /goal for work that runs for hours.

Agentic development frameworks compared Every framework on one table, with ceremony and context cost.