name: "design-systems"
description: "Build or evolve a design system by producing a Design System Operating Pack: charter, token model (incl. depth/elevation), component inventory + roadmap, blockframe-to-component mapping, documentation plan, and governance/adoption plan. Use for design systems, component libraries, design tokens, UI kits, and pattern libraries."

Design Systems

Scope

Covers
- Creating or upgrading a design system (tokens + components + guidelines)
- Using blockframes (lo-fi, system-aware wireframes) to lock logic before hi-fi execution
- Designing a future-ready visual foundation (depth/elevation, motion, texture) without breaking consistency
- Making the system easy for non-experts to use (guardrails, examples, starter templates)
- Driving adoption + governance (contribution model, champions, release cadence)

When to use
- “We need a design system / component library and a plan to build it.”
- “Our UI is inconsistent—define tokens + components + documentation to standardize.”
- “We want to refresh our UI style (more depth/texture/motion) without chaos.”
- “We need to scale design across teams or support enterprise customers with customization.”
- “We want faster hi-fi output by locking flows in lo-fi first.”

When NOT to use
- You’re defining a brand identity or logo system (different process).
- You need user research/discovery to decide what to build.
- You only need to ship one isolated UI change (just implement it).
- You’re doing pure front-end architecture unrelated to UI consistency.

Inputs

Minimum required
- Product + surfaces: web/iOS/Android; key flows
- Current state: existing UI kit/design system (if any), design tool (e.g., Figma), code stack (if relevant)
- Goals: speed, consistency, accessibility, scalability, customization, enterprise adoption
- Constraints: timeline, team ownership, level of engineering support, compliance/a11y needs

Missing-info strategy
- Ask up to 5 questions from references/INTAKE.md, then proceed with explicit assumptions.
- If platform/stack is unknown, assume a modern web product with a component library and design tokens.
- Do not request secrets or credentials.

Outputs (deliverables)

Produce a Design System Operating Pack in Markdown (in-chat by default; write to files if requested):

1) Context snapshot (goals, constraints, success signals)
2) Design system charter (mission, scope, principles, audiences, in/out)
3) UI audit + operational blockers (what’s slowing teams down; what must standardize first)
4) Blockframe-to-component map (lo-fi flows + mapping to components/tokens)
5) Token model (taxonomy, naming rules, and initial token backlog—include elevation/depth)
6) Component inventory + roadmap (tiers, prioritization, milestones)
7) Documentation + enablement plan (non-designer-friendly, “teaches by structure”)
8) Governance + adoption plan (contribution workflow, decision rights, champions, release cadence)
9) Quality gate (checklists + rubric score) + Risks / Open questions / Next steps

Templates: references/TEMPLATES.md

Workflow (7 steps)

1) Intake + success definition (who is this for?)

• Inputs: User context; references/INTAKE.md.
• Actions: Confirm primary users of the system (designers, engineers, PMs, “non-designers”). Define success signals (cycle time, consistency, adoption, fewer UI bugs, faster onboarding).
• Outputs: Context snapshot (draft).
• Checks: Success is measurable or at least falsifiable (e.g., “80% of new screens use system components”).

2) Audit the current UI and find the operational “hook”

• Inputs: Screens/flows, existing components, pain points, enterprise needs (if any).
• Actions: Inventory inconsistencies (spacing/type/color/components), identify the operational blocker the system will remove (e.g., slow production, inconsistent UI, customization needs). Choose the first high-leverage slice.
• Outputs: UI audit + operational blockers list; initial scope slice.
• Checks: The first slice is narrow enough to ship but broad enough to set patterns.

3) Lock logic with blockframes (separate thinking from styling)

• Inputs: Key flows; current IA; constraints.
• Actions: Create or specify “blockframes” (lo-fi, system-aware wireframes). Map each block to intended components and token usage so hi-fi execution becomes faster and more consistent.
• Outputs: Blockframe-to-component map (v1).
• Checks: A reviewer can validate flow/IA without debating visual details.

4) Define the token model (make the future style changeable)

• Inputs: Brand constraints, accessibility targets, desired direction (e.g., depth/texture/motion).
• Actions: Define token taxonomy + naming; include elevation/depth and state tokens. If doing a visual refresh, design the token model so style can evolve without rewriting components.
• Outputs: Token model + token backlog (v1).
• Checks: Tokens support theming and states; accessibility constraints are addressed (contrast, focus, motion).

5) Define the component model + delivery plan

• Inputs: Audit + blockframes + token model; engineering constraints.
• Actions: Tier components (primitives → composites → patterns). Prioritize by reuse and user impact. Define milestones, owners, and acceptance criteria.
• Outputs: Component inventory + roadmap (milestones).
• Checks: Milestone 1 ships within 1–2 weeks and establishes “golden path” patterns.

6) Make it easy to use (guardrails for non-experts)

• Inputs: Target user types; common mistakes; documentation needs.
• Actions: Design documentation and component guidelines so they “teach by structure”: sensible defaults, constrained options, examples, do/don’t. Provide starter templates for common layouts.
• Outputs: Documentation + enablement plan (v1).
• Checks: A non-expert can assemble a consistent screen using templates with minimal training.

7) Governance + adoption + quality gate

• Inputs: Draft pack; stakeholder map; toolchain (Figma/Storybook/etc.).
• Actions: Define decision rights, contribution workflow, review gates, and release cadence. Create a champion/office-hours plan to drive adoption. Run references/CHECKLISTS.md and score with references/RUBRIC.md. Finalize Risks / Open questions / Next steps.
• Outputs: Final Design System Operating Pack.
• Checks: Ownership is unambiguous; adoption plan exists; quality bar is explicit and repeatable.

Quality gate (required)

• Use references/CHECKLISTS.md and references/RUBRIC.md.
• Always include: Risks, Open questions, Next steps.

Examples

See references/EXAMPLES.md.