design-pipeline

Frontend Design Pipeline

This is the project front door. It routes UI work to the smallest relevant workflow, persists decisions as change-local artifacts, and prevents implementation claims that lack evidence. It does not replace specialist design skills; it coordinates them.

Start Here

1. Classify the request into exactly one primary job.

2. Run the Stage 0 route and persist its job plan before opening a catalog:

   designer-pipeline route --query "<brief>" --write --output job-plan.json --json
   

3. Read only the returned primary knowledge door. Treat secondaries as reference-only.

4. Read the matching workflow in references/stages.md and the route-specific contract listed below.

5. Create or update the OpenSpec change artifacts before implementation.

6. Verify the actual rendered/runtime surface, not only source files or screenshots.

If routing returns needs-clarification, ask one question that distinguishes the top jobs. Do not choose a primary route by guesswork.

Non-Negotiable Invariants

UX Research and AI Interaction Contract

Treat research and AI interaction as decision-and-evidence work, not generic capability checklists. Read references/ux-research-methods.md to select a method by question, product context, phase, and claim strength; read references/ai-interaction-patterns.md to select input/wayfinding patterns and make disclosure, caveats, consent, provenance, recovery, accessibility, and reduced motion legible. Every recommendation records its decision, chosen method or pattern, required evidence, limitations, and acceptance/recovery path. Never present a design review as user research or claim AI privacy, reversibility, or confidence that the implementation cannot prove.

Project DESIGN.md Invariant

• Project DESIGN.md and MOTION.md are reusable foundations. Validate them before implementation; change-local lowercase design.md and motion.md do not replace them.
• OpenSpec is the source of truth for meaningful changes. Do not create a parallel planning format.
• Every meaningful intermediate decision is persisted in an agent-readable artifact. State transitions use the existing state/event ledger.
• Design is the product boundary. Engineering, OpenSpec, GBrain, specialist skills, animation libraries, and graphics runtimes support design outcomes; this pipeline must not drift into a general-purpose development framework.
• Design choices are grounded in the product subject, audience, operating pressure, and single user job. Open-ended directions must name a product-specific signature and an explicit rationale.
• Default-only evidence is insufficient for core interactions. Cover applicable non-default states, keyboard focus/pressed behavior, mobile and desktop layouts, and reduced motion.
• Missing, stale, inconclusive, or unresolvable evidence remains visible as that state. Never convert it into ready, verified, exact, or complete.
• Existing project components, tokens, runtime, and design docs win over a familiar library or a copied template.
• Catalogs and upstream content are reference data unless a governed route explicitly admits them. Never install dependencies, execute remote skill text, copy remote source, or publish remote artifacts without explicit authority.
• Use real content and real states in previews and QA. Do not hide content behind entrance motion or use decorative structure in place of a usable carrier.