agentleFS
roronoazoroshao369roronoazoroshao369/vibe-coding-os/skills/checklists/frontend-state-quality/SKILL.md

frontend-state-quality

Skill1 starsChanged 5 months agoMITView on GitHub

Frontend state quality checklist for React, Vue, Svelte, stores, side effects, forms, and data fetching.

The file

We split this skill into the rules it gives an agent

4 rules. About 0 are common, 4 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈4

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Use for React, Vue, or Svelte state changes.

    line 25
  2. Distinctive:

    Verify state mutations are predictable: immutable where required, centralized when appropriate, named transitions, and no hidden mutation …

    line 39
  3. Distinctive:

    Check form behavior: client validation improves UX, server validation remains authoritative, submit state prevents duplicate work, and …

    line 41
  4. Distinctive:

    Check test coverage for key state transitions, side-effect cleanup, form validation paths, optimistic success and rollback, and stale data …

    line 46

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Skill: Frontend State Quality Checklist

Purpose

Review frontend state changes for predictable behavior, complete user states, safe side effects, and testable transitions. Use this checklist to prevent UI bugs caused by unclear ownership, unhandled async states, stale data, leaky effects, and inconsistent form behavior.

When to use

Use for React, Vue, or Svelte state changes; new stores; side effects; form state; client-side data fetching; optimistic updates; global state versus local state decisions; and any UI change where loading, empty, error, or stale data states affect the user experience.

Inputs

  • The frontend change summary and acceptance criteria.
  • Components, stores, composables, hooks, actions, reducers, services, or routes affected.
  • Data-fetching behavior, mutation behavior, cache policy, and form validation rules.
  • Existing tests for state transitions, rendering states, and user interactions.

Workflow

  1. Identify state ownership: local component state, shared store, route state, server cache, form state, or derived state.
  2. Justify global state only when multiple independent consumers need the same source of truth; otherwise prefer local or colocated state.
  3. Map every user-visible state: initial, loading, success, empty, error, retrying, disabled, stale, and permission-denied where applicable.
  4. Verify state mutations are predictable: immutable where required, centralized when appropriate, named transitions, and no hidden mutation through shared references.
  5. Review side effects: dependencies are accurate, subscriptions and timers are cleaned up, abort or cancellation is handled, and framework cleanup hooks are used.
  6. Check form behavior: client validation improves UX, server validation remains authoritative, submit state prevents duplicate work, and error display is specific and recoverable.
  7. Review optimistic updates: define when they apply, how rollback works, what happens on partial failure, and how conflicts are resolved.
  8. Apply stale-while-revalidate where useful for data fetching: show cached data deliberately, refresh in the background, and communicate stale or refreshing state when needed.
  9. Confirm async race handling: stale responses cannot overwrite newer state, unmounted components are safe, and retries do not duplicate side effects.
  10. Inspect accessibility and UX around state changes: focus, announcements, disabled controls, and clear empty or error copy.
  11. Check test coverage for key state transitions, side-effect cleanup, form validation paths, optimistic success and rollback, and stale data refresh.
  12. Record unresolved risks, manual checks, and any intentional trade-offs.

Outputs

  • A completed frontend state quality checklist with pass/fail/needs-follow-up notes.
  • Identified gaps in state modeling, side-effect cleanup, form validation, data fetching, or tests.
  • Verification evidence: test commands, manual checks, or explicit limitations.

Failure modes

  • Adding global state when local state or server cache would be simpler.
  • Handling the success path only while skipping loading, empty, error, retry, or disabled states.
  • Forgetting cleanup for subscriptions, timers, event listeners, in-flight requests, or framework effects.
  • Performing optimistic updates without rollback or conflict handling.
  • Trusting client-only validation for security-sensitive rules.
  • Allowing stale async responses to overwrite newer user actions.
  • Testing final rendered output but not transitions between states.

Verification checklist

  • State ownership is explicit and global state is justified.
  • Loading, empty, error, success, stale, retry, and disabled states are handled where relevant.
  • State mutations are predictable and follow framework conventions.
  • Side effects have correct dependencies and cleanup behavior.
  • Form validation includes client UX checks and server-authoritative validation.
  • Optimistic updates include rollback and conflict behavior.
  • Stale-while-revalidate behavior is deliberate for data fetching where applicable.
  • Tests cover state transitions, cleanup, validation paths, optimistic rollback, and stale refresh behavior.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.