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

[FEATURE]: droid-like custom slash commands in arbitrary languages using shebang lines #3168

New Issue
Open
opened 2026-02-16 17:38:56 -05:00 by yindo · 6 comments
yindo commented 2026-02-16 17:38:56 -05:00
Owner
Copy Link
Copy Source

Originally created by @ariane-emory on GitHub (Nov 27, 2025).

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Factory's droid tool supports using files containing shebang lines to write custom slash commands in arbitrary interpreted languages, see: https://docs.factory.ai/cli/configuration/custom-slash-commands#3-%C2%B7-executable-commands

The basic gist of the idea is that if we had this feature, a file like ./opencode/command/command.py, so long as it started with a #!/usr/bin/env python shebang line, would then show up in the opencode as a /command command, and would run a Python script that would generate the output that was sent to the model.

Being able to write custom commands in any interpreted language that supported being executed from files with shebang lines (i.e, very nearly all of them, including all of the most popular ones and even theoretical future languages that don't exist yet) would potentially provide a lot of power and flexibility.

Now, there are other things about droid that I didn't much care for - that's why I'm staying over here with Team Opencode instead of becoming a droid user - but that particular feature sounds pretty killer, it'd be amazing if we implemented something similar.

Originally created by @ariane-emory on GitHub (Nov 27, 2025). ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request Factory's droid tool supports using files containing shebang lines to write custom slash commands in arbitrary interpreted languages, see: https://docs.factory.ai/cli/configuration/custom-slash-commands#3-%C2%B7-executable-commands The basic gist of the idea is that if we had this feature, a file like `./opencode/command/command.py`, so long as it started with a `#!/usr/bin/env python` shebang line, would then show up in the opencode as a `/command` command, and would run a Python script that would generate the output that was sent to the model. Being able to write custom commands in any interpreted language that supported being executed from files with shebang lines (i.e, very nearly all of them, including all of the most popular ones and even theoretical future languages that don't exist yet) would potentially provide a *lot* of power and flexibility. Now, there are other things about droid that I didn't much care for - that's why I'm staying over here with Team Opencode instead of becoming a droid user - but that particular feature sounds pretty killer, it'd be amazing if we implemented something similar.
yindo added the discussion label 2026-02-16 17:38:56 -05:00
yindo commented 2026-02-16 17:38:56 -05:00
Author
Owner
Copy Link
Copy Source

@github-actions[bot] commented on GitHub (Nov 27, 2025):

This issue might be a duplicate of existing issues. Please check:

  • #299: [feat] custom slash commands - A comprehensive feature proposal for custom slash commands supporting .md files with bash execution and file references
  • #4726: [FEATURE]: Augment custom tools with an optional install hook - Related feature for extending custom tools to support dependencies and different languages
  • #2718: Support metadata and output format in custom tools - Addresses the need for custom tools to support more flexible output formats beyond strings
  • #2185: Hooks for commands (Plugin Commands) - Proposes a hooks system for commands that could enable custom command behavior

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Nov 27, 2025): This issue might be a duplicate of existing issues. Please check: - #299: [feat] custom slash commands - A comprehensive feature proposal for custom slash commands supporting .md files with bash execution and file references - #4726: [FEATURE]: Augment custom tools with an optional `install` hook - Related feature for extending custom tools to support dependencies and different languages - #2718: Support metadata and output format in custom tools - Addresses the need for custom tools to support more flexible output formats beyond strings - #2185: Hooks for commands (Plugin Commands) - Proposes a hooks system for commands that could enable custom command behavior Feel free to ignore if none of these address your specific case.
yindo commented 2026-02-16 17:38:57 -05:00
Author
Owner
Copy Link
Copy Source

@JunarisAlf commented on GitHub (Nov 27, 2025):

Isn't it already there?
https://opencode.ai/docs/commands/#shell-output

Add this to the command markdown !python3 path/to/script.py

@JunarisAlf commented on GitHub (Nov 27, 2025): Isn't it already there? https://opencode.ai/docs/commands/#shell-output Add this to the command markdown !`python3 path/to/script.py`
yindo commented 2026-02-16 17:38:57 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Nov 28, 2025):

@JunarisAlf Shell expansions in the Markdown files can let you achieve somewhat similar things, but it's slightly more cumbersome since you need to maintain both an .md file and a .py (or whatever other language) file instead of being to do it all in a single .py (or whatever) file.

Personally, I feel that it would be more ergonomic and provide a better DevX for custom command authors if they could do it all in a single file instead of having to maintain two files for a single command. Maintaining a second Markdown file that's just a shim calling some other script is a technical burden that could be easily avoided by the inclusion of support for directly using script files written in other languages. Why bear this burden if we don't have to?

@ariane-emory commented on GitHub (Nov 28, 2025): @JunarisAlf Shell expansions in the Markdown files can let you achieve somewhat similar things, but it's slightly more cumbersome since you need to maintain both an `.md` file and a `.py` (or whatever other language) file instead of being to do it all in a single `.py` (or whatever) file. Personally, I feel that it would be more ergonomic and provide a better DevX for custom command authors if they could do it all in a single file instead of having to maintain two files for a single command. Maintaining a second Markdown file that's just a shim calling some other script is a technical burden that could be easily avoided by the inclusion of support for directly using script files written in other languages. Why bear this burden if we don't have to?
yindo commented 2026-02-16 17:38:57 -05:00
Author
Owner
Copy Link
Copy Source

@einarpersson commented on GitHub (Nov 28, 2025):

I think this is cool, but if we were to get something like https://github.com/sst/opencode/pull/4411 then perhaps the feature that you are looking for here would just be the question of creating that plugin (and sharing it with the world?).

As i understand it, commands are right now either built-in custom stuff or "do something with a llm". But being able to utilize the SDK to register and run commands that execute code feels obvious. And that could of course include execute some other script with uv, node, julia or whatever with the proper shebang.

OR the other way around. Get something like this working first, like you propose. But the opencode SDK is only available in ts/js, so i suppose that if you want that script to also interact with the running client/server then you'd have to use that (or use the API perhaps, i'm not sure about feature parity sdk/api).

Bottom line: I'm all for stuff that opens up for power users to use opencode whatever way they want. Instead of building all features into opencode, let's create nice interfaces and get that eco-system going (and lower the treshold to customize it whatever way you want).

Questions:

  1. Would this allow for slash commands with arguments? to be provided to the commands
  2. Could something like env variables be used to provide the command with some context that could be useful? The API/SDK could perhaps be used to look up such stuff on a need-to-know basis but at the very least it could be useful for the command to get some id:s so it'd be easier to look up.
@einarpersson commented on GitHub (Nov 28, 2025): I think this is cool, but if we were to get something like https://github.com/sst/opencode/pull/4411 then perhaps the feature that you are looking for here would just be the question of creating that plugin (and sharing it with the world?). As i understand it, commands are right now either built-in custom stuff or "do something with a llm". But being able to utilize the SDK to register and run commands that execute code feels obvious. And that could of course include execute some other script with uv, node, julia or whatever with the proper shebang. OR the other way around. Get something like this working first, like you propose. But the opencode SDK is only available in ts/js, so i suppose that if you want that script to also interact with the running client/server then you'd have to use that (or use the API perhaps, i'm not sure about feature parity sdk/api). Bottom line: I'm all for stuff that **opens up** for power users to use **open**code whatever way they want. Instead of building all features into opencode, let's create nice interfaces and get that eco-system going (and lower the treshold to customize it whatever way you want). Questions: 1. Would this allow for slash commands with arguments? to be provided to the commands 2. Could something like env variables be used to provide the command with some context that could be useful? The API/SDK could perhaps be used to look up such stuff on a need-to-know basis but at the very least it could be useful for the command to get some id:s so it'd be easier to look up.
yindo commented 2026-02-16 17:38:57 -05:00
Author
Owner
Copy Link
Copy Source

@ariane-emory commented on GitHub (Nov 28, 2025):

I'm gonna have to spend a bit more time reading #4411 and thinking about it to say for sure, but my first instinct is to say that it doesn't seem quite as open-ended or flexible.

Part of what seems attractive about the shebang line method is that it isn't limited to some small subset of languages, it could be used with any language that can interface with standard Unix behaviours regarding the use of shebang lines to invoke interpreters via command lines - popular languages, ancient languages that have been nearly forgotten about and even languages to be invented in the future that don't exist yet. Whether that's valuable is a judgement call the reader will have to make for themselves.

Answers:

  1. Sure, arguments could be passed to the interpreter specified by the shebang line in the same way that they would be if you executed the script from the command line.
  2. Sure, I'd presume that those languages that would be able to access environment variables if you executed the script from the command line would be able to do so here as well. Some exotic languages might support shebang lines but not support environment variables: if you decided to write your command in Befunge we would be able to run it but you'd probably be out of luck on the environment variables.
@ariane-emory commented on GitHub (Nov 28, 2025): I'm gonna have to spend a bit more time reading #4411 and thinking about it to say for sure, but my first instinct is to say that it doesn't seem quite as open-ended or flexible. Part of what seems attractive about the shebang line method is that it isn't limited to some small subset of languages, it could be used with any language that can interface with standard Unix behaviours regarding the use of shebang lines to invoke interpreters via command lines - popular languages, ancient languages that have been nearly forgotten about and even _languages to be invented in the future that don't exist yet_. Whether that's valuable is a judgement call the reader will have to make for themselves. Answers: 1. Sure, arguments could be passed to the interpreter specified by the shebang line in the same way that they would be if you executed the script from the command line. 2. Sure, I'd presume that those languages that would be able to access environment variables if you executed the script from the command line would be able to do so here as well. Some exotic languages might support shebang lines but not support environment variables: if you decided to write your command in Befunge we would be able to run it but you'd probably be out of luck on the environment variables.
yindo commented 2026-02-16 17:38:57 -05:00
Author
Owner
Copy Link
Copy Source

@einarpersson commented on GitHub (Nov 28, 2025):

Yes I like what you are proposing. I just meant that as soon as the sdk can be used to create commands (that execute code) it should be possible to without further changes to source code, create such a plugin, that allows for registering and executing commands in any language as you propose, for example if is a commands folder is existing as in your proposal. If I'm not missing something. But adding this to core would be nice also. It would make it super easy to add slash commands

@einarpersson commented on GitHub (Nov 28, 2025): Yes I like what you are proposing. I just meant that as soon as the sdk can be used to create commands (that execute code) it should be possible to without further changes to source code, create such a plugin, that allows for registering and executing commands in any language as you propose, for example if is a commands folder is existing as in your proposal. If I'm not missing something. But adding this to core would be nice also. It would make it super easy to add slash commands
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 discussion
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#3168
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?