All skills
state-management-design
FoundationJIT onlyUse for client state ownership across local, server, optimistic, persisted, form, auth, or cache boundaries.
- Group
- Frontend engineering
- Supported roles
- MainAnalysisTaskReview
- Source
- SKILL.md
Use when
Trigger signals that make this skill the right owner
- choose local server global derived optimistic and persisted state boundaries
Do not use when
Anti-triggers — as binding as the triggers above
- no task-local state management design decision is required
Required inputs
What must be supplied before this skill can decide anything
- current task contract
- selected primary Professional Skill
- task-local trigger evidence
Output contract
What this skill owes the next role
- state-management decision with classification, authority and scope, identity and freshness, async and optimistic behavior, persistence policy, cleanup evidence, proof limits, and residual owners
Escalation signals
When this skill must hand the decision back
- Wrong state ownership causes stale data duplicated logic and race defects
Loaded by
This skill never owns a task. These professionals may pull it in as Layer 3.
Targeted references
Each reference carries its own load condition. None of them enter context by default.
| Reference | Load when | Do not load when | Required by |
|---|---|---|---|
| benchmarks-and-patterns.mdbenchmark-pattern | state ownership storage freshness invalidation or persistence choices remain unresolved | one authoritative owner determines storage lifecycle and reset behavior | Task |
| checklist.mddecision-checklist | change affects server UI form auth derived or persisted state | local state edit preserves ownership lifetime and synchronization | Task |
| evidence-patterns.mdevidence-pattern | invalidation logout rollback or persistence claims need fresh proof | current stores hooks fixtures and tests prove each claim | Task |