dreamteam

AI agents say "done" too easily. dreamteam makes a second, independent agent prove it before anything ships, re-running your tests and rejecting fake or over-claimed passes.

Minimal in both directions: dreamteam itself is one skill, not a platform — and its producers ship the least code that fully works, never by cutting validation or security.

Same bar on a $20 plan as a $200 one: capacity sizes the run, never the verification gate.

Try it · Why · Install · Quickstart · How it works · Demo · Cost · Profiles · Reference · Dependencies · FAQ

_{Not affiliated with NVIDIA's DreamTeam, a multi-agent solver for ARC-AGI-3 environments. The shared name is a coincidence.}

Try it

After install, point it at your repo in read-only mode:

/dreamteam --profile audit "find bugs in this repo"

It assembles a review crew, reproduces every finding against your real code, and prints a report — the read-only audit profile's only artifact (Safety guardrails is honest about what enforces that). It fans out parallel specialists, so check Cost & scale before an exhaustive (--depth exhaustive) audit.

What it does

• Point it at a task or an approved plan, and it assembles a crew of specialists to do the work.
• Nothing is marked done until a second, independent agent (the Reality Checker) re-runs the tests and matches every claim to real evidence.
• One loop handles building, auditing, research, and QA. Only the crew changes.

What you notice while it runs

Once you ask for dreamteam, it stays on for the rest of that session — every later task that changes a file, or runs something against a live service, goes through the same specialists-and-review path, and one typed sentence ("stop using dreamteam this session") turns it off again. Every "done" it reports arrives with what was actually checked: the command it ran and what that command printed, or what the second, independent reviewer concluded after re-running it — and where something was not checked it says "unverified" and names what you should check yourself, instead of rounding it up to "done". A finished report stops where its handoff notes stop: at most one improvement you didn't ask for, and never a menu of them — but nothing required is held back by that, so a must-fix from the gate, an "unverified" label, or a secret you still have to set all still print.

When you tell it something is wrong, it repeats your own words back so you can confirm it understood you, keeps the still-open items on a short list for that session, hands them to every specialist it sends out afterwards, and has the second, independent reviewer work that list line by line — on every kind of run — so its pass says, for each open item, whether your reported symptom was reproduced, or that the symptom lies outside what it can reach from where it runs. On Claude Code that list is a file the bundled hook writes beside the session state, and it is deleted when the session ends — or the moment you turn dreamteam off, which discards the whole list, still-open items included; on the other five CLIs nothing is written to disk at all — the list lives in the conversation and ends with it. If you report the same problem a second time it stops re-asserting: rather than another "should be fixed now", it pauses, says what it tried and what it cannot see from where it runs — your device, your hosted build — and offers you two or three options with the cost of each. Two limits on that, both worth knowing: it only counts a report it repeated back to you first, so one it never confirmed counts toward nothing; and only Claude Code keeps that count mechanically — on the other five CLIs the pause is a rule the conductor follows from the conversation, best-effort, with no counter behind it.

And when you ask "show me what you'd do", it answers the question rather than starting the work: it prints the specialists it would use and the first step it would take, then stops. Asking it to write a plan is a different request — a plan is a real deliverable, so that one it produces and reviews like any other work.

Why dreamteam?

Most agent tools hand a task to a model and trust whatever comes back: the model reports passing tests, and sometimes they don't pass — or the passing test never ran the code under it. dreamteam is built for that gap: everything it produces goes through a verification gate, and an independent Reality Checker re-runs the evidence before anything is called done. A green suite that still passes against a deliberately broken implementation is rejected, not trusted.

It is also deliberately small — one skill you invoke per task, not a framework you build against or a platform you live in, running on six CLIs rather than one runtime. The nearest comparison, ECC, is honestly a different category: an always-on operator layer, broader and deeper than dreamteam — whereas dreamteam stays a per-task skill whose learning is confined to your project and never rewrites the skill without your sign-off.[^prior-art]

It also declares its degradation contract: most orchestrators implicitly assume top-tier models and headroom, while dreamteam writes down what a small plan changes — a smaller, more interactive run — and what it never changes: the verification bar (Cost & scale has the contract).

	Dispatches work	Gates the result	No framework to build	Cross-CLI
Plain subagent dispatch / Task tool	✓	—	✓	—
CrewAI · AutoGen · LangGraph	✓	partial (you wire it)	—	—
dreamteam	✓	✓ (mandatory, vacuity-checked)	✓	✓

Install

Prerequisites: a supported CLI (Claude Code, Codex, Gemini, CodeWhale, OpenCode, or Cursor); a git repo for build-type runs (work happens in isolated git worktrees); paid model-API usage — a run spawns several agents (Cost & scale); Node.js on PATH if you install the bundled Claude Code hooks, which are node scripts.

Three steps; install commands live here, and other sections link back.

Step 1. Install the two required dependencies. dreamteam composes existing skills rather than reinventing them.

In Claude Code:

/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace

In a terminal:

npx skills add vercel-labs/skills --skill find-skills

• superpowers provides brainstorming, writing-plans, using-git-worktrees, verification-before-completion, and finishing-a-development-branch (github.com/obra/superpowers).
• find-skills, from the Vercel skills CLI (skills.sh · github.com/vercel-labs/skills), discovers and installs other skills and backs the advisory recommender.

A missing dependency warns but never blocks — dreamteam substitutes or flags it at runtime — but any path needing it stays dark until installed. The check also lists a third, recommended item, ui-ux-pro-max (composed by the ux-designer / design roles); Dependencies has the full picture, including the optional ai-research skills.

Step 2. Install dreamteam. Clone this repo and run the installer for your OS from its root. It installs into every Claude Code profile under your home directory — CLAUDE_CONFIG_DIR plus each ~/.claude* directory that holds a settings.json or a skills/ folder (the list is printed) — publishing skills/dreamteam/ to <profile>/skills/dreamteam/ as a skills-directory plugin: the folder carries .claude-plugin/plugin.json, hooks/, agents/ and vendor/, so Claude Code 2.1.157+ loads it as dreamteam@skills-dir with the bundled hooks and the 21 specialist agents registered, no marketplace step. Claude Code registers a plugin's agents from a flat agents/ directory in the plugin root, so that — not vendor/, and not a plugin.json key — is what the installer publishes; vendor/ ships beside it as the upstream-tracking source those files are copied from. Verified on Claude Code 2.1.246: after the install, claude plugin details dreamteam reports Agents (21) and one hook entry per registration in the bundled hooks/hooks.json — six of them across five scripts, itemised in Safety guardrails (and Skills (0) — on this path the skill itself loads from the profile's skills/ folder, not as a plugin component). On an older harness the hooks are merged into that profile's settings.json instead, with the install path in place of ${CLAUDE_PLUGIN_ROOT}, and no agents are registered — casts then fall back to the agents you already have. It validates every profile's settings.json before it writes anything, so a file it cannot parse stops the run with all your profiles untouched. Before registering, it retires any hand-wired settings.json hook entry that points at one of the bundled hook scripts (backing the file up as settings.json.bak-<timestamp>; every other setting, and any hook of your own, is kept as is), leaving one registration per profile; if a same-named dreamteam plugin from a marketplace is already enabled there, that copy takes precedence and the installer says so; a re-install keeps the per-install references/learnings.md and tests/learned-scenarios.md; agent names that already exist in the profile's agents/ are listed (an agent of your own with the same name takes precedence; claude plugin details dreamteam lists the plugin's own copies, by file name). It ends with the dependency check and the step Claude Code needs to pick the plugin up: /reload-plugins in an open session, or a restart.

bash ./install.sh       # Linux / macOS
pwsh ./install.ps1      # Windows

For each profile it installs into, the installer also prints that profile's always-on context: the byte size of its CLAUDE.md plus the files named by that file's @ import lines. It reads those lines one level down and never follows imports inside the imported files, so the figure is a floor rather than a full transitive total, and an import it can't find is listed by name and counted as nothing. Past 20,000 bytes it adds a warning with the reason the number matters — every agent dreamteam dispatches re-reads those files before it starts, so whatever sits there is paid for once per dispatch — and the recipe: scope the framework imports in the interactive profile's CLAUDE.md to what agents actually need, or move them behind a project CLAUDE.md. It is a report and never an edit — nothing in your profile is touched, a profile with no CLAUDE.md prints nothing, and a large number is not an install failure, since the install has already succeeded by the time it prints. The other five CLIs install by sync script and get no such report.

Step 3. Invoke it — the typed form is /dreamteam on every install path; plain-language invocation ("use dreamteam to add OAuth login") is unchanged — see Quickstart.

Other CLIs & the published-plugin install

dreamteam also installs from a Claude Code plugin marketplace — the same registration of the 21 specialist agents and bundled hooks as Step 2 (the enforcement one inert until armed, the one-line compact reminder on by default, per Safety guardrails), verified the same way on the same harness: on Claude Code 2.1.246 claude plugin details dreamteam reports Agents (21) and the same hook inventory on this path and on Step 2's alike. The two inventories differ in one line — Skills (2) (dreamteam and mle-workflow) here against Skills (0) on Step 2, where the skill loads from the profile's skills/ folder rather than as a plugin component and mle-workflow is not published at all. Pulled from the marketplace instead of a clone:

/plugin marketplace add adnantaufique/dreamteam
/plugin install dreamteam@dreamteam-marketplace

(Verified from a client on Claude Code 2.1.246 by registering a local checkout as the marketplace and running claude plugin install dreamteam@dreamteam-marketplace; resolving the adnantaufique/dreamteam remote over the network has not been client-tested. If it doesn't resolve, install.sh / install.ps1 always works.)

Other CLIs. The skill is CLI-agnostic — tool names, dispatch, and model tiers resolve per skills/dreamteam/references/platforms.md. Sync scripts (each has a .ps1 twin for Windows): sync-to-codex → ~/.agents/skills/dreamteam/ (+ an AGENTS.md pointer); sync-to-gemini (+ gemini-extension.json) → ~/.gemini/agents/dreamteam/; sync-to-codewhale → ~/.codewhale/skills/dreamteam/ (load via /skills); sync-to-opencode → ~/.config/opencode/skills/dreamteam/ (native skill tool); sync-to-cursor → ~/.cursor/skills/dreamteam/ (native Agent Skills). OpenCode and Cursor also natively read ~/.claude/skills, so Step 2 alone covers them — their sync scripts are only for setups that never ran the Claude installer.

Quickstart

With Install done, point dreamteam at a task or an approved plan — the slash command is shorthand, and plain language ("use dreamteam to add OAuth login") runs the same gated loop:

/dreamteam "add OAuth login to our web app"           # auto-picks the web crew, runs the gated loop
/dreamteam docs/plans/my-plan.md                      # execute an already-approved plan

Opt-in, then session-sticky: nothing runs until you invoke dreamteam — but once invoked, later artifact-producing tasks in the same session route through it too. Say "don't use dreamteam for this" to skip one task, or "stop using dreamteam this session" to turn it off (a later /dreamteam re-arms it).

Not for: a single-step task one agent handles, trivial edits, or work you haven't asked to orchestrate.

How it works

One loop, produce → gate → fix → integrate, runs across every domain. A workstream is one independently produced, independently reviewed slice of the task (a plan usually splits into several); the gate is the review panel every workstream must pass.

flowchart LR
  T["task / plan"] --> C{"Caster<br/>resolves the crew"}
  C --> P["produce<br/>dispatched specialist"]
  P --> G{"gate<br/>review + Reality Checker"}
  G -->|needs-work| F["fix"]
  F --> G
  G -->|pass| I["integrate"]
  I --> R["report"]

Three parts do the work:

• conductor — the loop you talk to: dispatches specialists, reports each verdict, never writes code itself.
• Caster — the selector: picks the crew and gives each role a cost-aware model tier (cheap → standard → capable → max, resolved to a concrete model per platform).
• Reality Checker — the always-on reviewer: re-runs the build and tests (data↔claim for research) and rejects anything it can't verify.

The three stages:

1. Caster resolves the crew. Explicit --roster/--profile/--skills wins; else a confident profile match takes the fast path; else a Caster agent reads the live agent registry and find-skills. The manifest prints before the run, one rationale line per pick.
2. The loop runs per workstream (references/loop.md): produce, gate, fix, integrate, report. Independent workstreams run concurrently, each file-mutating producer in its own git worktree; a mandatory re-anchor keeps the conductor dispatching instead of coding inline.
3. The gate checks the work (references/gate.md). A reviewer panel runs in parallel, split between static review and verification, and rejects faked or over-claimed coverage: a passing test is checked for vacuity — reasoned about always, perturbed to confirm it goes red on a broken implementation when cheap — and mocks can't stand in for the unit under test. Findings synthesize into pass, fix-then-pass, or needs-work; the fix loop is capped.

The deterministic edge cases — recommendations, audit, tier escalation, platforms, learning, the raw-idea wrapper, the flag grammar — live in Mechanics / Reference below.

What a run looks like

A run prints the crew manifest, then reports every workstream verdict with its evidence. Two moments from the transcript below (/dreamteam "add OAuth login to our web app") show the point — the gate rejecting a green-but-fake test:

Reality Checker  ✗ HIGH: refresh-token test is vacuous — still green when verify_signature()
                   is stubbed to return True (mock stands in for the unit under test)

…and the pass landing only after the fix survives perturbation:

re-verify → Reality Checker ✓ : perturbed verify_signature() → suite goes RED as expected
verdict: PASS · evidence: 17 unit + 4 integration green, non-vacuous (mutation-confirmed)

Full annotated transcript — the crew manifest, the vacuous-test rejection, a CSRF must-fix, and a tier escalation on a BLOCKED producer

$ /dreamteam "add OAuth login to our web app"

Caster → crew manifest (profile: web · platform: claude)
  planner    : writing-plans (skill)
  producers  :
    backend  → Backend Architect      capable → opus    : OAuth flow + token handling — multi-file, security-sensitive
    frontend → Frontend Developer      standard → sonnet  : login UI wiring — integration against the new endpoints
  reviewers  :
    Code Reviewer                      capable → opus    : static review + over-engineering / diff-scope check
    Reality Checker                    capable → opus    : re-runs tests; claim↔evidence; mock-integrity (always on)
    Security Engineer                  capable → opus    : added — auth/token handling on the critical path
  gate_policy : min_pass=all · max_fix_iterations=2
  workstream_strategy: sequential

Execution mode? Background subagents or the Workflow tool? [background] › background

── WS1: backend OAuth flow ──────────────────────────────────────────────
Dispatching `backend` for WS1 at capable, risk high — background subagents (session mode).
  producer → DONE: /auth/oauth routes + token exchange; 14 unit + 3 integration tests
  gate (parallel panel) → synthesizing…
    Reality Checker  ✗ HIGH: refresh-token test is vacuous — still green when verify_signature()
                       is stubbed to return True (mock stands in for the unit under test)
    Security Engineer ✗ HIGH: state param not validated on callback → CSRF on the OAuth handshake
    Code Reviewer    ✓ pass
  verdict: fix-then-pass (2 must-fixes) → re-dispatching producer with the fix list (iter 1/2)
  producer → DONE: real signature check asserted; state validated + test added
  re-verify → Reality Checker ✓ : perturbed verify_signature() → suite goes RED as expected;
                                   Security Engineer ✓ : CSRF test passes
  verdict: PASS · evidence: 17 unit + 4 integration green, non-vacuous (mutation-confirmed)
  integrate → merged branch ws1-oauth-backend; worktree cleaned

── WS2: login UI ────────────────────────────────────────────────────────
Dispatching `frontend` for WS2 at standard, risk standard — background subagents (session mode).
  producer → BLOCKED: token-refresh race needs more reasoning than this tier carries
  WS2 failed gate at standard → retrying at capable
  producer (capable) → DONE: refresh guarded; 6 component tests
  gate → Reality Checker ✓ · Code Reviewer ✓   verdict: PASS · evidence: 6 component tests green
  integrate → merged branch ws2-login-ui; worktree cleaned

Run complete · 2/2 workstreams integrated.
Retro → learning persisted: "web+auth → add Security Engineer by default; assert non-vacuous
        token tests." No skill-edit deltas proposed.

Every line is a real format from the skill: the manifest (references/caster.md), the re-anchor and escalation lines (references/loop.md), the verdict and its evidence (references/gate.md). Newer runs additionally open each per-workstream report with two ordinary-language lines — what changed, and what was checked — before any dreamteam vocabulary, announce each gate panel by name and say whether its reviewers ran in parallel or, where they could not, why not, print a gate: line naming the verdict and what was re-run directly after every verdict, gloss each verdict in one plain-language sentence, and close the user-facing report with handoff notes naming what still needs a human (references/loop.md §Report and §Conductor economy) — the transcript predates those lines.

Once the handoff notes close the user-facing report, a completed run adds a run-record block for the retro to read: a per-role reliability record — the dispatches that dropped, the re-dispatches that recovered them, and each role's median and longest wall-clock — and, beside it, a set of tally lines, only the ones that apply. They are counts of what the run did, never targets to hit: among them corrections raised and confirmed, required next steps against the tail's cap of one unsolicited proposal, scope questions and over-engineering findings, the ask classes (show / go / do), per-role effort, and gate yield per risk class: how many reviewer dispatches a round spent, and the Critical+High, Medium and Low they found — the one tally the retro also accumulates into the learnings store across runs of the same project (references/loop.md §Report, references/retro.md). The correction counts are numbers on Claude Code only; on the other five CLIs that line says the corrections rode in conversation state, with no counter behind them.

Cost & scale

A run is not a single prompt: a typical task spawns the Caster, a planner, one producer per workstream, a reviewer panel (the Reality Checker plus any domain reviewers, all capable), fix-loop re-dispatches, and a post-run retro — roughly N times one prompt's tokens, minutes rather than seconds, a handful to about a dozen dispatches (more for --profile audit --depth exhaustive, which is budget-printed and confirm-gated). Counting the transcript above: 12 dispatches — four producer runs (two initial, one fix re-dispatch, one tier escalation), seven reviewer runs (a three-reviewer panel, two re-verifies, WS2's two-reviewer gate), and the retro; the crew came via the profile fast path, so no Caster-agent dispatch; and no planner dispatch either — the printed manifest casts planner : writing-plans (skill), a composed skill, not a dispatched agent (references/caster.md: a skill-planner carries no tier and is never dispatched). Beyond that, measure your own runs rather than trusting a made-up figure.

Reviewers never drop below capable, so they're the largest steady cost — but the gate is risk-proportional by default: a low-risk workstream gets the Reality Checker alone, only a high-risk one the full panel (--full-gate, --cost quality, or an explicit roster pins it everywhere). Ceremony scales the same way: a raw task meeting all three pre-work micro criteria — the whole blast radius fits one sentence, nothing new (no interface, dependency, subsystem, or behavioral contract), one producer and one workstream suffice; any doubt runs full battery — runs micro: no wrapper ritual, a dispatch-free retro, a one-screen report — while its risk-class panel stays whatever the risk demands (a one-line auth fix keeps the full high-risk gate: scale trims ceremony, never review). --effort reviewers=<lvl> is an experiment instrument, not a tuning knob — it raises reviewer reasoning effort where the platform exposes a per-dispatch lever, and whether any reviewer default ever moves is settled by the paired A/B recipe in docs/VALIDATION.md, never before it: no default effort moves in this release. To economize:

• dispatch runs in the background, so it doesn't tie up your session (OpenCode excepted — Invocation shapes)
• --cost cheap biases producers to the cheapest tier that fits
• --autonomy confirm gates spend by confirming the crew and each verdict
• --depth shallow|module and a tighter task keep fan-out small

One saving is default rather than a knob: every dispatch brief carries a run context package — the repo map (affected files and their roles, entry points, verify commands) built once per run and updated as producers report back — so each agent spends its budget on the task instead of re-exploring the repo. It carries facts only, never verdicts: reviewers still verify for themselves, re-running as deeply as the risk class buys — everything, on anything that runs on a machine, edits your configuration, or ships to users. The conductor watches its own overhead the same way — in practice its own response gaps, not agent execution, dominate a run's wall-clock — dispatching a gate's panel as one wave (as parallel as the platform and caps permit, announced truthfully), batching independent reads into one step, and digesting each agent's narrative to a ledger line while verdicts and findings travel verbatim into synthesis: time saved by deleting duplicated work, never by removing a check.

Same bar, smaller bites: a low-capacity run gets fewer concurrent dispatches, a lower backstop, and more pauses, but the gate is identical at every capacity — the same Reality Checker requirement, risk-class panels, min_pass, and evidence-and-honesty rules. The run also sizes itself to the plan powering it — dreamteam runs on anything from a $20 plan to a $200 one. A capacity profile (--capacity, default auto — read off the conducting model's own tier) remaps concurrency, the dispatch backstop, and the confirm threshold for low/standard/high plans, and on a small plan resolves the reviewer floor to the best tier the plan actually has, declared once at cast; on a below-capable conducting model a weak-conductor guard also arms (off the model itself, whatever the flag says), routing borderline calls to you instead of guessing. The honest limits: how much a run gets through in a session does differ by plan, and the guard makes a weak conductor safer, not smarter. The strongest objection is real: on a small plan the model behind the bar is weaker too — the identical gate, executed by a weaker judge. The evidence rules are what compensate: a verifying reviewer re-runs the build and tests itself, never takes the producer's word, so a weaker reviewer holding run evidence beats a stronger one trusting claims; what no rule buys back is brilliance — the rules bound how wrong a run can be, not how insightful.

Default-on caps ride underneath; Safety guardrails specifies them.

Profiles (seed set)

Profile	Producers	Gate	Workstreams
mobile-dev	Mobile App Builder (iOS · Android · cross-platform) · UI Designer (Caster may re-add a design-architect for complex mobile)	Code Reviewer, Reality Checker	sequential
web	Backend Architect · Frontend Developer · UI Designer	Code Reviewer, Reality Checker (+ Security Engineer if auth/payments)	sequential
ai-research	expand (grow the research): deep-research-agent + AI Engineer · polish (write it up): AI Engineer / Technical Writer	methodology reviewer, Reality Checker	parallel (expand and polish side by side)
devops	DevOps Automator	Reality Checker, Security Engineer	sequential
qa	quality-engineer + Test Results Analyzer	Reality Checker	sequential
audit (read-only)	dimension specialists as producers — bugs: Code Reviewer · Security Engineer · Performance Benchmarker · root-cause-analyst · map: Explore · Software Architect · system-architect + a synthesizer	Reality Checker (+ dimension specialists as verifiers)	parallel
ml-dev	AI Engineer / python-expert · build-error-resolver / pytorch-build-resolver (training/CUDA build-fix) (ML development, distinct from ai-research)	methodology reviewer, Reality Checker (+ Security Engineer if infra/data-sensitive)	sequential
debug	root-cause-analyst (investigate) · host code producer (fix) (reproduce-first; skips plan-writing, but lands the fix)	Reality Checker (reproduce-then-resolve: RED before / GREEN after + a regression test), Code Reviewer	sequential
operate	general-purpose (or the host's computer-use agent) (operational DO-intent; the operation is the spec — skips plan-writing; one operator drives the live service via a connected capability and delivers the artifact to the user)	Reality Checker (artifact + observed completion; inspection-based for side-effectful/paid operations)	sequential
ux-designer	UI Designer (+ ui-ux-pro-max) · deep-research-agent (redesign) · Frontend Developer (if code emitted) (design-led; a11y non-waivable)	a UX/design reviewer, an accessibility reviewer, Reality Checker (re-derives a11y evidence) (+ Code Reviewer if code emitted)	sequential
tutor	deep-research-agent (understand) · Technical Writer (explain)	Reality Checker (explanation↔source; source wins), a clarity reviewer	sequential
generic	general-purpose	Code Reviewer, Reality Checker	sequential

• --profile android is a back-compat alias for mobile-dev. audit is read-only: the report is the artifact, nothing lands in the audited tree, integrate is a no-op (Audit and review).
• Software Architect and system-architect in the audit row are two distinct bundled agents (agency-agents and SuperClaude); map mode casts both.
• Rosters and tiers are defaults: --roster overrides, and anything richer goes to the Caster agent over the live registry — a security- or architecture-sensitive producer on the critical path can be cast above its default, as the transcript's OAuth backend was (standard → capable).
• With graphify installed, audit is graph-backed: an AST code-graph built once at fan-out as navigation infra. The graph never decides a verdict — the gate still reproduces every finding against live code.

Mechanics / Reference

The flags and the deterministic edge cases behind the loop.

Invocation shapes

Beyond Quickstart: --profile ai-research splits a run into parallel workstreams in isolated worktrees; --execution pre-sets how a run executes, skipping the one-time prompt:

/dreamteam --profile ai-research "reproduce the paper's ablation and extend it to two more datasets"
/dreamteam --execution workflow "add OAuth login to our web app"    # the Workflow tool (Claude Code only)
/dreamteam --execution background "find bugs in this repo"          # background subagents (default, every CLI)
/dreamteam --cost cheap --autonomy confirm "…"                      # economize + gate every verdict

Neither execution mode ties up your session, except OpenCode: its native dispatch is synchronous in core, so a run blocks the chat unless you add a community background plugin (references/platforms.md) — the dispatch → gate → integrate contract holds either way. The Workflow tool suits many independent workstreams; --execution workflow on the other five CLIs is invalid and falls back to background subagents. With no flag, dreamteam asks once per session, defaulting to background.

Full flag grammar

/dreamteam <task | plan-ref>
      [--profile mobile-dev|web|ai-research|devops|qa|generic|audit|ml-dev|debug|operate|ux-designer|tutor]
      [--depth shallow|module|exhaustive] [--mode bugs|map] [--graph on|off|auto]
      [--roster planner=…,producers=<role>:<agent>[@<tier>][+<skill>];…,reviewers=…]
      [--skills a,b] [--autonomy auto|confirm|step] [--execution background|workflow]
      [--models …] [--cost cheap|balanced|quality] [--capacity auto|low|standard|high] [--full-gate] [--platform claude|codex|gemini|codewhale|opencode|cursor]
      [--effort reviewers=<lvl>] [--retro on|off] [--learnings <path>] [--evolve [generations=N]]
      [--repo <path>] [--branch <name>] [--parallel]

Selection and cost

• Cost-aware tiers. Each role gets the cheapest tier that fits (references/platforms.md maps tiers to concrete models); reviewers stay capable; the loop escalates a tier on a gate failure or a BLOCKED producer. Tune with --cost / --models.
• Cross-platform. All six CLIs; --platform auto-detects the host.
• Recommendations (references/recommend.md). When a best-fit skill isn't installed, the Caster surfaces advice from skills.sh (via find-skills) plus the awesome-claude-code THE_RESOURCES_TABLE.csv — it recommends, never installs. An opt-in, human-gated setup role can install one approved, pinned candidate; the gate then checks the installed identity and that the command carried no auto-confirm flag.

Audit and review

• audit profile (references/audit.md). A read-only, many-reviewer adversarial sweep — bug-finder (--mode bugs) or project map (--mode map). Dimension reviewers run as producers; the gate reproduces or refutes each candidate and drops what doesn't reproduce. --depth shallow|module|exhaustive tunes fan-out.
• Devil's advocate on unanimous (references/gate.md). One opt-in extra capable reviewer charged with refuting a unanimous pass — off by default, on for audit.
• Pre-fix refuter (references/gate.md). A must-fix that is only a prediction (a reasoned file:line, no run evidence) gets one targeted dispatch, before the first fix iteration, to run the check that settles it: hard refuting evidence drops it; no evidence leaves it standing. One evidence run — not another reviewer — beats a fix round spent on a false positive.
• Evidence at emit time (references/gate.md). No finding counts without its motivating artifact — the file:line, the failing command and output, or a reproducing case. Anything less is an unverified note, never a must-fix, until re-raised with evidence; at synthesis a refuted prediction still loses to hard evidence.
• Confidence on every finding (references/gate.md). Confidence (how certain it's real) rides alongside severity (how much it hurts), so a proven bug outranks a hunch — but it affects display order only: high severity always surfaces, the Reality Checker always reports, and whether a finding is a must-fix comes from the gate's one definition of that term — a Critical or High, a Medium the conductor promotes with a stated reason, or one of the severity-independent promotions (an in-scope security failure, an accessibility failure, faked coverage, a false simplification, a failing verify phase) — never from its confidence. Ranking down a low-signal note is allowed; burying a real one is not.
• Security method (references/security.md). When security is in scope, the reviewer can follow a stack-neutral OWASP/STRIDE checklist — secrets, dependencies and supply chain, CI/CD, the OWASP Top 10, STRIDE per component, LLM/AI surfaces, the skill supply chain — instead of whatever the cast agent happens to know. A checklist the reviewer reads, not a scanner or a new gate step; findings enter the gate like any other. (Adapted from gstack.)

Safety guardrails

Being honest about what bounds a run: on the background-subagent path (five of the six CLIs, plus Claude Code's default mode) the guards are model-compliance rules and tripwires, not a hard sandbox — nothing at the OS level halts a misbehaving agent, so the rules are written to be hard to miss and checked as the run goes. On Claude Code with the Workflow tool a real limit sits underneath, but the design doesn't lean on it.

• Recursion firewall. A dispatched agent is a leaf: it does its one briefed task and returns — never re-invoking /dreamteam, conducting, or spawning subagents. Only the conductor dispatches, so the call tree stays one level deep by identity, not by a counter; session stickiness binds the conductor alone. The firewall is stated twice on purpose: atop the skill for an agent that auto-loads it, and in every dispatch brief for one that never loads it.
• Run-wide caps, on by default with no flag. A concurrency ceiling (8, hard limit 16) serializes the excess rather than fanning wider; a cumulative dispatch backstop (60) stops the run and escalates to you rather than continuing quietly; a confirm-gate prints projected cost and waits for your OK before a large fan-out, even under --autonomy auto. The stated defaults are the high capacity row — a low- or standard-capacity run resolves them to 3/30 · 5/45 (the capacity profile, Cost & scale); the hard limit never changes. In Workflow mode a user token target adds a fourth: the harness's live remaining budget becomes a run ceiling, met by scheduling alone — serialize, shrink the remaining fan-out, stop and escalate — never by thinning the review gate.
• Execution discipline. A producer watches every shell command to completion and reads its output and exit status before moving on — an unobserved command is not evidence. Long-running work gets a bounded, timed wait, then a check; past the bound, kill and retry once, or report the hang and continue with what it has. A discipline the model follows, not something the harness enforces.
• Optional hard enforcement (Claude Code). PreToolUse hooks fire inside dispatched subagents too (a leaf's tool calls carry a non-null agent id; the conductor's don't), so an opt-in, off-by-default hook — hooks/dreamteam-run-policy.js, armed by DREAMTEAM_ENFORCE=1 — turns two prose guards into real blocks: a leaf trying to dispatch or re-invoke /dreamteam is denied, and the conductor is hard-capped at max_total_dispatches — at the hook's own threshold (default 60; it doesn't read the capacity profile), so on a low- or standard-capacity run the armed layer sits looser beneath the prose cap, fail-safe in direction — set DREAMTEAM_MAX_TOTAL_DISPATCHES to align it with a lower capacity row. Fail-open (any parse or IO error allows — it can't block a legitimate call) and Claude-Code-only: prose stays the default everywhere, the only layer on the other five CLIs — and the confirm-gate and shell-timeout discipline stay prose on Claude Code too. Both install paths wire it (still inert until armed): the marketplace plugin and install.sh / install.ps1 register hooks/hooks.json through the dreamteam@skills-dir plugin, or merge it into settings.json on a harness older than 2.1.157; arm it with "env": { "DREAMTEAM_ENFORCE": "1" } in settings.json. Knobs: DREAMTEAM_MAX_TOTAL_DISPATCHES (default 60), DREAMTEAM_RUN_TTL_MS (stale-run reset, default 12h). A third check rides in the same script and is the only one that speaks while enforcement is off — cast conformance. The conductor prints a crew before it dispatches (a role, the agent that will play it, the tier it will run on) and writes that same cast to the session's state directory — which the stickiness hook names for it, in the line that hook injects on every armed turn — one line per role, role|agent|tier. Every dispatch is then compared against it. Which role a dispatch is playing is read from the call's own role: label, never inferred from the brief's prose: a brief that merely mentions another role is not a dispatch of that role, and dreamteam's standing preamble mentions several. Against that role's row, a divergence is an agent that is not the row's agent, or — where the row declared a tier — a call carrying no model at all, in which case the leaf silently inherits the conductor's own top tier. A byte-identical dispatch is never a divergence, and a row with no tier has no tier to have been dropped. Armed, it is denied with both sides named (manifest says <agent>@<tier>, dispatch passed <agent>@<none>); unarmed, the same sentence is emitted as context, so a mismatch shows up in the transcript instead of hiding in a call nobody sees. It compares identity by shape, so Code Reviewer and code-reviewer are one agent and punctuation is never a divergence. Every other path allows silently — no cast file, an unreadable or unparsable one, a dispatch with no role label, or a role the cast doesn't name: the check exists to catch a mismatch, never to require a cast. A second, advisory hook rides alongside: after a compaction (SessionStart, matcher compact), hooks/dreamteam-compact-rearm.js injects one conditional line reminding the conductor to re-read the skill from disk and re-anchor before the next artifact task (the compaction re-arm — a compaction summarizes the skill's rules away, so the conductor re-hydrates from the file). It is on by default — it never blocks anything and fires only on compact events — fail-open like the deny hook, and silenced by DREAMTEAM_NO_COMPACT_REMINDER=1; the deny layer stays opt-in because it can refuse tool calls.
• Prompt-time stickiness reminder (Claude Code only — default ON, silenceable). A third bundled hook, hooks/dreamteam-stickiness.js, carries the skill's session-stickiness rule mechanically, where prose alone decays as a session grows long: it runs on every prompt (UserPromptSubmit) and on a typed /dreamteam (UserPromptExpansion), costing one short-lived node process per prompt. It arms on /dreamteam or on an instruction to use dreamteam — "use / using / run / with / via / through / invoke / launch / load / start / kick off / switch to dreamteam", or "dreamteam it" — and from then on injects one reminder line per turn — artifact/operate task → dispatch, size doubt → dispatch; show/explain asks → answer, never dispatch — pointing at the skill's carve-out rule rather than restating it. Arming demands an unambiguous affirmative, and every ambiguity resolves to silence, because the two mistakes are not symmetric: a wrong arm writes session state and then injects a directive into every later turn until you notice and turn it off, while a wrong non-arm costs you one /dreamteam. So the hook finds the sentence that names dreamteam, and any negation signal anywhere in it — not, n't, no, never, none, cannot, stop, skip, without, avoid, refrain, forget, "instead of", "decided against", or a separable "turn/hold/hands … off" and "leave … out" — means it does not arm: one prompt skipped in an armed session, nothing at all in a session that was never armed. The signal never has to sit next to a verb or next to the name, which is what makes "we won't be using dreamteam today" or "refrain from using dreamteam" an opt-out rather than an arm. "do this one directly" is the same one-prompt opt-out, and the same sentence with "this session" in it — "stop using dreamteam this session" — turns the hook off until the next arm phrase. That conservatism has a real, bounded cost: a negation that does not govern dreamteam still blocks the arm when it shares the sentence ("I'm not sure, use dreamteam here"), and the remedy is one keystroke — a typed /dreamteam arms unconditionally, ahead of every prompt-text rule, because a typed command is not prompt analysis. Only a typed statement arms: a question ("should we use dreamteam?"), a pasted code fence, a path like /dreamteam-plugin/hooks and a possessive ("dreamteam's tests") never arm a session — and a question that carries a negation is read as the opt-out it is. Each state change is announced once at the top of the injected text (dreamteam: armed … / disarmed / skipping this task), and the arm line asks for the skill itself to be loaded first. Arming also writes the run marker the enforcement hook reads, so max_total_dispatches binds in a session started by typing /dreamteam — a path that never produces a Skill tool call; a typed /dreamteam starts a fresh budget, a conversational arm phrase mid-run does not. Advisory only — it never blocks a prompt — fail-open (any parse or IO error → exit 0, no output), never delivered to a dispatched leaf, and silenced by DREAMTEAM_NO_STICKINESS_REMINDER=1. State lives per session in <tmpdir>/dreamteam-hooks/session-<session id>/ (the root carries your user id where the platform has one, since one temp directory can be shared by several users) — keyed by session id only, never by directory and never expiring mid-session; directories and files are created for your user alone, a state path that is not a real file or directory you own is refused rather than written through, and both kinds of state under that root — the session directories, and the per-working-directory run markers beside them — are garbage-collected once idle for more than 7 days. The corrections ledger rides in the same hook. A prompt that reads as a correction — no, · wrong · not true · I told you · again · you already · that's not · didn't · false · you said · still · same mistake · not what I — appends a candidate line to corrections.txt beside the stickiness state, carrying your own words (at most fifteen of them, never a paraphrase), and injects one line asking for it to be confirmed or dismissed before any fix. A candidate is not a fact: that lexicon catches an instruction or a question about as often as it catches a correction, which is exactly why the conductor has to confirm it visibly — recorded correction: … — or you say it wasn't one — not a correction: …. A confirmed line leaves the way it arrived, by a visible line: closed correction: …, printed only on your word that the symptom is gone, never on a green gate. Those three lines are the whole vocabulary, and only the Stop hook below writes any of them — without the third, an open line would ride every turn for the rest of the session. From then on the open lines ride with the reminder every turn (at most five, newest first, with their repeat counts), which is the one position in context that doesn't decay as a session grows. The hook keeps the count, never the model: each open line's repeats is recomputed every turn as the number of later reports sharing at least two content words with it, over a fixed stopword list — coarser than a per-session frequency filter, and said so. A re-send is not a second report, so a prompt that is a prefix of a recent one writes nothing. What is stored is bounded and stated plainly: those fifteen words, and the last two prompts truncated to 512 characters for that re-send test alone. It never leaves the session, and the session-end hook deletes all of it. Turning the hook off deletes it sooner, and this is the part to know before you use it: the disarm sentence removes corrections.txt in the same turn — open and confirmed rows together, with no prompt and no summary — because the file only serves an armed session, and switching dreamteam off should not be the one thing that keeps your words on disk longer. Re-arm later and you start an empty ledger, counter and all; whatever was still open lives on only in the conversation.
• Claim check on stop (Claude Code only — on while the session is armed, silenceable). hooks/dreamteam-claim-check.js runs at Stop, once the conductor has finished a turn — one short-lived node process per turn — and only in a session the stickiness hook has armed. It reads that turn's final message and asks one question: if the message says verified, all tests pass, fixed, confirmed or successfully, does it also carry the evidence — checked: <command> → <result line>, gate: pass|fix-then-pass — <what was re-run>, or unverified: <what was not checked> — please check <X>? If it does, nothing happens; if it doesn't, the turn is blocked once with a reason naming those three shapes, and the conductor restates it. Be exact about what this is: the block never judges whether a claim is true. It checks that a claim carries its evidence or its unverified label — the part you can audit, and the only part a hook at this position can see. A dispatch is not an exemption: relaying a producer's "fixed" with no gate line is a bare claim like any other, and only the gate: marker — which names a verdict somebody else reached — excuses one. Two further rules live in the same script. It is the ledger's write path, parsing the visible recorded correction: … / not a correction: … lines out of that same message and moving the matching candidate to open or dismissed: the conductor's own text is the only input, the hook is the only writer, the model never edits the file. And it holds the second-time rule, which picks the reason for a block rather than adding one. Evidence is checked first and is never overridden: a message carrying checked:, gate:, unverified: or the pause marker passes even while an open correction sits at two repeats — including a claim about an unrelated workstream. What the rule does is hand a claim carrying none of those shapes the more specific reason paused — repeat #2 of an open correction, because at the second report the next move is a pause with the four-part frame (what was tried · what evidence exists · what you cannot reach · two or three options), not another assertion. A hook whose thesis is that claims carry evidence never refuses the evidence. The costs, stated rather than implied: a lexicon has false positives, and each one costs a full extra conductor turn — bounded at one block per turn, and falling toward zero as the markers get used, since a message carrying any of them is never blocked. The claim text comes from the harness's own last_assistant_message; where that field is absent the hook falls back to the transcript file, which may lag the conversation by a turn, and records which source it used in the debug log. It never fires inside a dispatched leaf (SubagentStop is deliberately not registered — a leaf's work is gated by the review panel instead), never blocks while the harness is already continuing a turn, and is fail-open on every path. Silence it with DREAMTEAM_NO_CLAIM_CHECK=1.
• Session-end cleanup (Claude Code only — on by default). hooks/dreamteam-session-end.js runs at SessionEnd, on every exit reason the harness reports (clear, resume, logout, prompt_input_exit, other), and does one thing: deletes this session's state directory, so the words you typed into the corrections ledger don't outlive the session on disk. It prints nothing and can't block anything — SessionEnd has no decision control — and swallows every error. The cost is real and worth saying out loud: a session you resume later starts with an empty ledger and an unarmed reminder, so an open correction has to be re-stated. For work on sensitive material that's the right way round. The 7-day sweep stays as the fallback for a session killed before the hook could run.

The bundled hooks at a glance. Every hook below is Claude-Code-only — none of them exists on Codex, Gemini, CodeWhale, OpenCode or Cursor, where the prose rules above are the only layer — and every one is fail-open: any parse or IO error means the session carries on as if the hook were not there.

Hook script	Event it runs on	Default	Off-switch
dreamteam-run-policy.js — run policy: leaf firewall + max_total_dispatches backstop	PreToolUse (matcher Agent|Task|Skill)	off — opt-in	leave DREAMTEAM_ENFORCE unset (arm it with =1)
dreamteam-run-policy.js — cast conformance, the one check that speaks while enforcement is off	PreToolUse (same registration)	on, advisory — one context line, never a refusal	DREAMTEAM_ENFORCE=1 turns the same line into a deny; unset keeps it advisory
dreamteam-compact-rearm.js — compaction re-arm reminder	SessionStart (matcher compact)	on	DREAMTEAM_NO_COMPACT_REMINDER=1
dreamteam-stickiness.js — session stickiness + the corrections ledger	UserPromptSubmit, and UserPromptExpansion (matcher ^(dreamteam:)?dreamteam$)	on	DREAMTEAM_NO_STICKINESS_REMINDER=1, or type "stop using dreamteam this session"
dreamteam-claim-check.js — claim check on the conductor's own completion claims	Stop	on while the session is armed	DREAMTEAM_NO_CLAIM_CHECK=1
dreamteam-session-end.js — deletes this session's state directory	SessionEnd (every exit reason)	on	none by design — the deletion is the privacy bound; drop the registration from hooks/hooks.json to opt out

Learning and lifecycle

• Learns from runs — measurably (--retro, default on). A post-run retro (references/retro.md) writes evidence-tagged learnings the Caster consults on later runs of the same project; skill self-edits are proposed and human-gated, never automatic. Learning is tracked, not just stored: a consult that sways a cast is recorded, the retro accumulates each applied learning's run outcomes against a per-profile baseline built only from runs where no learning was applied, and after three applied runs its confidence moves by exact arithmetic — a learning that never beats a still-growing baseline drops by rule (a baseline with no fresh runs holds it instead of punishing it), and one persisted at confidence ≥ 0.5 also emits a per-install test scenario the runner can execute (an advisory track record, not causal proof — there is no control arm). The retro also accumulates a per-agent scouting ledger — first-try, drop, and refuted-prediction counts the Caster uses to choose between fitting agents, advisory and never a ban. --evolve opts into a benchmark-evolution loop for ai-research (references/evolve.md).
• Wrapper (references/wrapper.md). A raw idea (rather than a plan) runs brainstorming → writing-plans → loop, keeping the human approval gates — unless the task classes micro (Cost & scale): then its one-sentence blast radius is the plan and the wrapper is skipped, never the gate.
• Autonomy. auto proposes the crew then proceeds, reporting at gates; confirm confirms the crew and each verdict; step pauses per workstream. On top of that cadence, each mid-run call is classified: Mechanical (fixed by plan or evidence — proceed), Taste (defensible either way — proceed, note the choice), or User-Challenge (changes your stated direction, or costly and hard to reverse) — which always pauses and asks, even under auto, defaulting to your choice. The report carries a decision log of these calls, followed by the handoff notes that close the user-facing report — report-only; dreamteam stays stateless across runs — the one exception is a session-scoped corrections ledger holding what you reported, never run state, deleted when the session ends or as soon as you disarm, whichever comes first — and that file exists on Claude Code only; on the other five CLIs nothing is written to disk.

Dependencies

Everything resolves or substitutes at runtime; a missing item warns rather than blocks (Install states the stays-dark caveat and holds the commands).

• Required: the superpowers plugin and find-skills (Install → Step 1 lists what each provides); find-skills also backs the recommender, alongside the awesome-claude-code THE_RESOURCES_TABLE.csv.
• Recommended: ui-ux-pro-max, composed onto UI Designer by the ux-designer profile when installed; absent, UI Designer designs natively — accessibility stays non-waivable either way.
• Agents. Cast per profile — the Profiles table names each crew. 21 specialists ship with the plugin (agency-agents, ECC, SuperClaude — MIT, provenance in THIRD_PARTY_NOTICES.md). They register from the plugin-root agents/ directory — the only place Claude Code reads plugin agents from, and it reads that directory flat: a file nested one level deeper is not registered. An agents key in plugin.json is not a second route to the same thing; it replaces the directory as the source and then registers nothing, so the manifest carries no such key. Measured on Claude Code 2.1.246 with a one-agent control plugin: the directory alone reports Agents (1), naming that same file in an agents key reports Agents (0), and naming a directory there fails claude plugin validate with agents: Invalid input. vendor/ is kept as the upstream-tracking source those files are copied from byte-for-byte, checked by the CI vendor guardrail. Both install paths register them: verified on Claude Code 2.1.246, claude plugin details dreamteam reports Agents (21) after the marketplace install and after the folder installer's dreamteam@skills-dir registration alike (a harness older than 2.1.157 gets the hooks only, and casts fall back to your own agents). Registering the crew adds roughly 1K always-on tokens per session, which claude plugin details itemises. A same-named agent in your own agents/ takes precedence over the plugin copy, and the Caster resolves names from your live agent registry, substituting or flagging what's missing. Explore and general-purpose are host built-ins.
• ai-research skills (optional): creative-thinking-for-research, brainstorming-research-ideas, literature-review, ml-paper-writing — installed the same npx skills add way as find-skills.
• Composed when installed (optional, degrade gracefully): karpathy-guidelines (every code-producing producer), superpowers:systematic-debugging (the debug investigator), architecture-reviewer (the wrapper's optional tri-review); ml-dev's mle-workflow ships bundled in skills/mle-workflow/, and loads with the marketplace install — the folder installer publishes skills/dreamteam/ only, so copy it alongside if you use that profile.
• ponytail (optional): an external enforcer of dreamteam's native minimal-code principle — the gate checks over-engineering with or without it; composed onto code producers when installed.
• graphify (optional; recommend-only, never bundled): an external AST code-graph the Caster uses as navigation infra (--graph on|off|auto), mostly for audit and codebase-heavy runs; absent, agents read the tree directly, and it never decides a verdict (github.com/safishamsi/graphify; install command in references/recommend.md).
• Recommendation sources. Beyond the bundled and required set, the Caster recommends from the upstream source (agency-agents, ECC, SuperClaude, superpowers, ui-ux-pro-max, graphify) and prints the command for you to run — it never installs anything itself (references/recommend.md).

Layout

.claude-plugin/plugin.json    # plugin manifest — identity and version only; agents/ and hooks/hooks.json are found by directory
skills/dreamteam/
  SKILL.md            # spine: invocation, flags, "you are the conductor", stickiness, autonomy
  references/
    profiles.md       # domain → crew rosters + gate + default tiers
    caster.md         # crew selection, manifest schema, tier rubric, learnings consult
    gate.md           # reviewer panel, synthesis, honesty rule, capped fix loop
    loop.md           # per-workstream produce→gate→fix→integrate, escalation, re-anchor
    wrapper.md        # full-lifecycle entry (brainstorming → writing-plans → loop)
    platforms.md      # per-CLI tool / dispatch / model-tier map
    audit.md          # the audit profile — read-only sweeps
    recommend.md      # advisory recommendations (Caster recommends, never installs)
    security.md       # OWASP/STRIDE security review method
    retro.md          # post-run learnings
    learnings.md      # the learnings store the Caster consults
    evolve.md         # benchmark evolution (opt-in, ai-research)
skills/mle-workflow/  # bundled ML-engineering skill, composed by the ml-dev profile
agents/               # the 21 specialist agents as the harness registers them (flat, plugin-root)
vendor/               # upstream-tracking source for agents/ (agency-agents · ecc · superclaude)
hooks/                # bundled hooks (hooks.json): opt-in PreToolUse enforcement + cast conformance;
                      #   default-on compact reminder, session stickiness + corrections ledger,
                      #   claim check on stop, session-end cleanup
tests/scenarios.md    # S1–S79 validation scenarios + grounding dry-runs (full specs)
tests/hooks.test.js   # unit tests for the bundled hooks (zero deps, no model calls)
tests/*.test.{js,sh,ps1}  # offline unit + installer tests (deterministic, no model calls)
docs/VALIDATION.md    # the same scenarios, one line each
THIRD_PARTY_NOTICES.md            # provenance + licenses for everything vendored
install.sh / install.ps1          # Claude Code installers: every profile, plugin registration, dependency check
install-helper.js                 # their shared settings.json edit + agent-name check
gemini-extension.json / GEMINI.md # Gemini CLI packaging
scripts/sync-to-{codex,gemini,codewhale,opencode,cursor}.*   # mirror the skill into other CLIs

Validation

Validation dispatches fresh subagents at tests/scenarios.md: 79 scenarios plus two grounding dry-runs. The subagent's behavior is the test, so re-run after any edit (install first). Coverage runs from crew selection, profiles, and the gate loop through run-level safety and resilience, cost and capacity scaling, platform wiring, the efficiency layer, and the closed learning loop — docs/VALIDATION.md lists every scenario in one line, grouped by area.

FAQ / Troubleshooting

1. The dependency check printed [ ! ] warnings. Is it broken?

No — the check is best-effort: it warns rather than blocks, and a flagged path won't fire until you install the item (Install → Step 1 has the commands). Markers: [ok bundled] ships with the plugin; [ ! ] is a missing depended-on or recommended item; [recommend-only] is optional, per profile; [built-in] Explore, general-purpose (host-resolved at runtime) never needs installing.

2. How do I cancel or abort a run?

Dispatch doesn't hold your prompt (OpenCode excepted — Invocation shapes); stop it the way you stop any background agent work: interrupt the session, or cancel the background task or Workflow. The conductor only integrates after a passing gate, so stopping mid-workstream leaves nothing half-merged. --autonomy confirm or step gives explicit stop points.

3. How much does it cost, and how do I economize?

Roughly N times a single prompt — Cost & scale has the dispatch anatomy, a counted example, and the knobs.

4. It ran inline and didn't dispatch. Is that expected?

No. The conductor dispatches every workstream to a background agent; editing files directly to produce one is drift the skill guards against (a genuinely tiny, non-workstream edit you asked for directly may be done inline, announced as such first). The flip side: once invoked, dreamteam is session-sticky — later artifact-producing tasks route through it until you say "don't use dreamteam for this" (skip one task) or "stop using dreamteam this session" (off until a later /dreamteam re-arms it).

License

Apache-2.0. See LICENSE.

[^prior-art]: dreamteam didn't invent verification-led orchestration — larger systems, ECC among them, run their own verification loops and quality gates. ECC is an always-on operator layer: dozens of agents, a large skill library, persistent memory, and learning that runs unprompted and platform-wide. dreamteam learns too (Learning and lifecycle); the difference is the shape, not whether it happens — its learning stays inside one skill and one project, skill-changing edits are proposed for your approval rather than applied, and the honesty gate is never traded away: a single opt-in skill rather than a standing platform, with a gate mandatory by construction instead of optional wiring.