What does this skill do, and when should you use it?
This skill is one of 18 bundled in the OpenChamber repository (an agentic development environment built on the OpenCode AI agent), located at .agents/skills/ui-api-decoupling. It is an architectural constraint guide: when an agent creates or modifies shared UI data access, it mandates that official OpenCode API calls go through @opencode-ai/sdk/v2, OpenChamber-owned routes through runtimeFetch, and runtime-owned capabilities through RuntimeAPIs. The skill ships 13 mandatory rules, a classification table, task-indexed reference documents, anti-pattern tables, and a verification checklist. It targets consistent behavior across web, Electron, VS Code, and mobile runtimes.
- Classifies each data-access need into the correct path: official SDK, owned HTTP route, runtime capability, or browser authenticated URL
- Forces OpenCode SDK calls through opencodeClient, banning bypasses or manually rebuilt requests
- Governs runtimeFetch usage and forbids hardcoded localhost, ports, or credentials in shared UI
- Audits caches, auth state, and transports on runtime switching to prevent stale endpoint reuse
- Requires boundary parsing of external payloads instead of validating then passing raw JSON
- Loads three on-demand references: browser assets/auth, runtime parity, and implementation map
- An OpenChamber contributor adding or changing data fetching in a shared UI component needs to decide between the SDK and runtimeFetch
- A maintainer must add a capability for one runtime (VS Code or Electron) or explicitly declare unsupported behavior across runtimes
- A developer implementing runtime switching must ensure caches, SDK clients, and credentials are not reused across endpoint switches
- Handling iframes, downloads, or images that need browser-authenticated assets via scoped short-lived URL auth instead of long-lived tokens in URLs
- A reviewer checking a PR for boundary violations like components reading runtime globals or fetch failures returning empty arrays
- Not useful for general frontend projects outside the OpenChamber codebase — every rule binds to its specific RuntimeAPIs, runtimeFetch, and runtime adapter architecture
- Does not cover implementing realtime transports like relay-transport itself; it only requires loading that skill alongside
How do you install this skill?
- 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.
- Local filesystem
The skill ships inside the OpenChamber repository at .agents/skills/ui-api-decoupling/. The README documents no standalone skill-install command; clone the repo and copy the skill folder into any Agent Skills-compatible client's skill path:
git clone https://github.com/openchamber/openchamber.git
cp -r openchamber/.agents/skills/ui-api-decoupling <your-skills-directory>/How do you use this skill?
Once installed, send your agent any of these to trigger it:
- Add a call to a new OpenChamber HTTP route /api/config/settings for the shared UI, registered before the generic OpenCode proxy
- I need to support a web-only capability in the VS Code runtime — implement it per the runtime parity rules and declare behavior for each runtime
- Refactor a component that reads runtime globals for URLs to use runtimeFetch and remove the hardcoded localhost port
- After a runtime switch the terminal and session caches show stale data — audit and fix cross-runtime cache keying and auth state reuse
The skill triggers automatically when an agent creates or modifies OpenChamber shared UI data access, per its SKILL.md description. Flow: classify the need using the table, load the matching reference documents (e.g. references/runtime-parity.md), apply the 13 mandatory rules, then verify against the checklist. No CLI options exist.
What are this skill's strengths and limitations?
- Rules are concrete and executable — 13 mandatory rules plus an anti-pattern table, not vague advice
- Task-indexed references avoid loading all context at once
- Addresses the real problem of cross-runtime parity (web/Electron/VS Code/mobile)
- Defines verification standards: transport/bridge/proxy tests must pass; static type/lint checks alone are insufficient
- Tightly coupled to OpenChamber's internal architecture; little transfer value elsewhere
- No automation scripts or test tooling — it is documentation-only guidance
- Enforcement relies on the agent proactively loading references; there is no hard mechanism
How does this skill compare with similar options?
Side by side with related skills; every score comes from the same FSRS standard.
| Skill | FS score | Stars | Last updated | License |
|---|---|---|---|---|
| OpenChamber UI/API Decoupling Skill this page | 58 · Recommended | ★ 12k | 11d ago | MIT |
| OpenChamber Desktop Shell Skill | 54 · Use with care | ★ 12k | 11d ago | MIT |
| VS Code Integration Test Runner ✓ Microsoft · Official | 52 · Use with care | ★ 194k | 11d ago | MIT |
| Locale UI Patterns — OpenChamber UI Localization Rules | 61 · Recommended | ★ 12k | 11d ago | MIT |
| Callimachus Recall | 58 · Recommended | ★ 43 | 3mo ago | AGPL-3.0 |
The README positions OpenChamber as a visual alternative/enhancement to OpenCode's TUI, but no alternative is named for this specific skill.
How did FollowSkills review this skill?
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.
Open a dimension to read why it scored that way
Evidence confidence：Low — Mostly static review, author material or a limited demo; useful for discovery, not high-risk decisions.
See the full review method →