just-vibeUI and frontend · apply by default
/ui-states
Add loading, empty, error, partial-data, disabled, and success states
Use to implement missing interface states; ui-flow connects states across a journey.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select ui-states from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv ui-states, /just-vibe ui-states and /jv:ui-states in Claude. See shortcut setup and context examples.
/just-vibe:ui-states Complete billing states for missing cards, failed renewal, and successful recovery./just-vibe:ui-states Add partial failure and retry states to a dashboard without losing filters./just-vibe:ui-states Design states with unknown payment policy; leave the policy-dependent transition unresolved.What the agent does
- Derive loading, empty, partial, stale, failed and success states from the data contract and business rules.
- Define retry, recovery and back-navigation transitions before rendering the states, and implement accessible feedback.
- Exercise each state with controlled data.
Inputs
- feature and valid loading/empty/error/partial/disabled/success conditions.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- Missing state behavior and presentation for the selected feature.
- Writes
- Apply: only the requested local changes and relevant isolated verification. Inspect/plan requests remain inspection/planning. External actions require their exact action and target in session authorization.
- Mode
- Apply; feature and valid loading/empty/error/partial/disabled/success conditions.
- 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
- State-complete UI with a state/trigger/message/action table and controlled fixture checks of each transition.
How the work is checked
- Empty data is distinguished from failed loading; a retry preserves relevant user input and context.
When to stop or clarify
- Do not invent payment/account policies. Unspecified critical transitions become questions while independent states proceed.
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
- Enumerate request/data states and transitions, including partial success and stale content.
- Method
- Preserve useful context and offer the action that can actually recover each failure; distinguish no results from unavailable data.
- Pitfall
- Replacing failed data with an empty-state message misrepresents the result and can encourage destructive user action.
- Check
- Trigger loading, empty, partial, failed and recovered states; verify user input, retry ownership and announcements survive transitions.
Situational decisions
When a partial response has useful data and an error: Preserve usable content and explain the failed portion rather than displaying a misleading empty state.
The coding agent follows this workflow using its available tools. Installation does not grant service access or guarantee an outcome. Read the compatibility notes.