pmo-designlisted

# pmo-design ## Purpose Turn scoped requirements into flows, a source-backed visual direction, and a buildable design contract without inventing scope or approval. ## Intents | Intent | Use when | Read set | |---|---|---| | `flow` (default) | Map requirements to flow, wireframe, or acceptance wording | `PROJECT.md`, relevant `DESIGN/**` | | `visual_direction` | Establish creative/art direction, avoid generic defaults, or choose how the product should feel | see Required Inputs | | `design_system` | Turn a selected direction or existing brand into a developer contract and visual sheet | see Required Inputs | | `system_design` | Define architecture, data/API boundaries, and early Test Strategy in `DESIGN/BUILD-SPEC.md` | `PROJECT.md`, `DESIGN/BUILD-SPEC.md` | | `design_provider` | Prepare the governed Claude Design handoff, run preflight, reconcile candidate output, and record the review | `PROJECT.md`, `DESIGN/BUILD-SPEC.md`, `DESIGN/CLAUDE-DESIGN/**`, `EXTERNALIZATION.json`, `decision-log.md` | Read `docs/concepts/visual-direction.md` for creative-direction rules and `docs/concepts/design-system.md` for the artifact contract. Do not restate them here. ## Routing and Fallback 1. Route requests for creative, distinctive, premium, unconventional, art direction, visual direction, or "not generic" work to `visual_direction`, even when the user also says "design system". 2. For a new design system, consume `DESIGN/VISUAL-DIRECTION.md` when its `direction_status` is `selected