just-vibeUI and frontend · plan by default
/ui-system
Establish typography, spacing, colors, tokens, and component conventions
Use to establish or refine shared design tokens/components; polish makes local refinements and build implements an accepted adoption.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select ui-system from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv ui-system, /just-vibe ui-system and /jv:ui-system in Claude. See shortcut setup and context examples.
/just-vibe:ui-system Plan semantic design tokens from the existing screens and brand constraints./just-vibe:ui-system Plan consolidating spacing and color tokens across light and dark settings screens./just-vibe:ui-system Plan a system from existing UI without replacing unavailable brand assets.What the agent does
- Inventory actual repeated values and component states.
- Define semantic token roles over a small coherent raw scale, and the component states they cover.
- Plan incremental adoption with representative specimens that show no visual regressions.
Inputs
- existing screens, brand constraints, reusable components, and desired consistency.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Tokens and component conventions; implementing an adoption is a separate build or polish request.
- Writes
- No source changes in inspect/plan. Save only requested planning artifacts. A separately requested repair uses the relevant implementation workflow.
- Mode
- Plan; existing screens, brand constraints, reusable components, and desired consistency.
- Prerequisites
- Target screens/flows, existing design conventions, and runnable UI or supplied references. Visual claims require actual renders; accessibility claims distinguish automated, keyboard, and assistive-technology evidence.
Expected output
- Token roles and scales for typography, spacing, color and state, a component state matrix, and a migration mapping with examples.
How the work is checked
- Tokens express meaning across components; contrast and long-content behavior remain usable in representative states.
When to stop or clarify
- Do not replace branding or add a component framework without need. Resolve competing theme requirements explicitly.
Handling missing context
- Infer
- Inspect the target flow, existing components/tokens, actual renders or supplied references and current responsive behavior.
- Assume
- Reuse established visual conventions and preserve keyboard behavior; label unrendered changes as visually unverified.
- Ask
- Ask about an unresolved interaction or visual direction only when plausible choices materially differ; do not make a missing screenshot block source inspection.
Technical guidance
- Evidence
- Inventory repeated tokens, typography, spacing, component states and existing theme contracts.
- Method
- Define semantic roles and a small consistent scale; migrate consumers incrementally with deliberate exceptions.
- Pitfall
- Renaming colors without updating focus, disabled, dark-mode or data-visualization states leaves an incomplete system.
- Check
- Render representative components in each supported theme and verify contrast, overflow and token fallback behavior.
Situational decisions
When two themes require different contrast relationships: Map semantic tokens per theme and verify components rather than applying one global color substitution.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.