Skills as Commands
OpenCode discovers skills from your project and home directories and exposes them to the model through its built-in skill tool. It does not, however, surface them in the TUI’s slash-command autocomplete. Systematic closes that gap: every skill OpenCode discovers becomes an invokable /skill-name command, the same way Claude Code and other agents treat skills.
This is on by default. If you already keep skills under .opencode/skills/, .claude/skills/, or .agents/skills/, they show up as commands as soon as the plugin loads — no configuration required.
Where skills are discovered
Section titled “Where skills are discovered”Systematic mirrors OpenCode’s own discovery contract exactly, so the command you invoke resolves to the same skill OpenCode’s skill tool would load. Skills are discovered from six roots:
| Scope | Locations |
|---|---|
| Global | ~/.claude/skills/, ~/.agents/skills/, ~/.config/opencode/skills/ |
| Project | .opencode/skills/, .claude/skills/, .agents/skills/ |
Project locations are discovered by walking up from your working directory to the git worktree root, so a skill defined in a subdirectory of a monorepo is found too.
When the same skill name exists in more than one location, the winner follows OpenCode’s precedence: .opencode skills win over .claude/.agents skills, and project skills win over global ones. The command Systematic registers always points at that same winner.
How a command is built
Section titled “How a command is built”Each discovered skill becomes a config.command entry named after the skill (/git-release, /deploy, and so on). The command includes the full skill text, not a pointer to it:
/git-release v2.4.0OpenCode processes the command the same way it processes its own commands: it substitutes any arguments you typed into the skill text, and it runs any !`command` snippets the skill contains, before the model ever sees the result. Only install skills you trust — a skill’s command can run shell snippets on your machine as part of being invoked.
A skill with disable-model-invocation: true in its frontmatter is a manual workflow — you invoke it, the model does not load it on its own. There is one honest limitation here: OpenCode has no mechanism for a plugin to hide a skill from the model’s own skill tool. Systematic controls the /command surface, but a command-only skill remains loadable by the model through OpenCode’s skill tool regardless. The disable-model-invocation flag shapes the command; it is not a hard guarantee that the model can never reach the skill.
Trust model
Section titled “Trust model”Systematic does not add a trust gate on discovered skills, and this is deliberate. OpenCode already discovers and registers these same skills — including project-local ones from a cloned repository — without a trust prompt, and a command never runs on its own: a human types it. Adding a Systematic-specific gate would restrict less than what OpenCode already exposes while adding friction. Treat skills in a repository you did not write the same way you treat any other code in it.
Turning it off
Section titled “Turning it off”Set skills_as_commands to false in your systematic.json to disable the feature entirely:
{ "skills_as_commands": false}Your own commands are never touched — Systematic only registers a discovered skill as a command when no command of that name already exists, so a command you define yourself always wins. Bundled Systematic skills (the systematic: and ce: commands) are unaffected by this setting.
To suppress a single discovered skill’s command rather than the whole feature, add its name to disabled_commands:
{ "disabled_commands": ["git-release"]}A discovered skill registers as a command under its bare name, so disabled_commands is the field that governs it. (The disabled_skills field only accepts bundled Systematic skill names.)
Relationship to upstream
Section titled “Relationship to upstream”OpenCode registers discovered skills as commands internally, but its TUI intentionally keeps them out of slash-command autocomplete in favor of a dedicated skills picker. That is a deliberate upstream choice, so this behavior may converge over time. If it does, Systematic’s registration degrades gracefully: because Systematic’s entry replaces the skill-sourced one by name, you still see exactly one command per skill, and the skills_as_commands toggle removes Systematic’s entries entirely.