Menu
Principles and patterns for writing slash command definitions
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
Fast-forward through OpenSpec artifact creation. Use when the user wants to quickly create all artifacts needed for implementation without stepping through each one individually.
Start a new OpenSpec change using the experimental artifact workflow. Use when the user wants to create a new feature, fix, or modification with a structured step-by-step approach.
How to write specs, name capabilities, and structure requirements. Load this when creating or reviewing proposals, specs, or capability lists.
How to invoke the openspec CLI. Load this BEFORE running any openspec commands.
Principles and patterns for writing agent definitions
| name | command-design |
| description | Principles and patterns for writing slash command definitions |
How to write and maintain commands in .opencode/commands/<name>.md.
A command defines a repeatable process kicked off by a slash command. It should be self-contained: everything needed to execute the workflow is in the command file.
| Command (workflow) | Not a command |
|---|---|
| /ship -- verify, commit, PR | Answering "what should I work on?" (agent) |
| /work -- pick issue, set up env | How to write good commit messages (skill) |
| /prune -- clean merged worktrees | Deciding priority order (agent) |
---
description: <what this command does>
---
## /<command-name> Command
<1 sentence summary>
### Input
- <parameter>: $ARGUMENTS
### Phase 1: <Step Name>
<Instructions>
### Phase 2: <Step Name>
<Instructions>
### Phase N: Report
<Output summary>
Phase-based flow: Break workflows into numbered phases with clear boundaries. Each phase has a single responsibility. This makes commands easy to follow, debug, and modify.
Decision trees over prose: Use tables and if/then structures for branching logic. Commands often have multiple paths -- make them explicit, not buried in paragraphs.
Delegate to agents: Commands compose agents, they don't duplicate agent logic. If an agent knows how to create PRs, the command delegates to it rather than reimplementing PR creation.
Explicit stop points: Define exactly when to STOP and ask the user. Especially at:
Report at the end: Every command ends with a summary of what happened. The user should know what changed without re-inspecting.
Commands are the most brittle extension point because they hard-code workflows that compose agents and tools. When an agent's interface changes, commands that delegate to it may break.
When updating a command:
When an agent changes: