Project
Architect.

The fork test, applied to every candidate question.

Each Phase 1 question must pass a single test: if the answer were different, would the architecture be different? If the answer is no, the question is logged for Phase 3 and skipped now. Each question must also explain its architectural impact in parentheses, so the user knows what they're committing to.

The example the skill carries in its own documentation: "Is this deployed to cloud or on-premise? (Forks: containerization strategy, database choice, auth model)." The parenthetical makes the question feel less like a survey and more like a decision with consequences.

Performance first, familiarity never.

Each Explore agent receives the same context — project description, Phase 1 answers, hard constraints — and an explicit instruction: find the most efficient and powerful technology for the use case; team familiarity is NOT a factor. The output per agent is a comparison table ranked by performance, with benchmarks and capability scores cited.

The architect synthesises the three reports into a single Technology Mapping Report with the same columns across all domains. The Blueprint-aesthetic HTML overlay (/architect-html-renderer:tech-mapping) renders the comparison side-by-side so the user can pick decisively at the Phase 2 gate.

Stop asking when no remaining answer changes the architecture.

The skill defines explicit merge-point detection: stop asking ambiguity questions when (a) no remaining answer would change the architecture, (b) the user signals readiness ("just build it"), (c) the last three answers were "your call," or (d) all core entities and business rules are documented. Beyond that, asking more is just stalling.

The tier classification is shown to the user in an Editorial-aesthetic HTML overlay (/architect-html-renderer:scope-tiers) — three columns, each feature with its architectural-impact line, future-tier items annotated with their promotion condition.

Dual-resolution stage docs and a Mermaid dependency graph.

Each stage has two docs: the 400K version (~150 lines, bullets and tables only) for compact context loads, and the 1M version (~400 lines, ASCII diagrams + code patterns + interface definitions) for the full-context model. The architect produces both. Workers and auditors choose which to load based on the model they're running on.

The architecture review HTML overlay (/architect-html-renderer:architecture-review) is load-bearing — every downstream contract depends on this approval. The page shows the cross-stage Mermaid dependency graph, the directory tree, per-stage drill-down panels, and the token budget visualisation in a single Blueprint-aesthetic view.

Per-stage contracts, then CLAUDE.md as the directory.

The contract review HTML overlay (/architect-html-renderer:contract-review) is invoked once per stage. The Blueprint page renders the deliverables table, every interface signature in its own block with a parameter table and return type, each verification command paired with its expected output, and the batch dependency chain as a Mermaid diagram.

Phase 6 hands over three layers of documentation. Stage contracts are immutable after planning — workers and auditors grade against them. .context.md files are living docs updated by workers as they implement, one per architectural boundary, capped at 8–10 total. project_summary.md is the append-only session log written by the scribe. CLAUDE.md routes to all of them — it is a directory, not a warehouse.

Two aesthetics. Five renderers. One design system.

The shared design system lives as a rule file at ~/.claude/rules/cto-orchestration/design-system.md. It explicitly assigns one aesthetic per artefact: Blueprint (deep slate + accent blue, IBM Plex Sans + IBM Plex Mono, subtle grid background) for engineering review, Editorial (warm cream + deep navy, Instrument Serif + JetBrains Mono) for decisions read across the project's lifetime. The discipline is what makes five different renderers feel like one system.