feat: Top level built-in command: /commands #3114

Activity

1. rekram1-node commented on Oct 12, 2025

   

   rekram1-node

   on Oct 12, 2025

   Contributor

   More actions

   are you just saying slash commands should handle collisions differently? Because the title is confusing me
2. rekram1-node

   assigned

   thdxr

   on Oct 12, 2025
3. taqtiqa-mark commented on Oct 12, 2025

   

   taqtiqa-mark

   on Oct 12, 2025

   Author

   More actions

   are you just saying slash commands should handle collisions differently? Because the title is confusing me

   Apologies. I am suggesting there should be a new built-in /commands, complimentary to /models, /agents, /themes.
   And that the commands shown are conditional on the primary agent that is activated (bottom right corner in TUI)
4. taqtiqa-mark commented on Oct 13, 2025

   

   taqtiqa-mark

   on Oct 13, 2025

   Last edited by taqtiqa-mark

   Author

   More actions

   Take two different use cases:

   • A user employing opencode configured for a IDE role (hit tab until IDE AGENT).
   • The same user employing opencode configured for a TA role (hit tab until TA AGENT).

   In each of those cases it is reasonable to anticipate that the set of Commands that have been introduced are quite different.
   When the agent is IDE AGENT the list returned by /commands should not include any of the Commands that are in scope when the agent is switched to TA AGENT, and vice versa.
5. taqtiqa-mark

   changed the title [-]feat: /commands[/-] [+]feat: Top level built-in command: `/commands`[/+] on Oct 13, 2025
6. rekram1-node commented on Oct 13, 2025

   

   rekram1-node

   on Oct 13, 2025

   Contributor

   More actions

   When the agent is IDE AGENT the list returned by /commands should not include any of the Commands that are in scope when the agent is switched to TA AGENT, and vice versa.

   Hm currently specifying an agent in the command is configuring what agent to use when executing the command, it doesn't mean that you have to currently be using that agent

   Especially since you can specify a subagent
7. taqtiqa-mark commented on Oct 13, 2025

   

   taqtiqa-mark

   on Oct 13, 2025

   Last edited by taqtiqa-mark

   Author

   More actions

   Hm currently specifying an agent in the command is configuring what agent to use when executing the command

   I believe I am addressing different behavior in the TUI regarding whether the command is listed or considered in-scope or "available".

   Selecting the primary agent (tab action), sets the commands that are shown by /commands,

   When I have the agent/ide.md as the active agent (IDE AGENT), then when I use the built-in /commands I do not want to see listed the commands: /grade, /comment, /appeal, /research that use the sub-agents of agent/ta.md (as you point out).

   Similarly, when I have the agent/ta.md as the active agent (TA AGENT), then when I use the built-in /commands I do not want to see listed the commands: /ticket, /comment, /debug, /research that use the sub-agents of agent/ide.md.

   Imagine the primary agent, by being set as the active agent (the TUI display in the lower right corner), sets rules common to all sub-agents and the commands listed in the TUI displays.

   Note the overlapping commands /research and /comment. One pair under command/ide/ the other pair under command/ta/

   Ideally this would then look like

   # command/ide/research.md
   ---
   description: Lorem ipsum.
   ---
   
   @ide/research
   
   **user_request**
   
   $ARGUMENTS
   
   

   and

   # command/ta/research.md
   ---
   description: Dolor sit amet.
   ---
   
   @ta/research
   
   **user_request**
   
   $ARGUMENTS
   
   

   etc.
8. taqtiqa-mark commented on Nov 24, 2025

   

   taqtiqa-mark

   on Nov 24, 2025

   Author

   More actions

   There is now a /commands. It went in a different direction. Nonetheless this is strictly obsolete.
9. taqtiqa-mark

   closed this as completedon Nov 24, 2025