OpenChamber Settings UI Patterns
A skill that makes AI agents build OpenChamber Settings pages from shared primitives, with localization and search-registry rules enforced instead of hand-rolled markup.
Pure documentation skill: no scripts, network calls, or sensitive-data handling; least privilege is inherently satisfied. Required companion skills (theme-system, locale-ui-patterns, ui-api-decoupling) are outside this assessment's scope and unverifiable. Deducted because referenced source files (SettingsSection.tsx, search.ts) are not provided, so instruction/code alignment cannot be fully confirmed.
Instructions are self-consistent with an explicit conflict-resolution rule; referenced paths are corroborated by repo scripts (settings-registry:generate, icons:generate). However this is a static read; the referenced files are not supplied, and SKILL.md says h-9 while controls.md says h-8 — an internal inconsistency. Score capped at anchor 10.
Description gives clear trigger conditions (creating/modifying OpenChamber Settings surfaces) and it is repo-specific by design; no China-network dependency, no deduction there. Deducted for missing explicit non-fit boundaries; trigger precision partly depends on repo context and inference.
MIT license is clear; layered structure with task-gated references and completion criteria shows good progressive disclosure. Deducted because the skill itself has no version, changelog, or declared ownership/update path in its files; unverified publisher adds no attribution strength (per rules, no extra deduction but no credit).
Clear marginal value for agents building Settings UI in this repo: primitive selection tables, search contract, and completion checklist are directly usable. Deducted because the value depends on supplied-file correctness not independently checkable here, the audience is very narrow, and static review cannot verify representative outputs; capped at 7, scored 6.
Repository-level evidence (CI workflows, test scripts, registry snapshot script) and a manual checklist with last_result entries partially corroborate claims. Deducted because the specific files the skill's key claims rest on are not included and nothing was independently reproduced; capped at 5, scored 4.
- This skill applies only to development inside the OpenChamber repository; do not treat it as a general-purpose Settings UI patterns reference.
- SKILL.md (h-9) and references/controls.md (h-8) disagree on the standard control height; verify against actual source before use.
- The skill depends on three companion skills and multiple source files not included here; loading it standalone yields incomplete context.
- The skill files carry no version or changelog; change tracking requires repository commit history.
- This was a static source review with no execution; actual usability must be reproduced inside the repository.
What does this skill do, and when should you use it?
This is one of 18 skills bundled in the OpenChamber repository (openchamber/openchamber, a desktop and web interface for the OpenCode AI agent), located at .agents/skills/settings-ui-patterns/. It is not an executable tool but a pattern specification an agent loads on demand: Settings pages must be composed from shared primitives such as SettingsSection and SettingsPageLayout, helper text is hidden behind info-hint icons by default, responsive layouts use container queries rather than viewport breakpoints, and every stable control change must update the Settings search registry in the same commit. The skill also mandates loading companion skills (theme-system, locale-ui-patterns, ui-api-decoupling) and routes tasks to three reference files covering layout, controls, and search. It is only directly useful to people working inside the OpenChamber codebase.
It is an instruction document (SKILL.md plus reference files) that the agent loads per task: layout.md for page skeletons and responsiveness, controls.md for field rows, checkboxes, chips and inputs, search.md for adding, moving, or indexing controls. It mandates that page chrome, section headers, field rows, and tooltips come from shared components in packages/ui/src/components/sections/shared/ rather than raw divs; that controls use one standard size (h-9 / select size="settings") with capped widths; that explanatory prose defaults to the info prop while warnings, required syntax, and validation errors stay visible; that save state is reported via SettingsPageLayout's shared indicator or reportSettingsSaveState, with per-page badges forbidden; and that every stable control addition or move registers a search item, a data-settings-item anchor, localized title/description keys, and availability in packages/ui/src/lib/settings/search.ts. New icons require referencing a Remix icon name and running bun run icons:generate.
- An OpenChamber contributor uses an AI agent to add a new Settings page and wants it to automatically follow the repo's layout, spacing, and info-hint conventions
- A maintainer adds or moves a Settings control and needs the agent to update the search registry, anchor, and localization keys in the same change without omissions
- A team wants all Settings-related changes to follow one description policy (visible warnings, explanations behind info hints)
- A developer inheriting the codebase wants the agent to preserve flat hierarchy and container-query responsiveness instead of introducing cards and full-width inputs
What are this skill's strengths and limitations?
- Rules are concrete and actionable: primitive selection table, control sizes, description policy, and search contract leave little room for improvisation
- Mandates companion skills (theme, localization, UI-API decoupling) and on-demand reference loading to control context consumption
- Includes explicit completion criteria for verifying generated changes
- Shared primitives plus container queries match the repository's real code structure
- Extremely narrow applicability: valuable only when developing Settings UI inside OpenChamber; not transferable to other projects
- Contains no executable scripts or automated enforcement — compliance depends entirely on model behavior
- Some detail lives in references/ files not included in the source material, so their completeness cannot be verified
- The repo is an independent project not affiliated with the OpenCode team; no long-term maintenance commitment is stated
How do you install this skill?
The skill ships inside the OpenChamber repository at .agents/skills/settings-ui-patterns/. If you work in the OpenChamber codebase with an Agent Skills-compatible client, the agent can trigger it via the SKILL.md description. The README provides no command to install this skill separately; the repository overall can be obtained via GitHub Releases (desktop apps) or installed as a CLI with curl -fsSL https://raw.githubusercontent.com/openchamber/openchamber/main/scripts/install.sh | bash (requires Node.js 22+), but installing the app is not a prerequisite — developing inside a cloned repository is enough.
How do you use this skill?
While working on Settings in the OpenChamber repository, ask the agent to load the skill, e.g.: "Use the settings-ui-patterns skill to add a checkbox control to Settings and wire it into search." The agent should first load the theme-system and locale-ui-patterns companion skills, then read references/layout.md, controls.md, or search.md depending on the task. Note the skill runs no scripts; its effect depends on the agent actually loading the references and obeying the rules. Using it outside the OpenChamber repo is meaningless because the shared primitives it references do not exist there.