We haven't really had a discussion yet on how we want to structure the CLI interface for custom commands (i.e. whether we include them in the positional arg gemini "/command args for command" or if we do the alternative gemini --command="args for command"

I continue to argue for the latter because it doesn't carry over the TUI ux affordance "/" which is unnecessary in the CLI command environment because we have flags. In other words, why invent a new way to do a flag on the command line when we have a perfect good way to do flags on the command line that is used by every other CLI application out there?

Second, I would like this PR to focus on custom commands. Take the @ file processing out for a different PR. Again gemini cli has the ability to take context on STDIN and files can be passed to gemini CLI that way, which is much more consistent with standard command line ux than including the TUI ux affordance "@" to indicate that on the command line. Either way, let's keep this PR focused on one thing.

Finally let's make sure we are including the issue for this #5435 in the PR description and please update the PR description to be more descriptive overall.

What do you think of splitting this into two parts:

1. Refactor existing functionality to create a reusable packages/cli/src/utils/commands.ts
2. Implement custom command support in non-interactive mode?

cc @abhipatel12 @allenhutchison

Good idea. Created PR #8381

We haven't really had a discussion yet on how we want to structure the CLI interface for custom commands (i.e. whether we include them in the positional arg gemini "/command args for command" or if we do the alternative gemini --command="args for command"

I continue to argue for the latter because it doesn't carry over the TUI ux affordance "/" which is unnecessary in the CLI command environment because we have flags. In other words, why invent a new way to do a flag on the command line when we have a perfect good way to do flags on the command line that is used by every other CLI application out there?

From an engineering perspective I like the separate command flag as it better separates concerns too.

However, the feedback seems clearly in favor of specifying it in the prompt (at least 6 votes for that). I totally understand, because I tried that myself and I think the intuition will become stronger over time as similar tools are going with that approach.

Second, I would like this PR to focus on custom commands. Take the @ file processing out for a different PR. Again gemini cli has the ability to take context on STDIN and files can be passed to gemini CLI that way, which is much more consistent with standard command line ux than including the TUI ux affordance "@" to indicate that on the command line. Either way, let's keep this PR focused on one thing.

Sorry for the confusing diff, that is actually existing functionality.

Finally let's make sure we are including the issue for this #5435 in the PR description and please update the PR description to be more descriptive overall.

Done.

FYI I split the refactoring for the command parsing to PR #8381

I'm not sure if I rebased this PR correctly (apologies I'm still learning Git), but I do see separate commits in this PR at least.

Good progress. A few comments to think about here. Ping me when you are ready for another review.

I took another pass this afternoon. This looks great, works well in my testing, and you've addressed all of my comments. I think we can bring this in.

trying to kick off the tests again