anomalyco/opencode
1
0
Fork 0
mirror of https://github.com/anomalyco/opencode.git synced 2026-07-22 02:05:26 -04:00
Code Issues 5.9k Packages Projects Releases 19 Wiki Activity

[feat] custom slash commands #216

New Issue
Closed
opened 2026-02-16 17:25:47 -05:00 by yindo · 22 comments
yindo commented 2026-02-16 17:25:47 -05:00
Owner
Copy Link
Copy Source

Originally created by @monotykamary on GitHub (Jun 21, 2025).

Originally assigned to: @tmeire, @adamdotdevin on GitHub.

There's an opportunity to add support for custom slash commands similar to Claude Code's slash command system, allowing users to create reusable prompts and workflows as markdown files.

Background

Currently, opencode has a keybinding-based command system with built-in triggers (like /help, /new, /sessions), but lacks the ability to create custom slash commands. Claude Code provides a powerful slash command system that allows users to:

  • Create custom commands as .md files
  • Support both project-level and personal commands
  • Use dynamic arguments and bash execution
  • Reference files directly in commands

Proposed Feature

Custom Slash Commands

Allow users to create custom slash commands by placing .md files in:

  • Project commands: .opencode/commands/*.md (shared with team)
  • Personal commands: ~/.opencode/commands/*.md (user-specific)

Command Syntax

/project:<command-name> [arguments]
/user:<command-name> [arguments]

Command File Format

Commands would be markdown files with optional YAML frontmatter:

---
description: "Analyze code for performance issues"
allowed-tools: ["bash", "read", "edit"]
---

Analyze this code for performance issues and suggest optimizations:

$ARGUMENTS

Key Features

  1. Namespacing: Support subdirectories for organization

    • .opencode/commands/frontend/component.md → /project:frontend:component

  2. Dynamic Arguments: Use $ARGUMENTS placeholder for user input

    # Usage: /project:fix-issue 123
# Command: Fix issue #$ARGUMENTS following our coding standards

  3. Bash Command Execution: Execute bash commands with ! prefix

    ## Context
- Current git status: !`git status`
- Recent commits: !`git log --oneline -10`

  4. File References: Include file contents with @ prefix

    Review the implementation in @src/utils/helpers.js
Compare @src/old-version.js with @src/new-version.js

Implementation Plan

1. Command File System

  • Create command directory scanning logic
  • Support both .opencode/commands/ (project) and ~/.opencode/commands/ (user)
  • Parse markdown files with YAML frontmatter

2. Command Parser

  • Extend existing completion system in packages/tui/internal/completions/
  • Add custom command discovery and parsing
  • Support namespaced command syntax

3. Command Execution Engine

  • Extend command registry in packages/tui/internal/commands/command.go
  • Implement dynamic command registration from files
  • Add argument substitution ($ARGUMENTS)
  • Add bash execution support (! prefix)
  • Add file reference support (@ prefix)

4. Integration Points

  • Modify chat editor to handle custom slash commands
  • Update completion provider to include custom commands
  • Extend command execution logic in TUI

Benefits

  1. Improved Workflow: Users can create reusable prompts for common tasks
  2. Team Collaboration: Project-level commands can be shared via version control
  3. Consistency: Standardize common workflows across team members
  4. Flexibility: Support for dynamic arguments and file references
  5. Extensibility: Easy to add new commands without code changes

Examples

Project Command: Code Review

.opencode/commands/review.md:

---
description: "Perform code review with context"
---

## Context
- Current branch: !`git branch --show-current`
- Modified files: !`git diff --name-only`

## Task
Review the following changes for:
- Code quality and best practices
- Security vulnerabilities
- Performance implications

$ARGUMENTS

Usage: /project:review Please focus on the authentication logic

Personal Command: Quick Fix

~/.opencode/commands/quickfix.md:

---
description: "Quick bug fix with standard format"
---

Fix the following issue following our coding standards:

Issue: $ARGUMENTS

Please:
1. Identify the root cause
2. Implement a minimal fix
3. Add appropriate tests
4. Update documentation if needed

Usage: /user:quickfix Button click handler not working on mobile

Related Work

This feature is inspired by Claude Code's slash command system, which provides similar functionality. The implementation would leverage opencode's existing command and completion infrastructure.

Acceptance Criteria

  • Support creating custom commands via .md files
  • Implement project-level (.opencode/commands/) and user-level (~/.opencode/commands/) command directories
  • Support namespaced commands via subdirectories
  • Implement $ARGUMENTS placeholder for dynamic content
  • Support bash command execution with ! prefix
  • Support file references with @ prefix
  • Integrate with existing completion system
  • Commands appear in / completion dropdown
  • Maintain backward compatibility with existing command system
Originally created by @monotykamary on GitHub (Jun 21, 2025). Originally assigned to: @tmeire, @adamdotdevin on GitHub. There's an opportunity to add support for custom slash commands similar to [Claude Code's slash command system](https://docs.anthropic.com/en/docs/claude-code/slash-commands), allowing users to create reusable prompts and workflows as markdown files. ## Background Currently, `opencode` has a keybinding-based command system with built-in triggers (like `/help`, `/new`, `/sessions`), but lacks the ability to create custom slash commands. Claude Code provides a powerful slash command system that allows users to: - Create custom commands as `.md` files - Support both project-level and personal commands - Use dynamic arguments and bash execution - Reference files directly in commands ## Proposed Feature ### Custom Slash Commands Allow users to create custom slash commands by placing `.md` files in: - **Project commands**: `.opencode/commands/*.md` (shared with team) - **Personal commands**: `~/.opencode/commands/*.md` (user-specific) ### Command Syntax ``` /project:<command-name> [arguments] /user:<command-name> [arguments] ``` ### Command File Format Commands would be markdown files with optional YAML frontmatter: ```markdown --- description: "Analyze code for performance issues" allowed-tools: ["bash", "read", "edit"] --- Analyze this code for performance issues and suggest optimizations: $ARGUMENTS ``` ### Key Features 1. **Namespacing**: Support subdirectories for organization - `.opencode/commands/frontend/component.md` → `/project:frontend:component` 2. **Dynamic Arguments**: Use `$ARGUMENTS` placeholder for user input ```bash # Usage: /project:fix-issue 123 # Command: Fix issue #$ARGUMENTS following our coding standards ``` 3. **Bash Command Execution**: Execute bash commands with `!` prefix ```markdown ## Context - Current git status: !`git status` - Recent commits: !`git log --oneline -10` ``` 4. **File References**: Include file contents with `@` prefix ```markdown Review the implementation in @src/utils/helpers.js Compare @src/old-version.js with @src/new-version.js ``` ## Implementation Plan ### 1. Command File System - Create command directory scanning logic - Support both `.opencode/commands/` (project) and `~/.opencode/commands/` (user) - Parse markdown files with YAML frontmatter ### 2. Command Parser - Extend existing completion system in `packages/tui/internal/completions/` - Add custom command discovery and parsing - Support namespaced command syntax ### 3. Command Execution Engine - Extend command registry in `packages/tui/internal/commands/command.go` - Implement dynamic command registration from files - Add argument substitution (`$ARGUMENTS`) - Add bash execution support (`!` prefix) - Add file reference support (`@` prefix) ### 4. Integration Points - Modify chat editor to handle custom slash commands - Update completion provider to include custom commands - Extend command execution logic in TUI ## Benefits 1. **Improved Workflow**: Users can create reusable prompts for common tasks 2. **Team Collaboration**: Project-level commands can be shared via version control 3. **Consistency**: Standardize common workflows across team members 4. **Flexibility**: Support for dynamic arguments and file references 5. **Extensibility**: Easy to add new commands without code changes ## Examples ### Project Command: Code Review `.opencode/commands/review.md`: ```markdown --- description: "Perform code review with context" --- ## Context - Current branch: !`git branch --show-current` - Modified files: !`git diff --name-only` ## Task Review the following changes for: - Code quality and best practices - Security vulnerabilities - Performance implications $ARGUMENTS ``` Usage: `/project:review Please focus on the authentication logic` ### Personal Command: Quick Fix `~/.opencode/commands/quickfix.md`: ```markdown --- description: "Quick bug fix with standard format" --- Fix the following issue following our coding standards: Issue: $ARGUMENTS Please: 1. Identify the root cause 2. Implement a minimal fix 3. Add appropriate tests 4. Update documentation if needed ``` Usage: `/user:quickfix Button click handler not working on mobile` ## Related Work This feature is inspired by Claude Code's slash command system, which provides similar functionality. The implementation would leverage opencode's existing command and completion infrastructure. ## Acceptance Criteria - [ ] Support creating custom commands via `.md` files - [ ] Implement project-level (`.opencode/commands/`) and user-level (`~/.opencode/commands/`) command directories - [ ] Support namespaced commands via subdirectories - [ ] Implement `$ARGUMENTS` placeholder for dynamic content - [ ] Support bash command execution with `!` prefix - [ ] Support file references with `@` prefix - [ ] Integrate with existing completion system - [ ] Commands appear in `/` completion dropdown - [ ] Maintain backward compatibility with existing command system
yindo closed this issue 2026-02-16 17:25:47 -05:00
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@adamdotdevin commented on GitHub (Jun 22, 2025):

if anyone wants to take a stab at this, please let me know here. we can use a modal for custom command args, but i wonder if we could just support them inline in the editor textarea, like:

> /project:fix-issue 113

would be cool to avoid all the complexity of the modal

@adamdotdevin commented on GitHub (Jun 22, 2025): if anyone wants to take a stab at this, please let me know here. we can use a modal for custom command args, but i wonder if we could just support them inline in the editor textarea, like: ``` > /project:fix-issue 113 ``` would be cool to avoid all the complexity of the modal
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@tmeire commented on GitHub (Jun 22, 2025):

if anyone wants to take a stab at this, please let me know here. we can use a modal for custom command args, but i wonder if we could just support them inline in the editor textarea, like:

> /project:fix-issue 113

would be cool to avoid all the complexity of the modal

@adamdotdevin can you assign it to me? I'll take a stab at this tomorrow.

@tmeire commented on GitHub (Jun 22, 2025): > if anyone wants to take a stab at this, please let me know here. we can use a modal for custom command args, but i wonder if we could just support them inline in the editor textarea, like: > > ``` > > /project:fix-issue 113 > ``` > > would be cool to avoid all the complexity of the modal @adamdotdevin can you assign it to me? I'll take a stab at this tomorrow.
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@pattobrien commented on GitHub (Jun 23, 2025):

It'd be awesome if the main implementation for custom commands used the MCP Prompt primitive.

@pattobrien commented on GitHub (Jun 23, 2025): It'd be awesome if the main implementation for custom commands used the MCP `Prompt` primitive.
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@tmeire commented on GitHub (Jun 25, 2025):

@thdxr @adamdotdevin I've implemented the basics (but majority) of this ticket in PR #385 . Would love some feedback on the general direction & some thoughts on how you would implement bash & file references support.

The main functionality is implemented on the server side to make sure it's available on future clients without effort.

  • prompts are passed to the tui using the config endpoint
  • prompts are then injected into the command list
  • after completion, the command is injected into the textarea to allow for additional arguments
  • the command with arguments are send to the server
  • the server translates the command to the stored prompt

Things where the implementation differs from the OP:

  • User commands are stored in ~/.local/opencode as per xdg
  • Allowed tools are parsed from the md files, but not used yet
  • Bash execution and file references are not implemented yet
  • It doesn't use the MCP prompts; the general support for those looks very weak at best
@tmeire commented on GitHub (Jun 25, 2025): @thdxr @adamdotdevin I've implemented the basics (but majority) of this ticket in PR #385 . Would love some feedback on the general direction & some thoughts on how you would implement bash & file references support. The main functionality is implemented on the server side to make sure it's available on future clients without effort. * prompts are passed to the tui using the config endpoint * prompts are then injected into the command list * after completion, the command is injected into the textarea to allow for additional arguments * the command with arguments are send to the server * the server translates the command to the stored prompt Things where the implementation differs from the OP: * User commands are stored in `~/.local/opencode` as per xdg * Allowed tools are parsed from the md files, but not used yet * Bash execution and file references are not implemented yet * It doesn't use the MCP prompts; the general support for those looks very weak at best
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@ezynda3 commented on GitHub (Jun 25, 2025):

Would it be possible to have named args just like we had before the refactor? https://github.com/sst/opencode/pull/13/commits/56160f80f3c1e675b164194fde42b05ed0e55794

@ezynda3 commented on GitHub (Jun 25, 2025): Would it be possible to have named args just like we had before the refactor? https://github.com/sst/opencode/pull/13/commits/56160f80f3c1e675b164194fde42b05ed0e55794
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@syabro commented on GitHub (Jun 26, 2025):

/project:frontend:component
Do we really need project/user prefixes? It's a huge downside for UX
I want to type /com and get /commit suggestion. I don't want to type /project:com

@syabro commented on GitHub (Jun 26, 2025): `/project:frontend:component` Do we really need `project`/`user` prefixes? It's a huge downside for UX I want to type `/com` and get `/commit` suggestion. I don't want to type `/project:com`
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@adamdotdevin commented on GitHub (Jun 26, 2025):

/project:frontend:component
Do we really need project/user prefixes? It's a huge downside for UX
I want to type /com and get /commit suggestion. I don't want to type /project:com

fwiw, the fuzzy matching should still allow you to match "com" in that example, but i've also thought it'd be nice to drop this distinction (even if only for aesthetic purposes)

@adamdotdevin commented on GitHub (Jun 26, 2025): > `/project:frontend:component` > Do we really need `project`/`user` prefixes? It's a huge downside for UX > I want to type `/com` and get `/commit` suggestion. I don't want to type `/project:com` > fwiw, the fuzzy matching should still allow you to match "com" in that example, but i've also thought it'd be nice to drop this distinction (even if only for aesthetic purposes)
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@seflue commented on GitHub (Jul 5, 2025):

It would be great, if I could refer to my existing claude-code slash-commands or github prompt files like the custom instructions.

Regarding the namespacing: In claude-code this namespacing is just a convention. Files are matched directly but there is no working auto completion for namespaces. The lookup is somehow fuzzy, if the command file was not found, the LLM tries to find it using file system tools. What I would prefer, if the namespaced commands are actually discovered and I can then just fuzzy match, like OpenCode already does. So it is primarily a matter of discovery and presentation within a list. Namespaces would be great, because then I could define stuff like /idea:new or /feat:new. I have this already in my slash commands in claude-code, but the ergonomics are far from ideal, because the autocompletion, although it matches the relevant commands doesn't show the namespaces. This is something, where I see some potential for OpenCode to provide a better user experience.

@seflue commented on GitHub (Jul 5, 2025): It would be great, if I could refer to my existing claude-code slash-commands or github prompt files like the [custom instructions](https://opencode.ai/docs/rules/#custom-instructions). Regarding the namespacing: In claude-code this namespacing is just a convention. Files are matched directly but there is no working auto completion for namespaces. The lookup is somehow fuzzy, if the command file was not found, the LLM tries to find it using file system tools. What I would prefer, if the namespaced commands are actually discovered and I can then just fuzzy match, like OpenCode already does. So it is primarily a matter of discovery and presentation within a list. Namespaces would be great, because then I could define stuff like `/idea:new` or `/feat:new`. I have this already in my slash commands in claude-code, but the ergonomics are far from ideal, because the autocompletion, although it matches the relevant commands doesn't show the namespaces. This is something, where I see some potential for OpenCode to provide a better user experience.
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@ll931217 commented on GitHub (Jul 5, 2025):

I really want this in OpenCode, so I took the initiative, I am really new to golang. Got the basics working. Took me a while to wrap my head around the packages.

I was able to add fuzzy find on my commands, I am able to supply arguments to the command file. Here is the code if anyone wants to try it out.

I want to first test the code some more and fix up where there is issues.

@ll931217 commented on GitHub (Jul 5, 2025): I really want this in OpenCode, so I took the initiative, I am really new to golang. Got the basics working. Took me a while to wrap my head around the packages. I was able to add fuzzy find on my commands, I am able to supply arguments to the command file. [Here](https://github.com/ll931217/opencode/tree/custom-slash-command) is the code if anyone wants to try it out. I want to first test the code some more and fix up where there is issues.
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@KP-Jaco commented on GitHub (Jul 11, 2025):

Huge +1 to this. I have a lot of custom slash commands set up in claude code so this would really close the loop.

@KP-Jaco commented on GitHub (Jul 11, 2025): Huge +1 to this. I have a lot of custom slash commands set up in claude code so this would really close the loop.
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@hujianxin commented on GitHub (Jul 30, 2025):

I'm really looking forward to this feature. It will bring about huge changes.

@hujianxin commented on GitHub (Jul 30, 2025): I'm really looking forward to this feature. It will bring about huge changes.
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@thoroc commented on GitHub (Aug 12, 2025):

Would be nice to have so we can use the bmad method.

@thoroc commented on GitHub (Aug 12, 2025): Would be nice to have so we can use the [bmad method](https://github.com/bmad-code-org/BMAD-METHOD).
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@monotykamary commented on GitHub (Aug 12, 2025):

apologies, I read that as the "be mad" method

@monotykamary commented on GitHub (Aug 12, 2025): apologies, I read that as the "be mad" method
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@fettpl commented on GitHub (Aug 18, 2025):

@thdxr @jayair Is there any solid plan for this feature? There's a statement in https://github.com/sst/opencode/pull/707 regarding you bringing it to internal discussion, but no follow-up.

@fettpl commented on GitHub (Aug 18, 2025): @thdxr @jayair Is there any solid plan for this feature? There's a statement in https://github.com/sst/opencode/pull/707 regarding you bringing it to internal discussion, but no follow-up.
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@jayair commented on GitHub (Aug 18, 2025):

Yeah we are hoping to get to it this week.

@jayair commented on GitHub (Aug 18, 2025): Yeah we are hoping to get to it this week.
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@ndrwstn commented on GitHub (Aug 27, 2025):

Probably can close this issue --> #2157 ?

@ndrwstn commented on GitHub (Aug 27, 2025): Probably can close this issue --> #2157 ?
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@martinffx commented on GitHub (Nov 12, 2025):

@jayair would you be open to a PR add command namespaces like you get in Claude Code?

https://code.claude.com/docs/en/slash-commands#namespacing

@martinffx commented on GitHub (Nov 12, 2025): @jayair would you be open to a PR add command namespaces like you get in Claude Code? https://code.claude.com/docs/en/slash-commands#namespacing
yindo commented 2026-02-16 17:25:48 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 12, 2025):

@martinffx how would that work given the current way slash commands are read from subdirs of commands dir

@rekram1-node commented on GitHub (Nov 12, 2025): @martinffx how would that work given the current way slash commands are read from subdirs of commands dir
yindo commented 2026-02-16 17:25:49 -05:00
Author
Owner
Copy Link
Copy Source

@martinffx commented on GitHub (Nov 12, 2025):

@rekram1-node idk, I've not looked into it yet.

I am checking that contributions like that are welcome, as a community contribution of commands was rejected, and I'm not sure what sort of contributions you are open to.

@martinffx commented on GitHub (Nov 12, 2025): @rekram1-node idk, I've not looked into it yet. I am checking that contributions like that are welcome, as a community contribution of commands was rejected, and I'm not sure what sort of contributions you are open to.
yindo commented 2026-02-16 17:25:49 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 12, 2025):

@martinffx so we accept a lottt of contributions, this was originally rejected a while ago because so many things were in flux and the team wanted to get the baseline apis and blocks to build with to a consistent state.

Now that we are in a better state almost any contirbution is welcome we just prefer if it is a huge change to ask questions before making huge prs.

But this doesnt sound like a huge change to me I just wanted to clarify

@rekram1-node commented on GitHub (Nov 12, 2025): @martinffx so we accept a lottt of contributions, this was originally rejected a while ago because so many things were in flux and the team wanted to get the baseline apis and blocks to build with to a consistent state. Now that we are in a better state almost any contirbution is welcome we just prefer if it is a huge change to ask questions before making huge prs. But this doesnt sound like a huge change to me I just wanted to clarify
yindo commented 2026-02-16 17:25:49 -05:00
Author
Owner
Copy Link
Copy Source

@martinffx commented on GitHub (Nov 12, 2025):

@rekram1-node ok, I understand. Just wanted to confirm that was not still the case before getting stuck into something.

So it looks like my issue is not really an issue anymore. When porting over my commands from CC back in August, none of my commands in subfolders would be read. It seems that it has been resolved since; command/code/review.md will be picked up as /code/review now.

Which is basically what I wanted, still think CC's namespaces are a little more elegant, i.e. /code:review. But that is more of an aesthetic preference than a functional limitation.

@martinffx commented on GitHub (Nov 12, 2025): @rekram1-node ok, I understand. Just wanted to confirm that was not still the case before getting stuck into something. So it looks like my issue is not really an issue anymore. When porting over my commands from CC back in August, none of my commands in subfolders would be read. It seems that it has been resolved since; `command/code/review.md` will be picked up as `/code/review` now. Which is basically what I wanted, still think CC's namespaces are a little more elegant, i.e. `/code:review`. But that is more of an aesthetic preference than a functional limitation.
yindo commented 2026-02-16 17:25:49 -05:00
Author
Owner
Copy Link
Copy Source

@rekram1-node commented on GitHub (Nov 12, 2025):

Sounds good, if u still want the namespaces we can probably add them I just worry about breaking workflows so I'd need to see what the change would encompass

@rekram1-node commented on GitHub (Nov 12, 2025): Sounds good, if u still want the namespaces we can probably add them I just worry about breaking workflows so I'd need to see what the change would encompass
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
acp
bad
bug
discussion
docs
documentation
enhancement
extension
good first issue
growth
help-wanted
mcp
model-problem
needs:compliance
nix
opentui
perf
pull-request
Mirrored from GitHub Pull Request
 tui
web
windows
zen
No Label
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
yindo
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#216
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?