From nexus-agents
Orchestrates a multi-agent development pipeline with spec, plan, tasks, and implement phases. Use for building features, fixing bugs, or executing complex plans via fan-out workers with consensus voting.
How this skill is triggered — by the user, by Claude, or both
Slash command
/nexus-agents:dev-pipelineThis skill is limited to the following tools:
The summary Claude sees in its skill listing — used to decide when to auto-load this skill
<!--
Use this skill when the user asks to build a feature, fix a bug, or implement a plan using the multi-agent development pipeline.
The run_dev_pipeline MCP tool implements a 4-phase gated workflow. Do not advance to the next phase until the current one is validated.
SPECIFY ──→ PLAN ──→ TASKS ──→ IMPLEMENT
│ │ │ │
▼ ▼ ▼ ▼
vote() vote() vote() vote() (per task)
Before producing the spec, surface assumptions explicitly:
ASSUMPTIONS I'M MAKING:
1. This runs in the existing nexus-agents MCP server (not a new process)
2. New CLI flag goes through the existing dispatch table (cli-command-catalog.ts)
3. Storage uses the existing FileAuditStorage path (not a new backend)
4. Output schema follows the Result<T, E> pattern per CLAUDE.md
→ Correct me now or I'll proceed with these.
The spec's purpose is to surface misunderstandings before code gets written. Silent assumptions are the most dangerous form of misunderstanding.
Convert the spec into a sequenced plan: which files change, in what order, with what tests. Each step references the canonical path (per CLAUDE.md "Canonical Paths") so future readers can navigate.
Break the plan into atomic tasks suitable for fan-out. Each task has:
.rules/subagent-coordination.md)Dispatch tasks per the orchestration-patterns reference (waves of 3-4, output budgets, status lines). Parent context summarizes each subagent result to 2-3 bullets — never inline raw outputs (see context-engineering skill).
Call the run_dev_pipeline MCP tool:
run_dev_pipeline({
task: "Build a health check endpoint", // Direct instructions
// OR
planFile: "/path/to/plan.md", // Read from file
repo: "owner/repo", // Track progress on GitHub issues
trackerBackend: "github", // or "gitlab" or "json"
mode: "autonomous", // "harness" = stop after decompose, return tasks
dryRun: false, // true = stop after plan+vote
simulateVotes: false, // TESTS ONLY — random output, never use for real decisions
sessionId: "my-session-id", // Enable checkpoint/resume (crash recovery)
maxVoteIterations: 3, // plan→vote loop limit
maxQaIterations: 3, // QA review loop limit
scanTarget: "/path/to/repo", // security scan directory
})
RESEARCH → research expert gathers context
PLAN → architecture expert creates plan
VOTE → consensus vote (higher_order Bayesian strategy)
↳ rejected? feedback → replan → revote (up to 3x)
PM DECOMPOSE → PM expert splits into tasks
PARALLEL IMPLEMENT → code experts work tasks concurrently
QA REVIEW → QA expert reviews each task
↳ needs_work? feedback → re-implement (up to 3x)
SECURITY SCAN → SARIF/Semgrep blocks on critical/high
SHIP ✓
The tool returns structured JSON:
{
"completed": true,
"securityPassed": true,
"voteIterations": 2,
"qaIterations": 3,
"plan": "...",
"tasks": [
{
"id": "task-1",
"title": "Add endpoint",
"status": "done",
"implementation": "export function health() { ... }",
"feedback": null
}
]
}
Autonomous mode (default): Implementations are in each task's implementation field.
implementation text from each taskHarness mode (mode: "harness"): Pipeline returns decomposed tasks — YOU implement them.
id, title, description, assignedTo — but no implementationdryRun: true first to review the plan before committing to implementationsessionId to enable crash recovery — pipeline resumes from last completed stagesimulateVotes: true is for unit tests only — its votes are random and must not be used as a fallback when adapters are missing. If no adapter is available, configure one rather than simulating.repo to get GitHub issue tracking of every pipeline stage| Excuse | Counter |
|---|---|
| "Skip the spec, just code" | The spec catches assumption mismatches before they cost a rewrite. Even a 5-line spec is better than zero. |
| "Skip the vote, I know what's right" | The vote isn't agreement-seeking; it's blind-spot detection. Cheap, fast, valuable. |
| "We don't need consensus for routine work" | Correct — use quickMode and simple_majority for routine. Skip the vote entirely only for trivial fixes. |
| "Just dispatch a giant subagent for the whole thing" | Wave-of-3-4 with bounded outputs (.rules/subagent-coordination.md). Giant subagents return giant outputs that flood parent context. |
| "I'll inline the subagent results into my context" | Summarize to 2-3 bullets per result; re-read the file if details needed. Inlining destroys parent context budget. |
simulateVotes: true for a non-test pathpnpm lint && pnpm typecheck && pnpm testnpx claudepluginhub nexus-substrate/nexus-agentsOrchestrates an adversarial plan-implement-review pipeline using native Claude Code subagents. Run after intake skills like /brainstorm produce a starting doc.
Guides developers through the full development pipeline: discover, brainstorm, plan, execute, review, and ship. Invoke when starting work on a bug, feature, improvement, or task.
Runs an orchestrator-pattern build on any codebase: decomposes goals into waves, dispatches parallel subagents, verifies between waves, and commits incrementally. For large tasks, overnight builds, or open-ended improvements.