design-gate

Design Gate

Turn "which design lens applies here?" into a small, evidence-based routing decision, then apply only the selected lenses and merge their findings into one verdict. This skill is the routing authority. It does not invent a second review method or call a council.

For the workflow stage boundaries and the practical skills that follow this gate, read shared/references/workflow-stage-routing.md.

Workflow

1. Identify the stage and surfaces from the plan, Slice Contract, or changed scope. During task planning, assess shared feature decisions once and classify each task's applicability and remaining risks. Use shared/references/planning-reuse.md when several tasks share a settled conclusion. Before implementation, use inherited constraints; re-route only when evidence changes the design surface.
2. Select lenses only for an unresolved decision or changed risk. Reuse settled decisions by ID when scope, authority, assumptions, and source revisions match. A matching task surface needs no repeated lens call; classify its remaining risks and security separately. Start with up to three bounded lenses for the central risks. When another material risk needs coverage, record its scope reason and apply that bounded lens in the current role. Dispatch a specialist only when the risk needs expertise or independence the current role cannot supply, under an approved route; otherwise retain an explicit blocker. Lens count alone never requires dispatch or removes coverage. No matching row on a local change means no gate.
3. Apply each selected lens in the current coordinator or implementer as a read only procedure. An independent specialist needs a material risk or unresolved question. Before dispatch, use shared/references/model-preview.md to reuse or obtain one concrete approved route snapshot. Give it the plan or design problem, the files and boundaries in scope, and the canonical gate result defined below. This response replaces a lens's standalone brief, edit, or implementation route. The independent final code review remains a separate workflow requirement.
4. Merge. Any revise with a concrete, load-bearing finding makes the gate verdict revise. Cosmetic or speculative findings are advisory.
5. On revise, state the required plan changes as a short numbered list. When lenses expose a real unresolved trade-off, set verdict: revise, set decision_required, and stop. Never call models-consensus from this skill. The user may invoke it separately when more opinions are useful.

Routing table

Change touches	Lens skill(s)
Unresolved overall system style	macro-architecture
Business vocabulary, bounded context, or relationship between domain contexts	domain-driven-design
Service decomposition or service/data ownership	macro-architecture
Local module placement, cohesion, or dependency direction	architecture-lens
Business-logic structure inside one context (aggregates, invariants, events)	domain-driven-design
Code structure choices, extensibility, sprawling conditionals	design-patterns
Scope pressure or competing local structures with a real trade-off	architecture-lens
Module/class/API interface design — depth, information hiding, interface complexity	software-design-philosophy
Stored state, databases, queues, caches, migrations, retries, concurrency, external APIs	data-systems-coding-lens
Container/process topology of a distributed app — sidecars, ambassadors, adapters, load-balanced replicas, sharding, scatter/gather, FaaS fit, ownership election, work queues, batch workflows	distributed-systems-patterns
Event streams as a source of truth — adopting or migrating to event-driven microservices, Kafka/Pulsar/Kinesis topics, event schemas, choreography vs orchestration, CDC/outbox data liberation	distributed-systems-patterns (event-driven route), data-systems-coding-lens
The thing being built is an agent — an LLM tool-calling loop, a multi-agent pipeline, or a long-running autonomous run needing durable state, mid-run approval, or replay	agent-architecture-lens
React state placement, rendering, effects, or asynchronous behavior	advanced-react
New or reworked user-facing flow, information hierarchy, or design system	ui-ux-pro-max
Two or more competing approaches with real trade-offs	architecture-lens

Fallback row (only when no specific row above fits): no specific lens fits but the change is architecturally significant → apply architecture-lens as a Lens 1 trade-off pass (name the 2–4 characteristics in tension, the real options, and the cost of each), and apply all three or no ADR before recording it with the canonical ADR template at architecture-lens/references/adr-template.md. Do not pair this with the rows above — it is the catch-all when a change is significant yet unroutable, not a peer lens.

No row matches and the change is not architecturally significant → the change is local; return proceed with the note "no design gate required" and do not invent a review.

Output contract

Read shared/references/gate-result.md and return its canonical gate result. Preserve blocking and advisory finding IDs, status, resolution evidence, and review focus when merging or rechecking. Resolve blocking findings, required changes, and material decisions before task approval; validate the versioned record with shared/scripts/gate_contract.py. Carry security classification separately from security-gate. The implementation engine receives these constraints; it does not replay every lens.

Gotchas

1. Select each lens for a material decision or risk and bound its scope.
2. Do not let lenses edit anything; the gate is read-only.
3. Do not block on style opinions; only findings that change boundaries, data ownership, contracts, or correctness block.
4. Do not reapply the full gate after a revise fix. Reapply only the lens that raised the blocking finding.
5. Do not use a consensus panel to break a tie. The gate can identify a decision; it cannot manufacture user preference.

When a material risk or unresolved question warrants an independent specialist, give it a bounded current decision packet and source locators in a fresh context. Reuse that role context only for its own blocking finding recheck. Do not fork the full product discussion into a narrow gate. Keep every material risk covered and preserve the route approval boundary.