design-gate
Installation
SKILL.md
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
- 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.mdwhen several tasks share a settled conclusion. Before implementation, use inherited constraints; re-route only when evidence changes the design surface. - 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.
- 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.mdto 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. - Merge. Any
revisewith a concrete, load-bearing finding makes the gate verdictrevise. Cosmetic or speculative findings are advisory. - On
revise, state the required plan changes as a short numbered list. When lenses expose a real unresolved trade-off, setverdict: revise, setdecision_required, and stop. Never callmodels-consensusfrom this skill. The user may invoke it separately when more opinions are useful.