GC-101 · Module 3

Custom Slash Commands

5 min read

Custom slash commands are reusable prompt templates defined in .toml files. They live in .gemini/commands/ (project-scoped) or ~/.gemini/commands/ (user-scoped). When you type /commandname, Gemini loads the .toml file, interpolates any arguments via {{args}}, and executes the resulting prompt. This is how you encode your team's best practices into repeatable workflows.

[command]
name = "review"
description = "Review code changes for quality and issues"
prompt = """
Review the following code changes:
{{args}}

Check for:
1. Logic errors and edge cases
2. Security vulnerabilities
3. Performance issues
4. Code style consistency with the project
5. Missing error handling
6. Test coverage gaps

Provide specific, actionable feedback.
"""

Commands support namespacing with a colon separator. This is powerful for organizing related commands. For example, /git:commit, /git:pr, and /git:changelog can all live in separate .toml files but group logically under the git namespace. The convention is to name the file with the full namespace: git-commit.toml, git-pr.toml.

[command]
name = "git:commit"
description = "Generate a conventional commit message"
prompt = """
Analyze the staged changes (run git diff --cached) and generate
a conventional commit message. Format:

type(scope): description

- type: feat|fix|refactor|docs|test|chore
- scope: the module or area affected
- description: imperative mood, lowercase, no period

Include a body if the change is non-trivial.
"""

The {{args}} interpolation token passes everything after the command name into the prompt. So /review @src/app.tsx becomes the prompt with "@src/app.tsx" substituted for {{args}}. You can also use shell execution within commands via the !{...} syntax, which runs a shell command and injects the output into the prompt.

[command]
name = "changelog"
description = "Generate a changelog from recent commits"
prompt = """
Here are the recent commits:
!{git log --oneline -20}

Generate a user-facing changelog grouped by:
- Features
- Bug Fixes
- Improvements

Use clear, non-technical language.
"""

Do This

  • Use project-scoped commands (.gemini/commands/) for team workflows
  • Use user-scoped commands (~/.gemini/commands/) for personal preferences
  • Namespace related commands with colons (/git:commit, /git:pr)
  • Check project commands into version control

Avoid This

  • Put personal preference commands in the project scope
  • Create flat, unnamespaced commands that collide with teammates' commands
  • Keep useful team workflows in your personal scope where nobody else benefits
  • Gitignore your project commands — they're team documentation