architect-team

Extracts the "backend logic from frontend" portion (Stages 5+6+7) of visual-to-api-design as a standalone reusable skill. Stage 5 per-page REST returns → API_RETURNS_MAP.md. Stage 6 consolidated API design + desk-trace play-test → API_DESIGN_MAP.md. Stage 7 backend data architecture → DATA_ARCHITECTURE_MAP.md + openspec change via openspec-propose. Each stage's 3-reviewer convergence wraps in a ralph-loop with total-agreement completion-promise. Inputs: PERSONA_MAP.md + page catalog + COMPONENT_ARCHITECTURE_MAP.md (or equivalent frontend artifacts). Callers: visual-to-api-design (refactors to delegate Stage 5+ here), architect-team-pipeline Phase 0b (backend dispatch when frontend or docs are referenceable). v3.4.0.

Use when a feature needs to be driven end-to-end to tested, integrated, demonstrable production code. Spec-to-production agent team orchestration: takes a requirement ($ARGUMENTS) — EITHER a requirements folder (OpenSpec, Superpowers, or plain markdown) OR a plain-language requirement typed directly as prose; builds and validates codebase + integration maps; generates the OpenSpec plan via a 100% coverage validation loop with reuse-first design; spawns parallel Superpowers-driven agent teams for backend and frontend work with mandatory architectural review gates; reconciles parallel changes; runs Playwright user-flow tests against the development environment; and meta-loops until the entire spec is implemented.

Use when a bug needs to be fixed end-to-end faster than the full architect-team-pipeline can deliver, but with the same rigor where it matters. A sibling orchestrator playbook whose Phases B−1 through B8 mirror the main pipeline's structural points but replace the Phase 2-5 parallel-team-spawn / 6-team-review with a tight replicate → reproduce-test → propose → fix → QA-replay loop. The body documents the five non-negotiable disciplines (replicate first, reproduction IS the regression test, generalized fix not symptom patch, QA replay against the live dev environment, live-dev-by-default with production opt-in). Accepts the same two input forms as the main /architect-team — a requirements folder OR a plain-language requirement typed directly as prose.

CT6's multi-agent wrapper around the external cartographer plugin call. One cartographer run produces CODEBASE_MAP.md; 3× codebase-map-reviewer agents independently audit the result and confirm 100% coverage in parallel; targeted re-mapping iterates until all 3 reviewers return ok. Wrapped in a ralph-loop with completion-promise "CODEBASE MAP COMPLETE". Caller-configurable output path so frontend-read-only mode (Phase 0b) can route output to .architect-team/frontend-reference/<codebase-slug>/ instead of <codebase>/docs/. v3.4.0.

Use when a requirement carries a Claude Design offer — a claude.ai/design/p link and/or a claude_design MCP mention — and you need to import that design project into the pipeline as a front-end oracle. Detects the offer, fetches the WHOLE project natively through the claude_design MCP, materializes it locally path-safely, and hands it to the existing interactive-mockup oracle path. Degrades gracefully with an instruct-then-fallback to the zip/local design-input path when the MCP is unavailable, so a run never dead-ends. The deterministic detector, URL parser, materializer, and fallback planner live in scripts/claude_design/claude_design_import.py; this skill is the contract.

Use when MemPalace is installed and you are authoring or auditing a project's CLAUDE.md (or AGENTS.md). When MemPalace is present, CLAUDE.md becomes a thin POINTER document — it tells the agent WHERE to find things so context is loaded on demand, rather than CONTAINING the full context — and it stays very small. Carries two parts — standards that point to a reference DB / reference MemPalace, and customizations the user can toggle on/off. The deterministic assessor + generator live in scripts/claude_md/claude_md_efficiency.py; this skill is the contract. CONDITIONAL on MemPalace being installed — with no MemPalace, a self-contained CLAUDE.md is correct and this discipline does not apply.

Use at the END of a work session — before compacting context, before declaring work done, or when invoked via /architect-team:closeout. A double-check that reviews the changes made against the requirement and confirms the documentation has been suitably updated; if any doc in the currency inventory is lax or incomplete, it updates it itself rather than just flagging it. Fires automatically before compaction via the PreCompact hook (hooks/precompact-closeout.py), which surfaces the deterministic staleness signals from hooks/closeout_check.py. Reuses the documentation-currency discipline + the doc-updater pattern; operates from the working-tree diff so it works OUTSIDE a full pipeline run.

Use whenever a run needs BOTH backend surface work AND a frontend that visualizes that data — a full-stack build from scratch, or an integration with existing services where the frontend needs inbound surfaces. The architect's parallelism protocol: the frontend and backend agents co-design the inbound surface contract, the architect approves it, the backend IMMEDIATELY provisions the endpoint AT ITS REAL PATH serving a contract-conforming mock payload, and the frontend then builds a fully integrated interface against that LIVE endpoint while the backend replaces the mock internals underneath. Neither side waits for the other. The same protocol covers a surface that already exists but needs new attributes. Every provisioned mock is a tracked, temporary scaffold recorded in a ledger; the deterministic engine (scripts/contract/interface_contract.py) makes a run non-closable while any surface is still mock-serving, so the parallelism borrowed is always repaid.

Use when building the Phase 1 coverage map, when verifying a team's slice in Phase 3, or when running the Phase 7 master review. Defines the coverage-map.json schema, how to populate it from OpenSpec specs and source requirements, how to detect uncovered requirements, and how to attribute commits to requirements for the final report.

Use when a codebase's team knowledge about data objects (tables and fields) needs a durable, structured, git-shared home instead of only prose recall. The persistent per-user annotation store on data objects, anchored to table/table.field ids from docs/data-dictionary.json and typed with a fixed vocabulary (note, quality_flag, deprecation). The CT6 inversion is load-bearing — a FACTUAL annotation (an expected_type/claims_key/definition) is corroborated on ingest through corroborate_definition and flagged on conflict, never transcribed as truth; opinions are stored as authored but a quality_flag still travels with the served field. Per-user files never merge-conflict; the knowledge server merges annotations at query time with corroboration status; recall INFORMS but never skips a per-run gate. The engine lives in scripts/data_dictionary/annotations.py; this skill is its contract.

Use when a codebase consumes data tables/databases and you need a self-contextualizing data dictionary — given code and/or documentation that reference data, derive the data model, define every field, and record provenance + corroboration. Branches by input type (code / documentation / direct user input); recursively follows objects that mask DB connections to find table references; when context is exhausted and a database is REACHABLE, performs live inspection (schema read + ~100-row sampling) to infer grain + field meaning; produces the standard artifact DATA_DICTIONARY_MAP.md (+ data-dictionary.json sidecar) with a by-field/by-table reference map and a relational/blend map. Runs during initial codebase exploration (after codebase + integration mapping) and is kept current whenever agents do database development. The deterministic pieces live in scripts/data_dictionary/data_dictionary.py; this skill is the contract.

Use when a data-engineering ask should be driven end-to-end as a first-class lane — build the warehouse dbt models, mine the stored procedures into a data dictionary, design the Airflow pipeline — faster than the full architect-team-pipeline but with the same rigor where it matters. A sibling orchestrator playbook (like bug-fix-pipeline) whose phases D−1 through D8 reuse the main pipeline's structural points rather than duplicating them; D0 dispatches data-engineering-exploration verbatim (the lane is its third caller), D2–D6 run Phases 2–6 verbatim (the full evidence stack), and the two new disciplines are the D−1 warm-catalog-first check (query the Run A knowledge server plus its freshness verdict before a rebuild) and the D7 catalog-refresh (rebuild the dictionary, re-index the server, mine to MemPalace, leaving the catalog warm). Accepts the same two input forms as architect-team — a requirements folder OR plain-language prose typed directly.

The data-plane analog of `visual-to-api-design` — a 7-stage exploration pipeline for data engineering / data architecture asks (dbt projects / Airflow DAGs / Snowflake warehouses / Databricks lakehouses / Kafka streaming / data meshes / feature stores / data products). Stage 1 domain context (via domain-research-team with mandatory outside research on data-stack patterns) → Stage 2 conceptual data model → Stage 3 service design (tool + architecture + phenotype dispatch) → Stage 4 volume + velocity analysis → Stage 5 data security (PII / encryption / access control / regulatory) → Stage 6 MANDATORY validation + lineage + observability (per-transformation rules + aggregate + per-endpoint metrics) → Stage 7 OpenSpec authoring via openspec-propose. Each stage's 3-reviewer convergence wraps in ralph-loop with total-agreement completion-promise. Dispatched from Phase 0c of architect-team-pipeline; never invoked standalone for code generation. v3.5.0.

Use when a diagnostic or feature trace reaches data and the asset-lineage layer of the Code & Data Lineage Graph (CDLG) must be produced or consulted — the bug/feature-flow-facing per-asset lineage that records which functions read / write / modify / originate each data asset, and how each asset is populated. Produces DATA_LINEAGE_MAP.md (human view) + the asset edges (reads / writes / modifies / originates) in lineage-graph.json, keyed by the asset:// nomenclature, joined to func:// nodes. Makes data-model decomposition available in the bug-fix and feature flows (not only Phase 0c). The deterministic graph pieces live in hooks/lineage_graph.py; this skill is the asset-lineage contract that layers on top of endpoint-trace-mapping. A reuse-first layer over data-engineering-exploration Stage 2/6 — the warehouse-design layer — not a duplicate of it.

Use at the END of every completed run or piece of delivered work — fired by the close-out of all four pipelines (Phase 8 / B8 / M7 / U9, right after run-continuity mark-complete) and invocable on demand for any finished change. Produces the run's DELIVERY MANIFEST (the "bill of sale") — what problem was solved in plain speak, the testing criteria anyone can use to validate it, and (for a feature) the location of every new element with what each one does — written email-ready so it can be copied straight into a message and sent. If the user provided an example document (a prior delivery note, a company template), the manifest MATCHES ITS VOCABULARY AND LAYOUT. The deterministic engine (scripts/delivery/delivery_manifest.py) gates publishing on content completeness (required sections, per-step expected results, per-element locations, zero placeholders); the manifest embeds into the run_complete email via the notifier's plan-file flag.

Use when authoring or refreshing a frontend codebase's UX mapping AND any design artifacts are available — Figma exports, screenshot/mockup images (PNG/JPG/SVG), design tokens files, Storybook configs, brand guidelines, or a codebase `assets/` directory. Triggers - a `designs/` / `screens/` / `mockups/` folder in `$REQ_DIR`, a Figma URL referenced in proposal/design.md, a `tokens.json` / `tailwind.config.{js,ts}` / `theme.ts` / `.storybook/main.{js,ts}` in the codebase, an `assets/` or `public/images/` directory with non-trivial content, OR you are about to author Playwright tests for a UI that has a visual contract that needs codification. Skipped when no design inputs exist — the absence of a DESIGN_MAP.md is not a gap if there are no design inputs.

Use when authoring or running integration tests against a backend slice, especially during Phase 5 when verifying against a live dev API. Defines payload conventions, side-effect verification (DB / queue / file), dev-data fixture hygiene, idempotency, and the rule that the system under test runs against real dependencies — mock only what's truly external or non-deterministic.

Use when a failing test escalates back to the orchestrator via a solution requirement before spawning a Phase 2 fix team. Spawns three diagnostic-researcher agents in parallel — each independently maps the FULL code flow from test input to failing assertion, then theorizes ranked diagnostic hypotheses anchored to file-line evidence. The system-architect agent reviews all three drafts for robustness, identifies coverage gaps, sends researchers back for deeper investigation if needed, and only then produces a consolidated diagnostic plan that becomes mandatory input to the fix team brief. The fix team never starts work without an approved diagnostic plan when this skill applies.

Use when the architect-team pipeline reaches Phase 8 and is about to commit and push — the documentation the project depends on (the maps CODEBASE_MAP / ROUTE_MAP / DESIGN_MAP / INTEGRATION_MAP, plus the project README, CHANGELOG, and CLAUDE.md / AGENTS.md) must be brought current with the shipped change and then independently reviewed before the GitHub push. Also use on demand when documentation is suspected stale. Defines the documentation inventory, what "current" means for each doc, the Phase 8 update-then-audit flow, and the producer/checker split — the orchestrator updates, the system-architect independently audits.

A 3-researcher domain analysis skill with MANDATORY outside research. Reads provided inputs (a frontend codebase, documentation, or both — any combination is valid), extracts personas + objectives, and AUGMENTS with industry / market / competitor research that every researcher performs independently regardless of input completeness. Round-robin convergence + master-synthesizer produces the final map. Caller-configurable output path so the skill is reusable from intake-and-mapping (INTEGRATION_MAP.md output), visual-to-api-design Stages 1+2 (PERSONA_MAP.md output), the new Phase 0b backend dispatch (PERSONA_MAP.md output to .architect-team/frontend-reference/ when frontend_read_only). v3.4.0.

Use when authoring a spec or DESIGN_MAP from a mockup, when implementing any screen that renders values, or when reviewing shipped UI — a cross-role discipline for telling a genuine static literal (a fixed label) from sample data standing in for a dynamic, data-bound value. Classify every displayed value static vs. dynamic FROM CONTEXT (its position, its nature, the requirements/design language) — never from the literal itself, since the same string is static in one place and dynamic in another. Mandates that every dynamic value is bound to a named data source rather than shipped as the design's hardcoded sample, and requires escalation to the human when a classification is genuinely ambiguous. Rejects rationalizations like "the design says John Smith so I'll render John Smith."

Use when a feature that creates or edits entities has been implemented and you must verify that every attribute those entities expose which a user should be able to control actually has a working end-to-end editing path — UI control through state through the API into the database and back. Triggers — a "create a thing" or "edit a thing" flow exists; an entity has attributes (title, name, description, status, tags, owner, ...) and you are not certain every one a user should set is actually settable and persists; a value shows in the UI or the data model but you cannot find where the user sets it; Phase 5 cross-layer verification; an on-demand editability audit via /architect-team:editability-audit. Spawns three editability-reviewer agents that independently reason through what must be editable, argue to a converged list, route gaps as solution requirements, and re-review after fixes until all three agree the editable surface is complete.

Use when a QA agent (bug-replicator, flow-executor, integration) detects email-touching work in its slice — template files, SMTP / transactional-email client imports, or email-sending function calls. The cross-cutting email-testing discipline that uses Mailpit (a local SMTP trap, zero external dependencies) as the default capture engine. The body documents the four phases (E1 detect email surface, E2 provision Mailpit, E3 capture sent emails + classify every link by reading template source, E4 follow every link in Playwright and complete each user flow it initiates), the rule that the agent reads the template source BEFORE the send, that EVERY link in EVERY email is tested (not just the primary CTA), mandatory teardown, and the project-level design.md provider override.

Use when the endpoint-tracer agent is producing a per-endpoint internal call-trace for an in-scope endpoint subset, or when any phase needs to consult or build the Code & Data Lineage Graph (CDLG). Defines ENDPOINT_TRACE_MAP.md + lineage-graph.json, the two-layer extraction contract (intra-service LSP-first static seed + LLM-refine on ambiguity; inter-service route/contract matching reusing INTEGRATION_MAP + INTERACTION_INTUITION_MAP), the func:// / asset:// identity nomenclature, runtime-witness verification against code-path-witness.json (the trust gate), subset-on-demand + transitive freshness + the cost ceiling. The deterministic pieces live in hooks/lineage_graph.py.

Use when debugging a failure whose verification cycle is expensive — a container rebuild, an ECS / Kubernetes / Cloud Run rolling deploy, a slow CI run, a long compile, any feedback loop with a multi-minute turnaround — or when you notice you have already burned two or more deploy / rebuild cycles fixing one bug at a time. Triggers — "I'll fix this one and redeploy to see", whack-a-mole config debugging, a greenfield Docker / Vite / build / CI pipeline that has never run end-to-end, an env var or asset that is not reaching the production bundle, sequential one-fix-per-deploy loops, "the deploy is rolling, waiting to verify". Establishes that when verification is expensive you audit the entire failure pathway and batch every fix before spending a cycle, rather than hunting one root cause at a time.

Use when the route-mapper agent is producing a ROUTE_MAP.md for a frontend codebase, or when any agent needs to consult an existing route map. Defines the ROUTE_MAP.md schema, the navigation web format, route inventory + dynamic routes + modal routes + API endpoint catalog, and what "complete" means for review.

Use after a session that went badly to file a manual triage report — the user-run counterpart to the automatic issue logging (named "Logit" / "Helpdesk"). It asks for explicit consent before sending anything and asks which privacy level to apply (full shares code/data snippets, summary sends nothing identifiable, off sends nothing), captures the issues the agents could not solve on the first attempt, and produces a triage submission that follows the SAME triage process as the automatic path. The deterministic submission builder + privacy redaction + validator live in scripts/helpdesk/logit.py; this skill is the contract. Honest boundary — the actual SEND to the triage server is the server-tier (the SEC handshake + the EVAL server), not part of this in-repo plugin; the skill produces the payload + applies privacy locally.

Use when entering Phase −1 of the architect-team pipeline, when any agent needs to consult codebase or integration maps, or when checking whether existing maps need refresh. Defines codebase discovery rules, the per-codebase ralph-loop with 3 reviewers (exit string "CODEBASE MAP COMPLETE"), frontend detection that triggers the route-mapper, and the integration ralph-loop with 3 explorers + master-synthesizer (exit string "INTEGRATION MAP COMPLETE"). Handles re-entry freshness checks against git commit timestamps.

Use when a feature with UI/UX surface has been implemented and you must independently verify the shipped UI is genuine — every interactive element is real-user-flow-tested (real page.click / page.fill, not a direct API call, not a vacuous navigate-and-assert) and correctly wired, every page is the real live page rather than a placeholder, and every displayed value is correctly a static literal or a dynamic data-binding rather than hardcoded sample data. Fires at Phase 3 review-gate or Phase 5 cross-layer verification, or whenever you are not certain each control genuinely works, a route may be a placeholder, or a value may be hardcoded where it should be dynamic. The body documents the full triggers and the three-reviewer team that enumerates, classifies, traces, audits test authenticity, converges, routes gaps as solution requirements, and re-reviews after fixes.

Discovery-phase verification discipline that — for every frontend codebase in scope at Phase −1B — cross-walks ROUTE_MAP.md × DESIGN_MAP.md × INTEGRATION_MAP.md and produces an explicit per-element intuition of what action each control takes and which endpoint it likely calls, with confidence high / medium / low / unknown, evidence, and a precise ambiguity question for every low-confidence item. The end of Phase −1 fires a bulk-verify gate: every low-confidence and unknown element is presented to the user as a single numbered list (`all correct` / a list of incorrect indices / `all incorrect`), then a targeted drill-down resolves only the flagged items. The confirmed intuition map is a binding input to Phase 0 spec authoring and Phase 1 coverage criteria. The Phase −1D bulk-verify is a domain gate (the user-confirmation step IS the feature) and fires regardless of the v0.9.20 process-gates-opt-in rule.

Two-pass discovery of interactive HTML mockups as oracle artifacts. Pass 1 (observation) runs the mockup in headless Chrome and records every interactive element's observed behavior; Pass 2 (intent inference) flags semantic-vs-observed mismatches (e.g., "Logout" button routing to /dashboard) and surfaces them at the existing Phase −1D bulk-verify gate so the user-resolved intent — not the mockup's literal behavior — becomes the binding contract. Adds a 6th spec_shape to oracle-deriver, a new interaction-observer agent, an INTENT-INFERENCE mode to interaction-intuiter, a new Layer 3 tool (verify-interactions-honored), and an OPTIONAL schema v7 field.

Lane-callable lifecycle discipline for a frontend codebase's INTERACTION_INTUITION_MAP.md, with three verbs — ensure (guarantee the map exists before any Playwright test is authored, dispatching interaction-intuiter in pipeline context or running the same rubric inline with an inline bulk-verify ad hoc), grow (upsert the elements and routes a user-specified flow exercises as confirmed entries carrying source user-flow, with no bulk-verify round-trip because the user specifying the flow IS the confirmation), bug-path-upsert (record a resolved bug path with source bug-path plus regression_refs naming the covering debug-flow test and the SR or bug slug). Triggers — any lane about to author or review Playwright tests, a user handing over a concrete UX flow, a debugging lane closing out a bug. The deterministic engine lives under scripts/intuition_lifecycle/ and this skill is its contract.

Use when designing or reviewing an application that embeds an LLM agent and you need the agent's output to be guaranteed consistent and standardized. Encapsulates best-in-class output-standardization techniques (MCP-1…3) — an explicit output contract (a closed JSON Schema), a structured-output mechanism the model is FORCED to call, validation of every produced value against the contract, and retry-on-mismatch. Applies whenever an embedded agent is asked to produce something, so its outputs are reliable to parse and consume. The deterministic contract builder + validator + completeness assessor live in scripts/mcp_design/output_contract.py; this skill is the contract and the mcp-design-agent is the worker.

Use whenever a phase of the architect-team pipeline needs to query prior context or persist a newly-produced artifact to the per-workspace MemPalace store. The orchestrator and named subagents (system-architect, diagnostic-researcher, route-mapper, cartographer-flow callers) consult this skill for the canonical wake-up query at intake, the search patterns each role uses before producing output, the auto-mine rules that fire when an artifact is written (CODEBASE_MAP, ROUTE_MAP, INTEGRATION_MAP, DESIGN_MAP, RCA artifacts, diagnostic plans, solution requirements, handoffs, coverage maps, final reports), and the MCP wire-up that lets every subagent reach the 29 mempalace MCP tools.

Use when a small-to-medium feature change (≤5 acceptance criteria) needs to be driven end-to-end faster than the full /architect-team can deliver, but with auto-merge to main on green QA. A sibling orchestrator playbook to architect-team-pipeline and bug-fix-pipeline; speed comes from dropping phases and parallel-review fan-out, not a weaker model. The body documents the M0-M8 phases: a single system-architect drafts the 5-artifact OpenSpec bundle with a mandatory ## QA Guidance section, two devs implement in parallel and cross-review each other, and one mini-qa agent runs unit + integration + 1-3 narrow Playwright flows against the live dev URL. On green it auto-merges to main with a Mini-Run: <slug> trailer; on persistent red it hands the work off to the unbounded full /architect-team pipeline as a continuation (no give-up cap). Accepts the same two input forms as /architect-team — a requirements folder OR plain-language prose.

Absorb any arbitrary codebase into a new labeled phenotype — analyze it (read-only), synthesize a generalized blueprint, derive a parameterized scaffold, write + validate the phenotype.json, and index it for reuse. Use when /architect-team:absorb-phenotype is invoked, or the user asks to "absorb" / "capture" / "turn this codebase into a phenotype". The generalized, repeatable form of how the seed phenotypes were authored by hand.

Discover, match, and consume phenotypes — pre-made generalized deployable application architectures (a blueprint + a parameterized scaffold + metadata) that the pipeline proposes reuse-first or is told to use. Use when a request matches a known architecture domain (user management, config management, an AI agent/prompt layer), when the user says "use the X phenotype" or "use phenotypes", or when the architect-team pipeline reaches reuse-first design and a phenotype could seed the work.

Callable orchestrator that builds and maintains a durable, persona-grouped Playwright suite for a target frontend codebase, reached via /architect-team:playwright-suite. Ten phases — P0 target and e2e-dir resolution following the repo's own convention, P1 inventory reconciled against the suite manifest, P2 intuition-map freshness, P3 review of the existing tests by dispatching the existing checkers, P4 suite-wide gap analysis, P5 gap-fill authoring per the full playwright-user-flows discipline, P6 debug-flow registration, P7 persona grouping, P8 dev-versus-prod safety classification, P9 engine-validated manifest write plus report. Triggers — "build the Playwright suite", a project with no durable test registry, a full-integration run that needs the entire dev suite enumerated. Adds no new agents.

Use when authoring or running Playwright tests for any feature with a frontend component, especially during Phase 5 integration. Mandates a workflow that first establishes who the users are and what they are trying to achieve (escalating to the user via structured questions when intent cannot be derived from product docs/requirements), then exhaustively enumerates every link, button, form input, modal trigger, keyboard shortcut, drag target, and conditional render gate plus the API contracts each touches, then authors tests organized around user journeys (page.goto / click / fill / waitFor) that assert visible state. Rejects endpoint-only testing as a substitute for user-flow testing. Coverage verification proves every user objective, every interactive element, and every error response is exercised.

Use when the architect-team / bug-fix / ux-test pipeline receives free-text prose (not a directory of OpenSpec / Superpowers artifacts), OR when /architect-team:refine-prompt is invoked standalone. Conversationally refines the prompt with codebase-map grounding and multi-axis clarity grading (clarity / scope / acceptance / grounding / conflict / scope-fidelity), iterating with the user until satisfied, then outputs a structured refined-prompt markdown the downstream pipeline consumes. A domain gate, not a process gate — the user-confirmation step IS the deliverable; --no-refine bypasses it. The body documents the R1-R6 phases, the six grading axes, standalone-vs-pipeline mode, and the scope-fidelity domain gate per `common-pipeline-conventions` `## Scope discipline`.

Use when creating or updating a README or any top-level project document and you want the house "bitmap" aesthetic — ASCII block-letter banner, gradient section dividers, box-drawing panels and inventory grids, ASCII flowcharts, logic maps that show routing and gates, a status timeline, colored badges, and a per-project color theme. Triggers — authoring or refreshing a README, the user asks for "flair" / "colorful" / "centered" / "bitmap" / "make it look good" styling, a new plugin or project needs its README, a version bump needs the README brought current, or a project has non-trivial control flow that the README must make legible. Reference guide — provides the canvas + centering rules, the pipe-table / ASCII-graph alignment rules, the banner / divider / panel / flowchart / logic-map / timeline patterns, the GitHub-safe + ANSI color model, the preset theme palettes, the interactive theme picker, and the consistency rules.

Use when authoring or refining any OpenSpec proposal/specs/design/tasks artifact, when making architectural decisions, or when proposing a new module/file/dependency. Enforces extend-before-compose-before-reuse-before-build-new, with a mandatory Reuse Decision Log anchored in CODEBASE_MAP.md and INTEGRATION_MAP.md. Rejects rationalizations like "cleaner as a new module" or "faster to just write it fresh."

Use when running, debugging, or triaging any Playwright user-flow test or live dev-API integration test. Triggers - any test failure, a flaky test, you are about to retry a test without diagnosing it, you are about to propose a fix without an evidence trail, or you find yourself reaching for "probably" / "must be" / "seems like" / "obviously" to explain why something deviated from expected. Also use before every test run to write the per-step expectation that the failure-mode analysis will measure against. Mandatory whenever the architect-team Phase 3 review gate or Phase 5 integration loop runs tests.

Use when a codebase's structure needs an adversarially-verified restructure plan — the user asks to optimize / reorganize / restructure the directory layout, module placement, or file organization ("optimize the codebase structure", "clean up the layout", "propose a better file structure"), or /architect-team:optimize-structure is invoked. Produces a reference-closed movement plan (every file movement + every reference that must change + every forced refactor, in ordered verifiable batches) as RESTRUCTURE_PLAN.md + movements.json + an OpenSpec change — it PLANS the restructure; execution belongs to /architect-team driving the produced change.

Use when the orchestrator is dispatching teammates in Phase 2 or capturing review-gate evidence in Phase 3. Defines non-overlapping file-scope rules, plan-approval-mode triggers, direct teammate-to-teammate messaging conventions, the review-gate evidence file schema (v7 — the teammate's 17-field self-review including the 5 Verified Agent Output fields, plus an independent task-reviewer verdict), the independent task-reviewer dispatch, the teammate manifest format the SubagentStop hook reads, and escalation policy on repeated hook rejection.

Evaluate every Playwright / QA test file in a codebase and classify it `@prod-safe` (only reads — safe against ANY deployed environment including production) or `@not-prod-safe` (contains mutations — POST/PUT/PATCH/DELETE / form submits / file uploads / DB writes / external side effects). Two modes — MASS-CLASSIFY scans every test under a glob, produces a per-file report, and (with `--write-annotations`) injects the top-of-file annotation into each file; AUTO-CLASSIFY runs on every new test file written at Phase 3 review gate, gates the slice on a missing annotation, and emits a `prod-safety-classification-required` SR when ambiguous. Both modes feed the 15th Layer 3 tool `verify_test_prod_safety_classification` which gates Phase 5 — a `@not-prod-safe` test scheduled against a production URL is `prod-deployment-runs-unsafe-test`, a CRITICAL safety violation.

A passive observer team that watches when testing is happening and produces a per-run report. Generic across 3 source adapters — local test runs (pytest / playwright / npm test / vitest / jest) / CI runs (GitHub Actions / GitLab CI) / production QA + UAT (APM / log-tail). Strictly log-only — no mid-run interrupts, no auto-SR filing, no pipeline gating.

Use to reduce the token cost of agents' INTERNAL communication — inter-agent messages, scratch notes, internal reasoning summaries — by writing tersely ("talk like a caveman"), WITHOUT harming external output quality (output to users / other systems / final deliverables stays full-quality; TC-1). Provides a deterministic stdlib "caveman" compressor (drops articles / politeness / intensifiers + wordy phrases, preserves content words / identifiers / numbers / code verbatim) and documents evaluating a heavier ML token-compression package (LLMLingua-style) for developer agents while they run (TC-3). The deterministic engine lives in scripts/token_compression/caveman.py; this skill is the contract, including the hard internal-only boundary.

A persona-driven UX-test orchestrator. Takes a persona description + objectives + target site (URL or `--dev` for the project's dev environment) + credentials (env-var reference, never the secret). Maps the site (fresh or freshness-checked via `intake-and-mapping`), drafts a literal Playwright flow matching the user's request, dispatches 3 `flow-explorer` agents to propose 10-15 additional adjacent flows each, distills to a unique set, authors one `.spec.ts` per flow, dispatches 3 `flow-executor` agents to run every flow in parallel against the live target, resolves verdict disagreements via loop-until-converged convergence (no fixed cycle cap), documents bugs, and auto-routes them through the existing `bug-fix-pipeline` (v0.9.22). The capability is the structural bridge between 'human describes a persona's UX concern' and 'the bug-fix-pipeline has the work queued.' Reached via `/architect-team:ux-test`.

Use BEFORE verifying any claim — a fix, a feature, a deploy, a diagnosis — to choose HOW to verify it. Enumerates the verification venues (local run, dev environment, replay of captured artifacts, seeded fixture, production read-only checks), states what each uniquely provides, proves whether the claim depends on it, picks the cheapest faithful venue, and records the choice as a verification_plan artifact. Adds the cheaper-faithful-method-found counterpart to the stuck verdicts (cannot-verify-without-deploy / env-failure / blocked) so "I need to wait for prod" is never the reflex when a faithful cheaper method exists, and a gate that needs a live environment obliges the run to PROVIDE one rather than ask.