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.
In this repository117 other files it gives its agents.
- AGENTS.mdAGENTS.md
- CLAUDE.mdCLAUDE.md
- advanced-orchestrationSkill
- architect-agentSkill
- implementer-agentSkill
- quality-councilSkill
- reviewer-agentSkill
- tester-agentSkill
- writer-critic-pairSkill
- authoring-skillsSkill
- api-endpoint-qualitySkill
- async-job-qualitySkill
- auth-qualitySkill
- db-migration-qualitySkill
- acceptance-criteriaSkill
- adaptive-flowSkill
- adaptive-prompt-selectionSkill
- adversarial-code-reviewSkill
- architecture-decision-recordsSkill
- brainstormingSkill
- brownfield-spec-enhancementSkill
- bug-fix-lifecycleSkill
- checkpoint-validationSkill
- cicd-integrationSkill
- clarify-before-codeSkill
- claude-code-hooks-packSkill
- code-context-packSkill
- code-intelligence-reviewSkill
- context-policySkill
- context-rich-implementationSkill
- crash-proof-planningSkill
- critique-pass-protocolSkill
- dependency-aware-task-orderingSkill
- deprecation-migrationSkill
- disciplined-diagnosisSkill
- docs-authorSkill
- executing-plansSkill
- external-skillSkill
- finishing-a-development-branchSkill
- git-guardrailsSkill
- goal-driven-executionSkill
- grill-user-before-buildingSkill
- guard-bypass-protocolSkill
- improve-codebase-architectureSkill
- incremental-reviewSkill
- issue-slicingSkill
- lessons-learned-dbSkill
- loop-engineeringSkill
- model-aware-configSkill
- model-weakness-memorySkill
- multi-repo-learningSkill
- orchestration-workflowsSkill
- plan-driven-executionSkill
- plan-from-specSkill
- prd-from-contextSkill
- project-constitutionSkill
- prompt-architectureSkill
- prototype-before-commitmentSkill
- quality-engineSkill
- quality-execution-contractSkill
- The first 60 shown.
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
- Distinctive: line 25
Use for React, Vue, or Svelte state changes.
- Distinctive: line 39
Verify state mutations are predictable: immutable where required, centralized when appropriate, named transitions, and no hidden mutation …
- Distinctive: line 41
Check form behavior: client validation improves UX, server validation remains authoritative, submit state prevents duplicate work, and …
- Distinctive: line 46
Check test coverage for key state transitions, side-effect cleanup, form validation paths, optimistic success and rollback, and stale data …
≈ “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.
Files
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
- Identify state ownership: local component state, shared store, route state, server cache, form state, or derived state.
- Justify global state only when multiple independent consumers need the same source of truth; otherwise prefer local or colocated state.
- Map every user-visible state: initial, loading, success, empty, error, retrying, disabled, stale, and permission-denied where applicable.
- Verify state mutations are predictable: immutable where required, centralized when appropriate, named transitions, and no hidden mutation through shared references.
- Review side effects: dependencies are accurate, subscriptions and timers are cleaned up, abort or cancellation is handled, and framework cleanup hooks are used.
- Check form behavior: client validation improves UX, server validation remains authoritative, submit state prevents duplicate work, and error display is specific and recoverable.
- Review optimistic updates: define when they apply, how rollback works, what happens on partial failure, and how conflicts are resolved.
- 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.
- Confirm async race handling: stale responses cannot overwrite newer state, unmounted components are safe, and retries do not duplicate side effects.
- Inspect accessibility and UX around state changes: focus, announcements, disabled controls, and clear empty or error copy.
- Check test coverage for key state transitions, side-effect cleanup, form validation paths, optimistic success and rollback, and stale data refresh.
- 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.
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
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.

