OpenChamber Sync State Invariants
A rulebook that enforces state ownership and failure semantics when agents change session sync, event reducers, polling, and caches — preventing destructive data loss and state corruption.
Pure guidance document with no scripts, commands, or external effects; least privilege is inherently satisfied and there are no covert data flows or red-line risks; deducted because rollback, confirmation, and source-attribution mechanisms are absent. 14/25.
Instructions are internally consistent, well structured, and concrete (failure-not-empty, optimistic updates, cache eviction), with a detailed verification checklist; deducted because the required context files (packages/ui/src/sync/DOCUMENTATION.md) are not present in evidence, key paths cannot be statically reproduced, and failure-feedback quality on abnormal input is unverifiable. 8/20.
Frontmatter trigger conditions are precise and scenario-oriented (sync, bootstrap, reconnect, reducers, polling, optimistic updates); deducted for undeclared non-fit boundaries, no Chinese-language considerations, and a narrow audience of this repo's own developers. 8/15.
Clear layering, stable naming, a verification checklist, and repository-level MIT license with active maintenance signals (CI, version 1.22.2); deducted for no skill-level versioning, changelog, or explicit update path, and required referenced docs are not visible, leaving hidden assumptions. 8/15.
Clear marginal value for developers maintaining this sync subsystem by encoding error-prone invariants as actionable rules plus a verification branch list; deducted because static review cannot confirm outputs are directly usable and representative results were not reproduced. 7/15.
Repository contains real test scripts (packages/ui test etc.) and a manual checklist as partially auditable primary material; deducted because evidence covering the skill's own referenced docs and key paths is thin and claims cannot be independently reproduced. 4/10.
- The referenced required-context file packages/ui/src/sync/DOCUMENTATION.md is not present in the assessment evidence; users should confirm it exists and matches the skill's rules.
- This is a static review; no verification checklist items were executed, so claimed lifecycle-branch coverage is declared but not independently reproduced.
- The skill has no independent version or changelog; rules may drift from code, so users should verify current code still follows these invariants.
- Rules are tightly coupled to this repository's internal architecture; cross-project reuse value is limited.
What does this skill do, and when should you use it?
sync-state-invariants is one of 18 skills bundled in the OpenChamber repository (a desktop and web interface for the OpenCode AI agent), located at .agents/skills/sync-state-invariants/. It is not an executable script but a domain engineering rulebook that activates when an AI agent modifies session synchronization, bootstrap/reconnect state, event reducers, polling, optimistic updates, or runtime-scoped caches. Its core rules cover classifying input authority, never letting failure masquerade as empty data, requiring complete authoritative snapshots before destructive cleanup, never evicting in-use cache entries, and a verification checklist spanning every lifecycle branch. It suits teams using agents on real-time, multi-directory session UIs like OpenChamber's.
The skill injects mandatory pre- and during-edit rules into the agent: read packages/ui/src/sync/DOCUMENTATION.md and owning module docs until every changed state has an identified owner, authority, scope, and lifecycle; classify inputs as directory child store, global sessions store, persisted history, or optimistic shadow state; require authoritative loaders to distinguish failure from legitimate emptiness (throw, or return T | null — never swallow SDK/API errors into []); permit snapshot-difference cleanup only between two complete authoritative snapshots from the same runtime and scope; require event reducers with explicit flat transition paths that reject stale async completions; keep optimistic updates encapsulated in the owning store with client-generated IDs reconciled against server echoes; key runtime-scoped caches by runtime identity and forbid eviction scans on the acquisition path; and finish with a verification checklist covering bootstrap, failure preservation, retries, rollback, partial multi-directory failure, and hydration races.
- An agent editing OpenChamber's session sync or reconnect logic, kept from wiping the session list by treating a fetch failure as empty data
- An agent changing an event reducer, forced to keep one ordering source and reject stale events so multi-tab session state stays consistent
- An agent implementing optimistic message queueing that needs correct client-ID/server-echo reconciliation and rollback-on-failure patterns
- An agent writing a runtime-scoped cache, steered away from evicting mounting entries on acquisition and the resulting infinite request loop
- An agent adjusting polling or bootstrap, required to preserve rich fields omitted by lightweight polling and treat startup 502/503 as transient
- An agent handling persisted-snapshot hydration, guided to define authority and monotonic revisions so stale writes are rejected
What are this skill's strengths and limitations?
- Rules are concretely actionable: each invariant ships with the correct implementation pattern (throw vs T | null, generation tokens vs mutation revisions), not vague advice
- The 'failure is not empty' and 'never evict what is in use' sections target real production failure modes (e.g., the unprotected-during-render infinite request loop) with symptom descriptions that aid diagnosis
- The verification checklist covers easily-missed branches: partial multi-directory failure, hydration races, snapshot-difference baseline resets
- Pure-text rulebook with no script dependencies — portable to any Agent Skills-compatible client
- Tightly coupled to the OpenChamber repo: it mandates reading packages/ui/src/sync/DOCUMENTATION.md, which does not exist in other codebases
- It is a coding discipline, not an executable checker: no bundled tests or linters verify compliance — effectiveness depends entirely on model adherence
- Narrow trigger scope — only relevant when changing sync/cache/reducer code, not general frontend work
- No metrics or user feedback in the source demonstrating it actually reduces bugs
How do you install this skill?
The skill ships inside the OpenChamber repository at .agents/skills/sync-state-invariants/. Installing OpenChamber provides it: via CLI with curl -fsSL https://raw.githubusercontent.com/openchamber/openchamber/main/scripts/install.sh | bash (requires Node.js 22+), or by downloading a Desktop release from GitHub Releases. To use just this skill with any Agent Skills-compatible client, copy the .agents/skills/sync-state-invariants/ folder (containing SKILL.md) into your client's skills directory. The source does not document how the skill degrades in projects lacking packages/ui/src/sync/DOCUMENTATION.md — evaluate that yourself.
How do you use this skill?
In a client that supports Agent Skills (e.g., Claude Code), the skill is selected per its frontmatter description whenever a task touches session synchronization, bootstrap/reconnect state, event reducers, polling, optimistic updates, message queues, ordering/reconciliation, runtime-scoped caches, or directory-dependent session behavior. You can also invoke it explicitly with a prompt like: 'Follow the sync-state-invariants skill when modifying this reducer.' The skill then makes the agent read packages/ui/src/sync/DOCUMENTATION.md first and work according to its invariants and verification checklist. For streaming-frequency work, it instructs the agent to also load the performance-engineering skill.
How does this skill compare with similar options?
Within the OpenChamber repo it works alongside the other 17 bundled skills — notably performance-engineering, which this skill explicitly references for streaming-frequency work; this skill owns sync-state correctness while performance-engineering owns performance. The source names no external alternatives.