SupremeTeam

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`.

Assesses interface performance, accessibility, frontend robustness, and component behavior across the visible product surface. Use when the user asks to review the frontend, check accessibility and performance, audit the interface behavior, or look at the component surface — even when they only say the UI "feels janky" or slow. Focuses on how the frontend behaves and performs; defers pure visual hierarchy, token adherence, and polish to `review/design-qa` and developer-facing onboarding and tooling to `review/devex-review`.

Pressure-tests the scoped surface from an adversarial viewpoint by tracing exploit paths, abuse cases, and chaining conditions. Use when the user asks to run adversarial review, pressure-test this code, think like an attacker, or look for exploit chains — even when they only ask "how would someone break this?". Focuses on chained, attacker-driven scenarios; hands single defensive flaws with no abuse sequencing to `review/security-review` and security-governance decisions to `review/cso`.

Assesses maintainability, architecture drift, standards compliance, and technical debt pressure across the scoped surface. Use when the user asks to review code quality, check maintainability, measure technical debt, or look for architecture drift — even when they only say the code "feels hard to work in". Takes the long-horizon health view; defers merge-gating of a single diff to `review/code-review`, concrete correctness defects to `review/bug-review`, and security exposure to `review/security-review`.

Assesses defensive security posture, dependency exposure, access-control risk, and unsafe data handling in the scoped surface. Use when the user asks to review security, check for vulnerabilities, audit the dependency risk, or look for data leakage — even when they only mention handling untrusted input or secrets. Covers defensive hardening of the code itself; defers attacker-driven exploit chaining to `review/mr-robot` and security governance, accepted risk, and release posture to `review/cso`.

Prevents changes inside a declared boundary until the owning contributor explicitly lifts the restriction. Use when the user asks to freeze this area, protect this path from edits, lock the boundary, or stop changes here — even when they only say "don't touch the payments code". Locks a path from edits; defers lifting that lock to `safety-guardrails/unfreeze`, a pure intent check to `safety-guardrails/careful`, and the combined intent-plus-boundary guard to `safety-guardrails/guard`.

Combines intent checks and write boundaries so risky work stays inside explicit limits until the owner decides otherwise. Use when the user asks to guard this work, turn on the safety guard, protect this area, or combine careful and freeze — even when they only ask to "lock things down while we work". Bundles both layers; use `safety-guardrails/careful` for an intent check alone, `safety-guardrails/freeze` for a path lock alone, and `safety-guardrails/unfreeze` to lift the boundary.

Automates browser interactions through a structured page-reading workflow that emphasizes observable evidence instead of selector guessing. Use when the user asks to browse this site, test the page in a browser, walk through the interface, capture browser evidence, or verify how a live flow behaves on an actual rendered surface — even when they only say "click through the app and check it". Drives an existing browser session; defers launching a visible workspace to `browser-automation/open-browser`, loading authenticated session state to `browser-automation/setup-browser-cookies`, and sharing the session with another operator to `browser-automation/pair-agent`.

Launches a visible browser workspace for guided interaction, debugging, and collaborative automation on live product surfaces. Reuses an already-available browser (installed system browser or cached Playwright browser) before installing one; attaching to a running browser over CDP is opt-in only. Use when the user asks to open the browser workspace, launch a visible browser, inspect the page live, or prepare a live session for reuse — even when they only say "pop open a browser so I can see it". Defers page interactions to `browser-automation/browse`, authenticated state to `browser-automation/setup-browser-cookies`, and session sharing to `browser-automation/pair-agent`.

Pairs a remote collaborator to a browser session using short-lived setup access and scoped session credentials. Use when the user asks to pair another agent to the browser, set up remote browser access, share a browser session safely, issue pairing access, or hand a live browser to another operator without exposing a broader environment than necessary — even when they only say "let my teammate drive this browser". Shares an existing session; defers launching the workspace to `browser-automation/open-browser`, loading authenticated state to `browser-automation/setup-browser-cookies`, and driving the page to `browser-automation/browse`.

Imports or prepares authenticated browser session state so later browser work can operate on protected surfaces safely. Use when the user asks to set up the browser session, import cookies for browser work, prepare the authenticated browser, load the browser access state, or verify that a protected page can be reached with the intended account and tenant — even when they only say "log the browser into our app". Prepares authenticated state; defers launching the workspace to `browser-automation/open-browser`, driving the page to `browser-automation/browse`, and sharing the session to `browser-automation/pair-agent`.

Implements approved scope as production code without placeholders, silent shortcuts, or unowned TODOs. Use when asked to implement approved scope, write production code, apply required fixes, or turn a reviewed change request into a gate-ready build package — including when the request is just "build it" with an approved spec in hand. Defers test authoring to `build/test-builder`, security hardening to `build/security-builder`, and root-cause analysis to `build/debugger`.

Build sub-orchestrator that runs the pipeline from approved design inputs to a production-ready build package with implementation, tests, security posture, and completeness evidence. Use when asked to implement a design, start the build pipeline, build a project, or turn a specification into code. Delegates implementation to `build/bob-the-builder`, tests to `build/test-builder`, hardening to `build/security-builder`, completeness to `build/cross-check-build-confirm`, and gate validation to `build/gatekeeper-build`.

Confirms that the build package is complete, internally consistent, and ready for downstream review without missing critical evidence. Use when the user asks to confirm build completeness, cross-check the build package, verify the implementation is complete, or prepare the build confirmation — even when they only ask "did we finish everything?". Performs the internal completeness cross-check; defers the formal advance/revise verdict to `build/gatekeeper-build` and runtime/startup health to `build/health-check`.

Isolates root causes, tests repair strategies, and returns a bounded fix path with proof that the failure mode changed. Use when the user asks to debug this failure, find the root cause, repair the broken path, or isolate the defect — even when they only paste an error and ask "why?". Targets a specific, reproduced failure inside the build phase; defers greenfield feature implementation to `build/bob-the-builder`, test authoring to `build/test-builder`, and broad multi-system incident analysis to `investigate`.

Validates build-phase deliverables, hardening evidence, and completeness claims before code work can advance. Use when the user asks to validate the build deliverable, review build phase output, check build readiness, challenge this build packet, or verify whether implementation evidence is ready for review — even when they only ask "is the build ready?". Gates the build→review boundary only; defers the other gates to `design/gatekeeper-design`, `review/gatekeeper-code`, and `gatekeeper-admiral`.

Verifies runtime health signals, startup readiness, and environmental dependencies so deployment or review does not inherit avoidable runtime surprises. Use when the user asks to run the health check, verify runtime readiness, check startup health, or validate environment health — even when they only say "does it actually run?". Focuses on runtime and environment readiness; defers automated test authoring to `build/test-builder` and build-package completeness confirmation to `build/cross-check-build-confirm`.

Hardens the implementation by checking unsafe dependencies, insecure patterns, and missing protective controls before the build advances. Use when the user asks to harden the build, review build security, check dependency risk, or prepare the security pass — even when security is only implied by handling secrets or untrusted input. Hardens code during the build phase; defers feature implementation to `build/bob-the-builder` and the independent review-phase security audit to `review/security-review`.

Builds the automated test surface that proves the implementation behaves correctly across the intended scope and key failure paths. Use when the user asks to build the test suite, cover the implementation with tests, verify the changed behavior, or add regression protection — even when they only say "add some tests". Authors the test surface; defers feature implementation to `build/bob-the-builder`, diagnosing a specific failure to `build/debugger`, and runtime/startup health to `build/health-check`.

Researches stakeholder goals, domain constraints, and requirement evidence so the design pipeline starts from a grounded problem statement. Use when the user asks to research this problem space, gather requirement evidence, analyze stakeholder needs, map the domain context, or turn a fuzzy request into evidence the design team can actually build from — even when they only hand over a vague idea. Establishes the grounded problem statement; defers turning requirements into a plan to `design/planner` and system architecture to `design/architect`.

Admiral-pipeline cross-stage gatekeeper, normally invoked by `admiral` at each boundary; if reached directly without an active Admiral handoff, hand off to `admiral` first (see routing-doctrine.md). Validates cross-stage packages and decides whether they are ready to advance between major delivery boundaries. Use when `admiral` routes a boundary package for a verdict, or the user asks to validate the handoff, check build readiness, review delivery readiness, challenge the package boundary, or verify whether a package can move from one orchestrator to the next.

Admiral-pipeline investigation component, 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 disciplined root-cause analysis across code, logs, runtime clues, and environmental evidence when the failure shape is still unclear. Use when `admiral` delegates an investigation, or the user asks to investigate this issue, find the root cause, explain why this broke, trace the failure, or narrow a messy incident down to one credible explanation.

Updates release notes, operational follow-up, and product documentation so the release leaves a usable paper trail. Use when the user asks to document the release, update the launch notes, write the release follow-up, or capture what shipped — even when they only say "write up what we just released". Produces the release paper trail; defers the actual merge-and-rollout to `release-and-deployment/land-and-deploy`, end-to-end release orchestration to `release-and-deployment/ship`, and durable deploy configuration to `release-and-deployment/setup-deploy`.

Combines merge, rollout, verification, and post-release checks into one controlled flow with rollback awareness. Use when the user asks to land and deploy this, merge and release it, ship the branch, merge then verify the rollout, or take an approved change all the way into a real environment — even when they just say "get this live". Executes the merge-to-environment flow; defers broader release orchestration and sequencing to `release-and-deployment/ship`, first-time deploy configuration to `release-and-deployment/setup-deploy`, and release notes to `release-and-deployment/document-release`.

Defines durable deployment settings and environment conventions so later rollout flows can reuse proven configuration safely. Use when the user asks to set up deployment config, prepare the release settings, persist the deployment details, or configure the deploy flow — even when they only say "get deploys set up". Establishes reusable configuration; defers executing an actual rollout to `release-and-deployment/land-and-deploy`, release orchestration to `release-and-deployment/ship`, and release notes to `release-and-deployment/document-release`.

Orchestrates release readiness, launch sequencing, verification, and follow-up actions for a controlled product release. Use when the user asks to ship this release, prepare the launch, run the release flow, or coordinate the rollout — even when they only say "let's launch". Owns end-to-end release orchestration; defers the single merge-and-deploy execution to `release-and-deployment/land-and-deploy`, durable deploy configuration to `release-and-deployment/setup-deploy`, and release notes to `release-and-deployment/document-release`.

Finds correctness defects, broken invariants, crash paths, and data corruption risks in the scoped code surface. Use when the user asks to find the bugs, review correctness, check failure paths, or look for broken assumptions — even when they only say "something is wrong here" and point at code. Focuses on deterministic correctness, not attacker-driven exploit chains (route to `review/mr-robot`), defensive-security posture (`review/security-review`), or maintainability and tech-debt pressure (`review/quality-review`).

Applies security-leadership scrutiny to the product, release, or operating model and surfaces the highest-value control gaps. Use when the review scope includes security governance, accepted risk, release posture, or executive control decisions, or when the user asks to run the security oversight pass, review this like a security chief, challenge the security posture, or stress-test the security decisions. Defers code-level vulnerability hunting to `review/security-review` and attacker-chaining to `review/mr-robot`.

Assesses visual hierarchy, token adherence, responsive behavior, and interaction polish across the rendered interface. Use when the user asks to review the visual quality, audit the design implementation, check the interface polish, or validate the visual system — even when they only say the UI "looks off". Focuses on visual fidelity against the design system; defers runtime performance, accessibility, and component robustness to `review/frontier` and developer-facing ergonomics to `review/devex-review`.

Assesses onboarding, tool ergonomics, documentation clarity, and integration friction for developer-facing surfaces. Use when the user asks to review the developer experience, audit onboarding, check the docs and tooling, or look for integration friction — even when they only say the API or SDK is "hard to get started with". Focuses on the experience of developers consuming the surface; defers end-user visual quality to `review/design-qa` and runtime frontend behavior to `review/frontier`.

Validates consolidated review packages and decides whether the review evidence is ready for delivery or needs another round. Use when the user asks to validate the review package, check review readiness, challenge this review packet, or gate the review output — even when they only ask "is this review done?". Gates the review→delivery boundary only; defers the other gates to `build/gatekeeper-build`, `design/gatekeeper-design`, and `gatekeeper-admiral`.

Adds a protective decision layer before risky operations so destructive or irreversible actions require explicit evidence and intent. Use when the user asks to be careful with this, add a safety guard, protect the risky action, or pause before destructive work — even when they only say "don't break anything". Adds an intent/confirmation check on actions; defers locking a path from edits to `safety-guardrails/freeze`, the combined intent-plus-boundary guard to `safety-guardrails/guard`, and lifting a boundary to `safety-guardrails/unfreeze`.

Clears an active protection boundary and records that the guarded area is open for changes again. Use when the user asks to unfreeze this area, remove the guard, lift the protection boundary, or allow changes again — even when they only say "we're done, open it back up". Lifts an existing boundary; defers creating a path lock to `safety-guardrails/freeze`, an intent check to `safety-guardrails/careful`, and the combined guard to `safety-guardrails/guard`.