Full Pipeline & Multi-Agent

These commands handle the full build lifecycle — from a product idea through PRD, planning, implementation, QA, and commit. They include the full pipeline orchestrator and the individual multi-agent commands it coordinates.

/mx:build

Full pipeline — discovery questions, PRD, plan, build, QA, commit & ship

/mx:build [product/feature idea] [--auto] [--skip-prd <path>] [--skip-plan <path>] [--stack <stack>]

Takes a product or feature idea and orchestrates the full mx pipeline end-to-end. Makes incremental commits at each phase so you can track progression in git log.

Flag	Effect
(none)	Ask discovery questions, then proceed through all phases with approval gates
--auto	Skip questions and gates, run fully autonomous
--skip-prd <path>	Skip PRD generation, use an existing PRD
--skip-plan <path>	Skip plan generation, use an existing plan
--stack <stack>	Pre-specify the tech stack

Pipeline phases:

1. Discovery — Funnel-style: quick yes/no direction questions → inferred context confirmation → targeted details only where uncertain
2. PRD — Problem-first product spec with User Roles & Expectations (each role gets a table of must-haves with unique IDs for QA traceability) (commit: docs(prd): ...)
3. Plan — Codebase-aware implementation plan (commit: docs(plan): ...)
4. Build — Test-first cycle (write test → confirm fails → implement → confirm passes) for every feature. Auto-selects agent team or single-agent by plan complexity. (commit: feat: ...)
5. QA — Spec conformance per role (PASS/FAIL/MISS per expectation ID), test coverage verification, structural checks, and fix cycles (commit: fix: ... if needed)

Key features:

• Funnel discovery — starts with fast yes/no questions (Web or mobile? Auth needed? Multi-user?) to narrow decisions, then infers stack and scope. Only asks open-ended questions for things it can’t figure out.
• User Roles & Expectations — the PRD defines what each role can do (e.g., “Admin can remove users”, “Customer can checkout”). QA verifies every must-have was built, per role.
• Test-first — every feature gets its test written before implementation. QA fails any feature that doesn’t have a corresponding test.
• Auto strategy selection — agent team for multi-component work (3+ independent components), single agent for focused changes.

When to use it:

• When you have an idea and want Claude to handle the entire journey
• When you want guided discovery questions before building
• When you’d otherwise run /mx:prd → /mx:plan → /mx:implement → /mx:qa → /mx:commit manually

Build vs individual commands

/mx:build is the “I trust the pipeline” command. Use it for end-to-end orchestration. Use the individual commands (/mx:prd, /mx:plan, /mx:implement) when you want more control over each step.

/mx:prd

Interactive PRD generator — problem-first, hypothesis-driven product spec

/mx:prd [feature or product idea]

Generates a Product Requirements Document starting from the problem, not the solution. It acts as a sharp product manager who thinks in hypotheses, challenges assumptions, and produces a structured spec with problem statement, user stories, acceptance criteria, and scope boundaries.

Run without arguments to start an interactive Q&A session. Pass an idea to skip straight to PRD generation.

The generated PRD is saved to .agents/prds/.

When to use it:

• When you have a rough idea but need to think through requirements before coding
• Before /mx:plan for any feature that needs scoping
• When you want to document the “what” and “why” before diving into the “how”

PRD vs Plan

/mx:prd defines what to build — problem statement, hypotheses, scope, and acceptance criteria. /mx:plan defines how to build it — implementation steps, file changes, and architecture decisions.

Typical flow: new feature that needs scoping goes through /mx:prd first, then /mx:plan. A clear bug fix or well-defined task skips straight to /mx:plan.

/mx:build-with-agent-team

Build using Claude Code Agent Teams — multiple Claude instances working in parallel

/mx:build-with-agent-team <plan-path> [num-agents]

Coordinates a build using Claude Code Agent Teams — multiple Claude instances working in parallel via tmux split panes or in-process mode. Each agent gets a specific contract (inputs, outputs, interfaces) and works independently on its portion of the plan. Agents communicate through direct messaging and a shared task list, following a contract-first approach to avoid interface divergence.

Argument	Description
<plan-path>	Path to the implementation plan (from /mx:plan or /mx:prd)
[num-agents]	Number of parallel agents to spawn (optional, auto-determined if omitted)

Prerequisites:

• Claude Code v2.1.32+
• Experimental flag enabled in ~/.claude/settings.json
• For split-pane mode: tmux or iTerm2 with the it2 CLI (optional — in-process mode works in any terminal)

Display modes:

Mode	How it works	Requirements
In-process	All teammates in your main terminal. Cycle with Shift+Down.	Any terminal
Split panes	Each teammate in its own pane. Click to interact.	tmux or iTerm2

Default is "auto" — uses split panes if inside tmux, in-process otherwise. Override with --teammate-mode in-process or set teammateMode in ~/.claude.json.

When to use it:

• For complex, multi-component features where different parts can be built in parallel
• After /mx:prd has defined the scope and /mx:plan has broken it into independent pieces
• When a single-agent workflow would take too long for the scope of work

Every team build automatically includes a dedicated QA teammate (using the mx-quality-keeper agent) that verifies completed work, routes failures back to owning agents, and enforces a 3-attempt rejection loop before escalating to the lead. The QA agent does not count toward the implementation team size.

See the Multi-Agent Team guide for the full protocol, hooks, QA agent details, task management, and troubleshooting.

/mx:qa

Comprehensive quality audit on current work

/mx:qa [--scope <path> | --full | --contracts-only]

Runs a quality audit using the mx-quality-keeper agent. It detects and runs all available quality checks (lint, type-check, tests), audits suppressions, and optionally verifies contract conformance. Produces a structured report saved to .agents/reports/.

Flag	Effect
(none)	Audit current git diff (staged + unstaged) — lint, types, tests
--scope <path>	Limit audit to a specific directory or file
--full	All checks including dependency audit and suppression audit
--contracts-only	Only check contract/interface conformance

When to use it:

• After completing work, before committing, for a thorough quality check beyond /mx:validate
• After a multi-agent team build to verify the full output
• When you want suppression and dependency audits alongside standard quality checks