OpenChamber UI/API Decoupling Rules
Enforces clean data-access boundaries in OpenChamber's shared UI: official APIs via the SDK, app capabilities via RuntimeAPIs — no hardcoded URLs, tokens, or transport assumptions.
The skill mandates least privilege (privileges kept at the native boundary), explicit confirmation for trust-boundary mutations, no long-lived credentials in URLs, parsing external payloads at the boundary, and no masking failures as empty values; data-flow disclosure is thorough. Deducted: publisher identity is unverified, and several security claims (ui-auth allowlist, scoped tokens) are assertions not statically confirmed against implementations.
SKILL.md is internally consistent; classification tables, rules, anti-patterns, reference paths and test lists cross-check cleanly; rule 8 mandates clear failure feedback. Deducted: nothing was executed; existence and passing status of the cited test files were not confirmed and edge-case coverage rests on claims.
The description lists precise triggers (RuntimeAPIs, runtime fetch/auth, SDK calls, runtime switching), giving low false-trigger risk; five runtimes and explicit unsupported behavior are enumerated. Deducted: the skill is tightly bound to this repository's internal structure with near-zero applicability elsewhere, and non-fit scope is not explicitly declared.
Good layering: main SKILL.md plus three task-oriented references with progressive disclosure; repo has MIT license, versioning and changelog tooling. Deducted: the skill file itself has no version/changelog, and maintenance responsibility/update path are only partially evidenced at repo level.
For UI/API decoupling work in this repo the skill provides directly actionable rules, code paths and anti-patterns, clearly better than informal conventions. Deducted: static review cannot verify outputs are directly usable; scope is narrow, limiting general marginal value.
Concrete test file paths and verification checklists are cited and auditable. Deducted: tests were not executed, test file contents and actual CI coverage of the skill's key paths were not confirmed, and evidence types are limited.
- This skill applies only to development inside the OpenChamber repository; it is not general architecture guidance.
- Static review executed nothing; the listed test files and their CI coverage were not independently verified.
- Publisher is unverified; security claims (scoped URL tokens, allowlists) should be checked against actual code before relying on them.
- The skill file has no independent version/changelog; compare repository commit history when it changes.
What does this skill do, and when should you use it?
This is one of 18 skills bundled in the openchamber/openchamber repository, located at .agents/skills/ui-api-decoupling/. It is a guidance-only SKILL.md with no scripts; it constrains AI assistants to follow the project's established layering when creating or modifying data access in OpenChamber's shared UI. The core boundary: official OpenCode API calls must go through @opencode-ai/sdk/v2 via opencodeClient; OpenChamber-owned HTTP capabilities use RuntimeAPIs or explicit routes via runtimeFetch; browser/realtime consumers use runtime URL resolvers. Three task-scoped references (browser assets & auth, runtime parity, implementation map) are loaded as needed.
Loads the right reference (browser-assets-and-auth.md, runtime-parity.md, or implementation-map.md) based on the task table before any edit; provides a classify-first routing table (official endpoint → opencodeClient, OpenChamber route → runtimeFetch, runtime capability → RuntimeAPIs, SSE/WebSocket → owning transport plus relay-transport); imposes 13 mandatory rules including never bypassing the SDK, registering routes before the generic proxy, resolving runtime state at call time, never putting long-lived credentials in URLs, parsing external payloads at the boundary, and modeling real contracts with discriminated unions; includes runtimeFetch code examples and an anti-pattern comparison table; ends with a verification checklist requiring transport/bridge/proxy/auth/runtime-switch tests — static type checks alone are deemed insufficient.
- A contributor lets an AI assistant add or modify shared-UI data access in OpenChamber and needs it to route through the correct SDK/path instead of ad-hoc fetch
- A maintainer keeping behavior consistent across web, Electron, VS Code, and mobile runtimes needs the skill to force explicit per-runtime support or stable unsupported responses
- Handling authenticated browser assets (iframes, downloads, raw images, object URLs) requires scoped short-lived URL tokens per the reference doc, never tokens appended manually
- Implementing runtime switching requires reviewing and resetting cached base URLs, credentials, SDK clients, and realtime transports so stale endpoint state is never reused
- During code review, use the anti-pattern table and verification checklist to check request fidelity, failure signaling, and privilege boundaries
What are this skill's strengths and limitations?
- Rules are extremely concrete: a classify-first table, copyable runtimeFetch examples, and an anti-pattern comparison table leave little ambiguity for model execution
- Three task-scoped reference docs cover auth, privileges, and runtime switching — classic failure zones — in depth
- Enforces explicit failure signaling, boundary parsing of external payloads, and discriminated unions, which prevents silent state-corruption bugs
- Pure Markdown guidance with no scripts, so porting to any Agent Skills-compatible client is cheap
- Tightly coupled to OpenChamber-internal concepts (RuntimeAPIs, opencodeClient, runtimeFetch, relay-transport); nearly worthless outside this repository
- It is a constraint spec, not an executable tool — no scripts or automated verification, so effectiveness depends entirely on the model following 13 rules
- Contents of references/implementation-map.md and the other references are not shown in the source, so their completeness cannot be assessed
- The verification checklist requires transport/bridge/auth tests, but the tests themselves are not shown in the source; actual coverage is unverifiable
How do you install this skill?
The skill ships inside the OpenChamber repository at .agents/skills/ui-api-decoupling/. OpenChamber users can manage repo skills through the app's built-in skills catalog (the README mentions this feature but gives no steps for installing a single skill file into other Agent Skills clients). To use it elsewhere, copy the whole ui-api-decoupling directory (SKILL.md plus references/) into your client's skills folder; the exact path depends on your client and is not documented in the source.
How do you use this skill?
The skill triggers automatically via its description whenever a task touches OpenChamber shared UI data access, OpenCode SDK calls, RuntimeAPIs, runtime fetch/auth/URLs, authenticated browser assets, bridges/proxies, runtime switching, or server API routes. You can also invoke it explicitly, e.g.: 'Add a data load for the settings page calling an OpenChamber route; per the ui-api-decoupling skill, classify whether it goes through runtimeFetch or the SDK first and load the matching references before editing.'