added gemini cli custom commands!

[yoav0gal]

issue: #363

Comment: Currently, the search in gemini-cli is based on the first letters and the commands are /agents:pm, so in order to search, one needs to look for agents instead of just pm.

Can be hacked, so commands will be just /pm or /create-doc - but I don't like it.

[dracic]

issue: #363

Comment: Currently, the search in gemini-cli is based on the first letters and the commands are /agents:pm, so in order to search, one needs to look for agents instead of just pm.

Can be hacked, so commands will be just /pm or /create-doc - but I don't like it.

I made a PR for Gemini CLI implementing case insensitive fuzzy command matching, and it will be in 4.x. Next week I suppose.

https://github.com/google-gemini/gemini-cli/releases/tag/v0.4.0-preview

So maybe we should do the same setup as in Claude Code IDE setup? At the moment it is

BMad:agents:agentname
Bmad:tasks:taskname

claude-code:
   name: Claude Code
   rule-dir: .claude/commands/BMad/
   format: multi-file
   command-suffix: .md
   instructions: |
     # To use BMad agents in Claude Code:
     # 1. Type /agent-name (e.g., "/dev", "/pm", "/architect")
     # 2. Claude will switch to that agent's persona
 crush:

[dracic]

Also let's look at:

https://github.com/google-gemini/gemini-cli/blob/main/docs/cli/commands.md#4-injecting-file-content-with-

This is an opportunity for a simpler setup where the agent's content would be inserted directly using this directive from the .bmad-core directory. So in that case dev custom command would be:

# In: <project>/.gemini/commands/BMad/agents/dev.toml
# Invoked via: /BMad:agents:dev

description = "Load fullstack dev agent"
prompt = """
@{.bmad-core/agents/dev.md}
"""

If you have the time and willingness, I look forward to your PR.

[yoav0gal]

Hahaha, I was digging into the code and saw that someone already did something for gemini-cli. Just realized that's you 🤣

So maybe we should do the same setup as in Claude Code IDE setup? At the moment it is

Yep took insperations from that in the pr its:

/agents:agentname - it have a bmad indication next to it as well.

lmk if you think we should add the bmad: as well - I think its overkill but IDK, something like bmand-agents:agent-name and bmad-tasks:can also work as well.

make the call XD

[dracic]

Let's keep the same or similar setups within similar IDE solutions. And qwen will have the same setup. Fuzzy matching makes this easy.

/dev and tab

We had that discussion: #541

[yoav0gal]

Also let's look at:

google-gemini/gemini-cli@main/docs/cli/commands.md#4-injecting-file-content-with-

This is an opportunity for a simpler setup where the agent's content would be inserted directly using this directive from the .bmad-core directory. So in that case dev custom command would be:

# In: <project>/.gemini/commands/BMad/agents/dev.toml
# Invoked via: /BMad:agents:dev

description = "Load fullstack dev agent"
prompt = """
@{.bmad-core/agents/dev.md}
"""

If you have the time and willingness, I look forward to your PR.

Yep, thats cool.

The on the flight loading is interesting:
pro: addpts when you are changing the agent definition yourself.
con: slower, more work - on every prompt copy paste - less observabilty (I don't think it's a biggie)

What are your thoughts?
@dracic - Make a call here as well It should not take long implement

[dracic]

con: slower, more work - on every prompt copy paste - less observabilty (I don't think it's a biggie)

What do you mean by "copy paste" in this case?

[yoav0gal]

con: slower, more work - on every prompt copy paste - less observabilty (I don't think it's a biggie)

What do you mean by "copy paste" in this case?

From my understanding of gemini-cli (not a good one)

This is myfile.txt

this prompt @{myfile.txt} 

would get translated in the gemini-cli react application to:

this prompt This is myfile.txt 

and the calculation to do that runs every time you call a prompt with @{}.

I can make the argument that because we don't change the agent command, it should be pre-computed.

But honslty, I dont think its a big deal. just thinking out loud.

[yoav0gal]

Let's keep the same or similar setups within similar IDE solutions. And qwen will have the same setup. Fuzzy matching makes this easy.

/dev and tab

We had that discussion: #541

Not sure I got you right:

so here you want to have the folder structure to be:

.gemini/extensions/bmad/commands/bmad/agents

instead of

.gemini/extensions/bmad/commands/agents

so when you write the command it would look: bmad:agents:sm insted of agents:dev ?

[dracic]

The point of file injection is - why would you construct whole agent definition via complex JS function in

.gemini/commands/BMad/agents/dev.toml

when you can just insert it dynamically from

.bmad-core/agents/dev.md

This is not meant to change the agent's definition dynamically, but rather to avoid having the same content in two places if we don't have to. I think Brian has an idea for v5 how to add possibility to add something to agent definition. The .toml files are not re-read or re-parsed on every command invocation. Try adding or changing a custom command (or inserted file) while running the Gemini CLI and see if you'll have a change.

So:

1. Startup Initialization: The application's entry point is the main function in gemini.tsx. This function orchestrates the startup sequence of the CLI.

2. Command Service Creation: During startup, a CommandService instance is created. This service is responsible for discovering and loading all slash commands for the CLI. The creation is handled by the static create method of the CommandService class.

3. Command Loading: The CommandService.create method takes an array of command loaders. One of these loaders is the FileCommandLoader, which is responsible for custom commands defined in .toml files.

4. File Scanning and Parsing: The FileCommandLoader.loadCommands method is called only once during this startup phase. It scans the user, project, and extension directories for any .toml files, reads them, parses their content, and converts them into executable SlashCommand objects.

5. In-Memory Storage: The loaded commands are then stored in a readonly array within the CommandService instance.

[dracic]

Let's keep the same or similar setups within similar IDE solutions. And qwen will have the same setup. Fuzzy matching makes this easy.
/dev and tab
We had that discussion: #541

Not sure I got you right:

so here you want to have the folder structure to be:

.gemini/extensions/bmad/commands/bmad/agents

instead of

.gemini/extensions/bmad/commands/agents

so when you write the command it would look: bmad:agents:sm insted of agents:dev ?

No. Custom commands location is in .gemini/commands/

For bmad if we want the same setup like Claude Code we should have:

.gemini/commands/BMad/agents/agentname.toml
.gemini/commands/BMad/tasks/taskname.toml

With fuzzy matching you don't have to start typing /BMad, /dev will give you a list of all commands matching "dev"

[yoav0gal]

cool,
I'll draft a pr.
You want to go for BMad for all or bmad (currently, a bunch of things are in bmad and some are BMad)

I tend to like bmad more for the folder

[yoav0gal]

@dracic - made the changes we discussed.

[dracic]

cool, I'll draft a pr. You want to go for BMad for all or bmad (currently, a bunch of things are in bmad and some are BMad)

I tend to like bmad more for the folder

Not my preference, just if Claude has BMad currently, let's go with it. I'll rather have consistency if it doesn't break anything, and then if we change our mind, let's change all at once.

[dracic]

Thanks @yoav0gal !

[yoav0gal]

Cool,
updated to BMad.

I asked because the rest is mostly bad (cursor, Auggie)
Others with a signal file are using bmad. other multi-file/chats are using a variation of bmad (cline, roo)
We should probably change those as well if we are going for BMad (later)

BTW - in the gemini-cli the readPathFromWorkspace function does run every time (checked that) - I still don't think its an issue. i think keeping the @{} is ok

can we move Gemini CLI higher on the select menu?

[dracic]

I agree with you, the nomenclature should be standardized. On the other hand, not all tools have this capability for hierarchical organization of the commands, so the only difference is in the name of the directory where they are located. The dev agent is dev everywhere. Let's raise this issue for v5. Should our future namespace be "BMad" or "bmad".

[dracic]

BTW - in the gemini-cli the readPathFromWorkspace function does run every time (checked that) - I still don't think its an issue. i think keeping the @{} is ok

Yes, now I tried It too. I'm eating humble pie. Ok, Iet's try the difference in speed.

[dracic]

Man, we are talking here about few ms. I just like it so simple. @yoav0gal do we need gemini-extension.json for custom commands?

[yoav0gal]

About the extension.json I don't think so,...
I'll drop it when I am on my computer (after I'll look into that).

About the ms, yes! That's what's I was saying, I don't think it's a big deal,

Initially I just wanted to keep the standards and explain my thoughts on why I didn't go for the @{} at the first place.

If you guys think it's better this way or that way I don't really have an opinion about that.

The main thing is to get the commands working.

[dracic]

It works and I like this!

[dracic]

@yoav0gal I was thinking. Now that you're at full speed, you could do something similar for Qwen code in antoher PR. They have now synced to 0.2.1. It seems to me that they are always one week behind compared to the Gemini CLI. We can leave it unmerged until they upgrade.

[bmadcode]

Thanks @yoav0gal @dracic - merging.