agent product skill risk: low

StyleSeed UX Feedback States

Identifies data-dependent areas in StyleSeed components and pages, then specifies loading, empty, error, and success states for each along with reusable patterns and follow-up work…

SKILL 1 file

SKILL.md

Download

---
name: ux-feedback
description: "Add loading, empty, error, and success feedback states to StyleSeed components and pages with practical mobile-first rules."
---
# UX Feedback

## Overview

Part of [StyleSeed](https://github.com/bitjaru/styleseed), this skill ensures data-dependent UI does not stop at the happy path. It adds the four core feedback states every serious product needs: loading, empty, error, and success.

## When to Use
- Use when a component or page fetches, mutates, or depends on async data
- Use when a flow currently renders only the success path
- Use when a card, list, or page needs better state communication
- Use when the product needs clear recovery and confirmation behavior

## The Four Required States

### Loading

Use skeletons that match the final layout. Avoid spinners inside cards unless the pattern genuinely requires them. Delay skeletons slightly to avoid flashes on fast responses.

### Empty

Provide a friendly explanation and a next action. Zero values should still render meaningfully instead of disappearing.

### Error

Use plain-language failure messages and always offer recovery where possible. Localize failures to the affected card or section if the rest of the page can still work.

### Success

Use toasts or equivalent lightweight confirmation for completed actions. Add undo for reversible destructive changes.

## Output

Return:
1. The data-dependent areas identified
2. The loading, empty, error, and success states added for each one
3. Any reusable empty-state or toast patterns created
4. Follow-up work needed for analytics, retries, or accessibility

## Best Practices

- Match loading placeholders to the real layout
- Keep partial failure isolated whenever possible
- Make recovery obvious, not hidden in logs or developer tools
- Use success feedback sparingly but clearly

## Additional Resources

- [StyleSeed repository](https://github.com/bitjaru/styleseed)
- [Source skill](https://github.com/bitjaru/styleseed/blob/main/seeds/toss/.claude/skills/ux-feedback/SKILL.md)

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.

REQUIRED CONTEXT

component or page that fetches/mutates async data

OPTIONAL CONTEXT

current implementation details
existing UI code

ROLES & RULES

Match loading placeholders to the real layout
Keep partial failure isolated whenever possible
Make recovery obvious, not hidden in logs or developer tools
Use success feedback sparingly but clearly
Use this skill only when the task clearly matches the scope described above
Do not treat the output as a substitute for environment-specific validation, testing, or expert review
Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing

EXPECTED OUTPUT

Format

structured_report

Schema

numbered_list · The data-dependent areas identified, The loading, empty, error, and success states added for each one, Any reusable empty-state or toast patterns created, Follow-up work needed for analytics, retries, or accessibility

Constraints

return exactly the four numbered items listed under Output
identify data-dependent areas first
describe states added for each area
include any reusable patterns created

SUCCESS CRITERIA

Identify data-dependent areas
Add loading, empty, error, and success states for each
Create reusable empty-state or toast patterns when applicable
Note follow-up work for analytics, retries, or accessibility

CAVEATS

Missing context

Specific component or page names to analyze
Existing data-fetching patterns or libraries in use
Preferred toast / notification implementation

Ambiguities

'Delay skeletons slightly' does not specify duration or trigger condition.
'Use toasts or equivalent lightweight confirmation' does not define acceptable equivalents.
'Follow-up work needed for analytics, retries, or accessibility' does not specify depth or format of recommendations.

QUALITY

OVERALL: 0.74
CLARITY: 0.85
SPECIFICITY: 0.78
REUSABILITY: 0.62
COMPLETENESS: 0.72

IMPROVEMENT SUGGESTIONS

Add an explicit 'Input' section listing required context (component code, data sources, current UI states).
Make the Output section a strict numbered template with sub-bullets for each state.
Replace vague phrases such as 'slightly' and 'equivalent' with concrete guidance or examples.

USAGE

Copy the prompt above and paste it into your AI of choice — Claude, ChatGPT, Gemini, or anywhere else you're working. Replace any placeholder sections with your own context, then ask for the output.