opencode-primitives
$
npx mdskill add different-ai/openwork/opencode-primitivesEnsures OpenCode primitives are implemented according to official documentation
- Solves inconsistencies in skill, plugin, and config-driven behavior implementation
- Relies on OpenCode documentation for skills, plugins, MCP servers, and opencode.json
- Applies naming rules, file structure, and permission logic from OpenCode specs
- Produces UI-consistent terminology and behavior aligned with OpenWork standards
SKILL.md
.github/skills/opencode-primitivesView on GitHub ↗
---
name: opencode-primitives
description: Reference OpenCode docs when implementing skills, plugins, MCPs, or config-driven behavior.
---
## Purpose
Use this skill whenever OpenWork behavior is implemented directly on top of OpenCode primitives (skills, plugins, MCP servers, opencode.json config, tools/permissions). It anchors decisions to the official OpenCode documentation and keeps terminology consistent in the UI.
## Doc Sources (Always cite when relevant)
- Skills: https://opencode.ai/docs/skills
- Plugins: https://opencode.ai/docs/plugins/
- MCP servers: https://opencode.ai/docs/mcp-servers/
- Config (opencode.json, locations, precedence): https://opencode.ai/docs/config/
## Key Facts To Apply
### Skills
- Skill files live in `.opencode/skills/<name>/SKILL.md` or global `~/.config/opencode/skills/<name>/SKILL.md`.
- Skills are discovered by walking up to the git worktree and loading any matching `skills/*/SKILL.md` in `.opencode/` or `.claude/skills/`.
- `SKILL.md` requires YAML frontmatter: `name` + `description`.
- Name rules: lowercase alphanumeric with single hyphens (`^[a-z0-9]+(-[a-z0-9]+)*$`), length 1-64, must match directory name.
- Description length: 1-1024 characters.
- Access is governed by `opencode.json` permissions (`permission.skill` allow/deny/ask).
### Plugins
- Local plugins live in `.opencode/plugins/` (project) or `~/.config/opencode/plugins/` (global).
- npm plugins are listed in `opencode.json` under `plugin` and installed with Bun at startup.
- Load order: global config, project config, global plugins dir, project plugins dir.
### MCP Servers
- MCP servers are defined in `opencode.json` under `mcp` with unique names.
- Local servers use `type: "local"` + `command` array; remote servers use `type: "remote"` + `url`.
- Servers can be enabled/disabled via `enabled`.
- MCP tools are managed via `tools` in config, including glob patterns.
- OAuth is handled automatically for remote servers; can be pre-registered or disabled.
### Config (opencode.json)
- Supports JSON and JSONC.
- Precedence order: remote `.well-known/opencode` -> global `~/.config/opencode/opencode.json` -> custom path -> project `opencode.json` -> `.opencode/` directories -> inline env overrides.
- `.opencode` subdirectories are plural by default (`agents/`, `commands/`, `plugins/`, `skills/`, `tools/`, `themes/`), with singular names supported for compatibility.
## When to Invoke
- Adding or adjusting OpenWork flows that reference skills, plugins, MCP servers, or OpenCode config.
- Designing onboarding guidance that mentions skill/plugin installation, config locations, or permission prompts.
- Implementing UIs that surface OpenCode primitives (skills tab, plugin manager, MCP toggles).
## Usage
Call `skill({ name: "opencode-primitives" })` before implementing or documenting any OpenWork behavior that maps to OpenCode primitives.
More from different-ai/openwork
- browser-setup-devtoolsGuide users through browser automation setup using Chrome DevTools MCP only. Use when the user asks to set up browser automation, Chrome DevTools MCP, browser MCP, or runs the browser-setup command.
- daytona-electron-testTest the real Electron app on Daytona: create sandbox, start services, connect via CDP, create workspaces, drive sessions, and verify settings. Use when the user says 'test on Daytona', 'run the app on Daytona', 'Daytona dry run', 'test Electron remotely', or 'reproduce on Daytona'.
- get-startedGuide users through the get started setup and Chrome DevTools demo.
- opencode-bridgeBridge between OpenWork UI and OpenCode runtime
- opencode-mirrorMaintain the local OpenCode mirror for self-reference
- openwork-coreCore context and guardrails for OpenWork native app
- openwork-debugDebug OpenWork sidecars, config, and audit trail
- openwork-orchestrator-npm-publish|
- run-evalsRun OpenWork UI evals on a Daytona sandbox or local Electron instance. Handles sandbox creation, service startup, and eval execution via CDP browser tools.
- shadcnManages shadcn components and projects — adding, searching, fixing, debugging, styling, and composing UI. Provides project context, component docs, and usage examples. Applies when working with shadcn/ui, component registries, presets, --preset codes, or any project with a components.json file. Also triggers for "shadcn init", "create an app with --preset", or "switch to --preset".