React · plan by default
/react-state
Simplify state ownership, derived state, and synchronization
Use for duplicated/inconsistent state ownership; react-effects handles external synchronization.
Make it your own.
In Claude Code, use the slash command and add your context. In Codex, select react-state from the just-vibe skill picker, then send the same brief.
Version 0.11.0 also supports /jv react-state, /just-vibe react-state and /jv:react-state in Claude. See shortcut setup and context examples.
/just-vibe:react-state Plan simplifying duplicated filter state without adding a state library./just-vibe:react-state Refactor a multi-tab editor without sharing unsaved drafts across documents./just-vibe:react-state Review state design when persistence requirements are unspecified.What the agent does
- Name each authoritative value and derived representation, and distinguish per-instance, shared and persisted state.
- Model update and reset transitions, choose the narrowest owner, and remove redundant representations only when their synchronization is understood.
- Verify the user-visible behavior.
Inputs
- component flow and ownership constraints.
Optional context: scope, references, constraints, successCriteria, environment, mode, budget.
Scope
- Reads
- State location, derived values, synchronization, and transitions within the feature.
- Writes
- Inspect/plan: inspect or propose; save requested artifacts only. Apply: edit the requested local implementation and perform relevant bounded checks while preserving unrelated work. Live data changes, remote actions and paid jobs require their resolved target and existing session authorization.
- Mode
- Plan for redesign; apply for explicit state refactoring. Requires component flow and ownership constraints.
- Prerequisites
- Component source, React/framework versions, state/data conventions, and relevant test tooling. Browser/profiler evidence is needed for measured rendering claims. Preserve existing framework and state libraries unless changing them is part of the request.
Expected output
- Ownership/transition table and the proposed or implemented simplification, with checks for reset, independent instances and persistence.
How the work is checked
- Editing and resetting remain consistent; independent component instances do not accidentally share local state.
When to stop or clarify
- Do not introduce a global store by default. Undefined persistence or cross-tab requirements are explicit design questions.
Handling missing context
- Infer
- Read component callers, ownership of state, installed React/framework versions and existing interaction tests.
- Assume
- Retain the framework and state library; preserve intended loading/error/empty behavior while resolving the named bug.
- Ask
- Ask when product semantics such as persistence, optimistic failure or reset behavior have conflicting evidence; missing profiler access only blocks measured performance claims.
Technical guidance
- Evidence
- Map each value to its owner, lifetime, derivation, persisted form and reset trigger.
- Method
- Keep intentional drafts distinct from server values; remove duplicate state only when its synchronization contract is understood.
- Pitfall
- Copying props into state on every update can erase user edits; a module variable can leak state between instances or server requests.
- Check
- Test two instances, identity changes, reset and recoverable errors; verify drafts and unrelated state are preserved as intended.
Situational decisions
When a prop change should reset only one form instance: Define the reset identity explicitly rather than synchronizing every prop into local 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.