Command Creator
Create custom /slash commands for repetitive tasks in OpenCode. Use when user wants to create a command, automate a workflow, make a shortcut, add a slash command, set up automation, create a /test, /review, /deploy, /commit, /fix, /build, /lint, /spellcheck, /migrate, or /ci command. Also use when writing a command file, configuring command frontmatter, using $ARGUMENTS placeholders, setting agent: plan, using subtask: true, injecting shell output with !cmd, referencing files with the at-file syntax in a command template, or choosing between a slash command, agent, and skill.
npx skills add github:pantheon-org/tekhne --skill agentic-harness--opencode-toolkit--design-commandsQuick Start
Create .opencode/commands/<name>.md:
---
description: Run tests and fix all failures automatically
---
Run the full test suite, identify any failures, and fix them.
1. Run `npm test`
2. For each failure, identify root cause and fix
3. Re-run to verify all pass
Invoke it in OpenCode: /test
Run bun run opencode to start, then type /<name> to invoke your command.
Mindset
Slash commands are user-to-agent shortcuts — markdown files with an instruction template. User types /test → OpenCode substitutes placeholders → agent executes.
Decision rule:
- Human wants a shortcut → Command
- Agent needs standing instructions → Skill
- Task needs a persona → Agent
When to use: Repetitive multi-step tasks that need a one-word trigger.
When NOT to use: Do not create a command for one-off tasks — just type the instruction directly. Do not use commands for interactive workflows; commands are one-shot.
Modes: no agent: = default build (read/write); agent: plan = read-only; subtask: true = fire-and-forget.
Template Placeholders
$ARGUMENTS — all args; $1/$2 — positional; !cmd — shell output injection; @filename — include file content.
# Dynamic context injection example
!git log --oneline -5
---
description: Deploy to staging with context
agent: plan
subtask: true
---
Deploy $ARGUMENTS using the steps in docs/deploy.md.
!git log --oneline -3
Anti-Patterns
NEVER use $ARGUMENTS more than once in a command body. WHY: The placeholder is substituted literally — using it twice creates duplicate content that confuses the agent.
# BAD — duplicate content
Review $ARGUMENTS. Focus on $ARGUMENTS for security issues.
# GOOD — wrap in XML once
<target>$ARGUMENTS</target>
Review the target file for security issues and bugs.
NEVER tell the agent to “run /command” inside a command body. WHY: Agents cannot invoke slash commands from within a command — only users can type /cmd.
# BAD
After fixing, run /test to verify.
# GOOD
After fixing, run `npm test` to verify.
NEVER use agent: plan for commands that write files. WHY: The plan agent is read-only and will refuse any write operation, silently failing the command.
# BAD
---
agent: plan
---
Create a new file called output.md with the results.
# GOOD — remove agent: plan for write operations
References
references/command-patterns.md— Creation phases, example commands (/test, /review, /commit, /deploy, /spellcheck), pattern libraryreferences/frontmatter-reference.md— Complete frontmatter fields and placeholder reference
Eval Scenarios: Scenario 0: Deploy | Scenario 1: Spellcheck | Scenario 2: Fix anti-patterns
Explicit NEVER/WHY/consequence triplets with side-by-side bad/good examples. Generic warnings score low — concrete failure modes with real impact (security, correctness, performance) score high.
Runtime validation via eval scenarios proving the skill actually changes agent behaviour. Requires evals/ directory, instructions.json, ≥3 scenarios, and ≥80% instruction coverage in summary.json.
Appropriate rigidity for the skill type: strict rules for critical/security skills, balanced steps for process skills, flexible options for tool skills. Mismatched calibration (too rigid or too loose) reduces score.
Expert-only knowledge the AI couldn't derive on its own — domain-specific patterns, production gotchas, decision frameworks, and non-obvious tool behaviour. High scores mean <5% redundancy with what the model already knows.
A clear philosophy plus numbered step-by-step workflows with explicit entry/exit points. Should answer: what is the core principle, how to execute it, and when (and when not) to apply it.
Rich activation keywords and trigger scenarios in the description so the skill fires when needed. Best descriptions read like an exhaustive list of the tasks and concepts that should invoke this skill.
Copy-paste-ready code, complete runnable examples, real file paths and commands. Pseudocode and abstract descriptions score low — concrete, executable content scores high.
SKILL.md as a <100-line navigation hub pointing to focused references/ files. Content should be lazy-loaded on demand, not front-loaded. Includes actionable 'When to Use' conditions per reference.
Proper frontmatter, single-task focus, activation keywords, and cross-harness portability. Skills must work across 40+ agentic harnesses without hardcoded paths or agent-specific references.
Expert-only knowledge the AI couldn't derive on its own — domain-specific patterns, production gotchas, decision frameworks, and non-obvious tool behaviour. High scores mean <5% redundancy with what the model already knows.
A clear philosophy plus numbered step-by-step workflows with explicit entry/exit points. Should answer: what is the core principle, how to execute it, and when (and when not) to apply it.
Explicit NEVER/WHY/consequence triplets with side-by-side bad/good examples. Generic warnings score low — concrete failure modes with real impact (security, correctness, performance) score high.
Proper frontmatter, single-task focus, activation keywords, and cross-harness portability. Skills must work across 40+ agentic harnesses without hardcoded paths or agent-specific references.
SKILL.md as a <100-line navigation hub pointing to focused references/ files. Content should be lazy-loaded on demand, not front-loaded. Includes actionable 'When to Use' conditions per reference.
Appropriate rigidity for the skill type: strict rules for critical/security skills, balanced steps for process skills, flexible options for tool skills. Mismatched calibration (too rigid or too loose) reduces score.
Rich activation keywords and trigger scenarios in the description so the skill fires when needed. Best descriptions read like an exhaustive list of the tasks and concepts that should invoke this skill.
Copy-paste-ready code, complete runnable examples, real file paths and commands. Pseudocode and abstract descriptions score low — concrete, executable content scores high.
Runtime validation via eval scenarios proving the skill actually changes agent behaviour. Requires evals/ directory, instructions.json, ≥3 scenarios, and ≥80% instruction coverage in summary.json.
Expert-only knowledge the AI couldn't derive on its own — domain-specific patterns, production gotchas, decision frameworks, and non-obvious tool behaviour. High scores mean <5% redundancy with what the model already knows.
A clear philosophy plus numbered step-by-step workflows with explicit entry/exit points. Should answer: what is the core principle, how to execute it, and when (and when not) to apply it.
Explicit NEVER/WHY/consequence triplets with side-by-side bad/good examples. Generic warnings score low — concrete failure modes with real impact (security, correctness, performance) score high.
Proper frontmatter, single-task focus, activation keywords, and cross-harness portability. Skills must work across 40+ agentic harnesses without hardcoded paths or agent-specific references.
SKILL.md as a <100-line navigation hub pointing to focused references/ files. Content should be lazy-loaded on demand, not front-loaded. Includes actionable 'When to Use' conditions per reference.
Appropriate rigidity for the skill type: strict rules for critical/security skills, balanced steps for process skills, flexible options for tool skills. Mismatched calibration (too rigid or too loose) reduces score.
Rich activation keywords and trigger scenarios in the description so the skill fires when needed. Best descriptions read like an exhaustive list of the tasks and concepts that should invoke this skill.
Copy-paste-ready code, complete runnable examples, real file paths and commands. Pseudocode and abstract descriptions score low — concrete, executable content scores high.
Runtime validation via eval scenarios proving the skill actually changes agent behaviour. Requires evals/ directory, instructions.json, ≥3 scenarios, and ≥80% instruction coverage in summary.json.
Expert-only knowledge the AI couldn't derive on its own — domain-specific patterns, production gotchas, decision frameworks, and non-obvious tool behaviour. High scores mean <5% redundancy with what the model already knows.
A clear philosophy plus numbered step-by-step workflows with explicit entry/exit points. Should answer: what is the core principle, how to execute it, and when (and when not) to apply it.
Explicit NEVER/WHY/consequence triplets with side-by-side bad/good examples. Generic warnings score low — concrete failure modes with real impact (security, correctness, performance) score high.
Proper frontmatter, single-task focus, activation keywords, and cross-harness portability. Skills must work across 40+ agentic harnesses without hardcoded paths or agent-specific references.
SKILL.md as a <100-line navigation hub pointing to focused references/ files. Content should be lazy-loaded on demand, not front-loaded. Includes actionable 'When to Use' conditions per reference.
Appropriate rigidity for the skill type: strict rules for critical/security skills, balanced steps for process skills, flexible options for tool skills. Mismatched calibration (too rigid or too loose) reduces score.
Rich activation keywords and trigger scenarios in the description so the skill fires when needed. Best descriptions read like an exhaustive list of the tasks and concepts that should invoke this skill.
Copy-paste-ready code, complete runnable examples, real file paths and commands. Pseudocode and abstract descriptions score low — concrete, executable content scores high.
Runtime validation via eval scenarios proving the skill actually changes agent behaviour. Requires evals/ directory, instructions.json, ≥3 scenarios, and ≥80% instruction coverage in summary.json.
No eval scenarios available.
Command Patterns Reference
Common patterns, creation workflow, and example commands for OpenCode slash commands.
Creation Workflow
Command creation is conversational, not transactional.
- MUST NOT assume what the user wants — ask
- SHOULD start simple, add complexity only if needed
- MUST show drafts and iterate based on feedback
Phase 1: Understand the Task
-
“What task do you want to automate?”
- Get the repetitive prompt/workflow
- Examples: “run tests”, “review this file”, “create a component”
-
“Can you show me how you’d normally ask for this?”
- Get the actual prompt they’d type
- This becomes the template body
Phase 2: Inputs & Routing
-
“Does it need arguments?”
- If they mention “this file”, “a name”, “the function” → yes
/command foo bar→$ARGUMENTS= “foo bar”,$1= “foo”,$2= “bar”
-
“Should it make changes or just analyze?”
- Changes → default agent (build)
- Analysis only → set
agent: plan
-
“Should it run as a background subtask?”
- Long-running or parallel work → set
subtask: true - Interactive or quick → leave unset
- Long-running or parallel work → set
-
“Project-specific or use everywhere?”
- Project →
.opencode/commands/ - Global →
~/.config/opencode/commands/
- Project →
Phase 3: Review & Refine
- Show the draft command, ask for feedback
- Iterate until user is satisfied
Be flexible: If user provides lots of info upfront, adapt — MUST NOT rigidly ask every question.
Command File Format
---
description: 3-word command summary
agent: build # Optional: build, plan, or custom agent
model: provider/model-id # Optional: override model
subtask: true # Optional: run as subagent
---
<summary>
Line 1: You MUST [purpose].
Line 2: You SHOULD [inputs].
Line 3: You MUST [outcome].
</summary>
<user_guidelines>
$ARGUMENTS
</user_guidelines>
Template body goes here.
Frontmatter Options
| Field | Purpose | Required |
|---|---|---|
description |
Shown in command list | Recommended |
agent |
Route to specific agent | No |
model |
Override model | No |
subtask |
Force subagent invocation | No |
Command Locations
| Scope | Path |
|---|---|
| Project | .opencode/commands/<name>.md |
| Global | ~/.config/opencode/commands/<name>.md |
Example Commands
/test — Run Tests and Fix Failures
---
description: Run tests and fix failures
---
<summary>
You MUST run the full test suite.
You SHOULD identify and fix failures.
You MUST re-verify fixes.
</summary>
<objective>
You MUST run the full test suite, find the root cause of any failures, and fix the issue.
</objective>
1. Show the failing test
2. Identify the root cause
3. Fix the issue
4. Re-run to verify
/review — Code Review (Read-Only)
---
description: Review code for issues
agent: plan
---
<summary>
You MUST review $ARGUMENTS for issues.
You SHOULD check for bugs, security, and performance.
You MUST provide actionable feedback.
</summary>
<target>
$ARGUMENTS
</target>
<objective>
You MUST review the file above for bugs, security, and performance issues and provide actionable feedback without making changes.
</objective>
/commit — Smart Commit with Conventional Prefix
---
description: Stage and commit with conventional prefix
---
<summary>
You MUST analyze changes and stage files.
You SHOULD choose a conventional commit prefix.
You MUST commit with a concise message.
</summary>
<context>
!`git status`
!`git diff`
</context>
<objective>
You MUST analyze changes, stage relevant files, and commit with a concise message.
</objective>
1. Analyze all changes
2. Choose appropriate prefix: docs:, feat:, fix:, refactor:, test:, ci:
3. Write concise commit message (imperative mood)
4. Stage relevant files and commit
/spellcheck — Check Spelling in Markdown
---
description: Check spelling in markdown files
subtask: true
---
<summary>
You MUST find unstaged markdown files.
You SHOULD check them for spelling errors.
You MUST report any found errors.
</summary>
<context>
!`git diff --name-only | grep -E '\.md$'`
</context>
<objective>
You MUST check for and report any spelling errors found in unstaged markdown files.
</objective>
/issues — Search GitHub Issues
---
description: Search GitHub issues
model: anthropic/claude-3-5-haiku-20241022
subtask: true
---
<summary>
You MUST search GitHub issues for $ARGUMENTS.
You SHOULD limit results to the top 10.
You MUST summarize the relevant issues.
</summary>
<context>
!`gh issue list --search "$ARGUMENTS" --limit 10`
</context>
<objective>
You MUST summarize the top 10 relevant GitHub issues found for $ARGUMENTS.
</objective>
/component — Create React Component
---
description: Create a new React component
---
<summary>
You MUST create a React component named $1.
You SHOULD include TypeScript props and basic styling.
You MUST provide a unit test file.
</summary>
<objective>
You MUST create a React component named $1 in $2 with TypeScript props interface, basic styling, and a unit test file.
</objective>
Usage: /component UserProfile src/components
/migrate — Database Migration
---
description: Generate database migration
---
<summary>
You MUST read the Prisma schema.
You SHOULD generate a migration for $ARGUMENTS.
You MUST ensure the migration matches the schema.
</summary>
<context>
@prisma/schema.prisma
</context>
<objective>
You MUST generate a Prisma migration for $ARGUMENTS that matches the provided schema.
</objective>
Shell Commands in Templates
Use the !cmd syntax to inject bash output:
Review recent changes:
!`git log --oneline -10`
Suggest improvements.
File References
Use @ to include file content:
Given the schema in @prisma/schema.prisma, generate a migration for $ARGUMENTS.
Pattern: Analysis Command (Read-Only)
Use agent: plan for commands that should never modify files.
---
description: Analyze code quality
agent: plan
---
<summary>
You MUST analyze $ARGUMENTS for code quality issues.
You SHOULD check for bugs, security issues, and anti-patterns.
You MUST provide a prioritized list of improvements.
</summary>
<target>
$ARGUMENTS
</target>
<objective>
Provide actionable feedback without making any changes.
</objective>
Pattern: Fire-and-Forget (Background Task)
Use subtask: true for tasks that run independently and produce a single output.
---
description: Generate test coverage report
subtask: true
model: anthropic/claude-3-5-haiku-20241022
---
<summary>
You MUST generate a test coverage report.
You SHOULD identify untested code paths.
You MUST output a markdown summary.
</summary>
<context>
!`npm run test -- --coverage --json 2>/dev/null | tail -100`
</context>
<objective>
Analyze coverage and produce a markdown report of untested paths.
</objective>
Pattern: Contextual Command (Dynamic Injection)
Use !cmd to inject live shell output and @file for file content.
---
description: Review recent changes
---
<summary>
You MUST review recent git changes.
You SHOULD identify potential issues or improvements.
You MUST provide actionable feedback.
</summary>
<context>
!`git log --oneline -10`
!`git diff HEAD~5`
</context>
<objective>
Review the changes above and provide specific, actionable feedback.
</objective>
Pattern: Multi-Argument Command
Use $1, $2 when two distinct pieces of information are needed.
---
description: Migrate component to new pattern
---
<summary>
You MUST migrate $1 from $2 pattern to the new pattern.
You SHOULD preserve existing behavior.
You MUST run tests after migration.
</summary>
<target>
Component: $1
From pattern: $2
</target>
<objective>
Perform the migration and verify tests still pass.
</objective>
Usage: /migrate UserCard class-component
Pattern: Scope-Limited Command
Use @file references to constrain context to relevant files.
---
description: Generate API client from schema
---
<summary>
You MUST generate a TypeScript API client.
You SHOULD follow patterns in existing client code.
You MUST export typed functions for each endpoint.
</summary>
<schema>
@openapi.yaml
</schema>
<existing_client>
@src/api/client.ts
</existing_client>
<objective>
Generate TypeScript functions for each endpoint following existing patterns.
</objective>
Decision Guide: Which Pattern to Use
| Requirement | Pattern | Key Setting |
|---|---|---|
| Read-only analysis | Analysis | agent: plan |
| Background processing | Fire-and-forget | subtask: true |
| Needs live data | Contextual | !cmd injection |
| Two input variables | Multi-argument | $1, $2 |
| Schema or config driven | Scope-limited | @file reference |
| Default (interactive) | None | Omit all flags |
Naming Conventions
| Command Name | Convention | Example |
|---|---|---|
File → /filename |
Kebab-case | code-review.md → /code-review |
| Short action verbs | Prefer imperative | /test, /review, /deploy |
| Qualified actions | Noun-verb | /db-migrate, /api-generate |
Best Practices Summary
- Single responsibility — One command does one thing
- Use XML blocks — Separate objectives, context, and user input
- Inject, don’t hardcode —
!cmdfor dynamic data,@filefor configs - Match agent to purpose —
planfor analysis, default for changes - Start with
$ARGUMENTS— Only use$1/$2when order matters
Frontmatter and Placeholder Reference
Complete reference for command file frontmatter fields and template placeholders.
Frontmatter Fields
---
description: "Short summary shown in /help list" # RECOMMENDED
agent: build # Optional: build | plan | <custom-agent-name>
model: provider/model-id # Optional: override default model
subtask: true # Optional: run as background subagent
---
description
Shown in the /help command list. Write as a 3-7 word imperative phrase.
Good: Run tests and fix failures
Bad: This command runs tests
agent
Routes the command to a specific agent:
| Value | Behavior |
|---|---|
| (omitted) | Default build agent — can read, write, execute |
build |
Explicit build agent — same as default |
plan |
Read-only analysis agent — cannot modify files |
<name> |
Any named agent from .opencode/agent/<name>.md |
Rule: Use agent: plan whenever the command should never write files.
model
Overrides the default model for this command only.
model: anthropic/claude-3-5-haiku-20241022 # Fast, cheap — for simple tasks
model: anthropic/claude-sonnet-4-5-20250514 # Balanced
model: openai/gpt-4o # Alternative provider
Use a cheaper/faster model for subtasks that don’t need full reasoning.
subtask
When true, the command runs as a background subagent:
- Does NOT show intermediate messages
- Returns a single final output
- Cannot interact with the user during execution
Use for: lint checks, spell checks, coverage reports, search tasks. Do NOT use for: step-by-step workflows, anything requiring user input.
Template Placeholders
$ARGUMENTS
Everything passed after the command name, as a single string.
/review src/api.ts --depth=deep
→ $ARGUMENTS = "src/api.ts --depth=deep"
Rules:
- Use ONCE per template (not repeated)
- Wrap in an XML block to keep objective clean
- Use when argument structure doesn’t matter
$1, $2, $3
Positional arguments split by whitespace.
/migrate UserCard class-component
→ $1 = "UserCard", $2 = "class-component"
Use when: You need to distinguish two independent inputs (e.g., source and target).
!cmd
Injects the output of a shell command at template load time.
!`git log --oneline -20`
!`git status`
!`cat package.json | jq .dependencies`
Rules:
- Backtick-wrapped command:
!`command` - Executes in the current project directory
- Output is injected inline before the agent sees the prompt
- Use for: git state, file listings, environment info, build output
@filename
Injects the full content of a file.
@src/schema.ts
@prisma/schema.prisma
@.env.example
Rules:
- Path relative to project root
- Content injected inline
- Use for: schemas, configs, reference files the agent needs
XML Block Conventions
The recommended template structure uses XML blocks to organize content:
| Block | Purpose |
|---|---|
<summary> |
3-line MUST/SHOULD/MUST summary of intent |
<context> |
Dynamic data injected via !cmd or @file |
<target> |
User-provided input ($ARGUMENTS, $1, $2) |
<objective> |
Explicit success condition for the agent |
<constraints> |
What NOT to do (optional) |
Template Skeleton
---
description: Do the thing
---
<summary>
You MUST [primary action].
You SHOULD [secondary action].
You MUST [success condition].
</summary>
<context>
!`some-command`
@some/file.ts
</context>
<target>
$ARGUMENTS
</target>
<objective>
You MUST accomplish [goal] using the context and target above.
</objective>