SupremeTeam primary entry orchestrator for design, build, review, ship, investigate, checkpoint/resume, and skill or team creation. Routes every delivery-lifecycle request under one intake, one save-protocol run, and one gatekeeper. Use when the user says: run the full pipeline, ship end to end, resume from a checkpoint, design/build this project, review or audit this codebase, find the root cause, create a skill, build a team, or run Admiral. All lifecycle work enters here first; standalone utility tools run directly.
Transforms the approved plan into a system architecture with interfaces, API endpoint contracts, component boundaries, data flow, and technology rationale, and owns the frontend/UI visual design system (design interview, shadcn/ui token system, component template, preview, UI/UX spec, and adversarial design review) for user-facing surfaces. Use when the user asks to design the architecture, define system boundaries, write the architecture package, lock the component model, design the UI, build a design system, set up shadcn/ui tokens and components, produce UI/UX specs, or audit a design system.
Admiral-pipeline design sub-orchestrator, normally invoked by `admiral`; if reached directly for lifecycle work without an active Admiral handoff, hand off to `admiral` first (see routing-doctrine.md). Runs the design pipeline from initial scope to an approved design package with requirements, plans, architecture, interface contracts, and implementation guidance. Use when `admiral` delegates the design boundary, or the user asks to design this system, create the design package, start the design pipeline, or plan and architect this project.
Converts the approved design package into an implementation specification with delivery slices, dependency order, and operational constraints. Use when the user asks to prepare the implementation spec, translate design into delivery slices, write the engineering plan, or sequence the implementation details — even when they only say "how do we actually build this?". Produces the build-ready spec; defers system architecture and interface contracts to `design/architect`, the high-level delivery plan and milestones to `design/planner`, and writing the code itself to `build/bob-the-builder`.
Validates design-phase deliverables before a design package can advance to the next design activity or leave the design pipeline. Use when the user asks to validate the design deliverable, review design phase output, check design readiness, challenge this design packet, or verify whether the design package is coherent enough for build consumption — even when they only ask "is the design done?". Gates the design→build boundary specifically; defers the build→review gate to `build/gatekeeper-build`, the review→delivery gate to `review/gatekeeper-code`, and the cross-stage delivery gate to `gatekeeper-admiral`.
Turns approved requirements into a delivery plan with milestones, rollout strategy, decision gates, and explicit risk handling. Use when the user asks to plan this project, create the rollout plan, sequence the implementation work, or define delivery milestones — even when they only ask "what's our plan here?". Owns the high-level delivery plan; defers requirement gathering to `design/researcher`, system architecture and interfaces to `design/architect`, and the low-level build-ready implementation spec to `design/engineer`.
Runs the full review pipeline across correctness, readiness, maintainability, security, adversarial testing, security leadership oversight, and optional interface or developer-experience surfaces. Use when the user asks to run the full review flow, review this codebase comprehensively, audit this change before merge, or pressure-test this project — even when they only say "review the code". For a single lens, use that specialist reviewer instead; for the merge gate, use `review/gatekeeper-code`.
Evaluates merge readiness, local code quality, change risk, and clarity so the delivery decision rests on concrete evidence. Use when the user asks to review the code, check merge readiness, audit this change, or look for code quality issues — even when they just drop a diff and ask "is this good to merge?". Judges the change as submitted; defers exhaustive correctness hunting to `review/bug-review`, security exposure to `review/security-review`, and long-horizon maintainability to `review/quality-review`.