| name | delegating-to-gemini-cli |
| description | Delegates coding tasks to the Gemini CLI agent. Use when asked to use gemini, gemini-cli, or to spawn external agents for parallel work on multiple issues. |
Delegating to Gemini CLI
Orchestrates work delegation to the Gemini CLI agent for parallel task execution.
When to Use
- User explicitly asks to use "gemini", "gemini cli", or "gemini-cli"
- Multiple independent issues need fixing in parallel
- Tasks benefit from a fresh context/agent perspective
- Offloading work to run concurrently while continuing other tasks
Prerequisites
Verify gemini CLI is installed:
which gemini && gemini --version
Model Selection
Always specify the model explicitly with -m. Only use Gemini 3 models:
gemini -m gemini-3-pro-preview "task description"
Allowed models:
gemini-3-pro-preview - Best for complex coding tasks, refactoring, multi-file changes
gemini-3-flash - Fast for simpler tasks, single-file fixes, quick edits
Never use: gemini-2.5-pro, gemini-2.0-flash, or any 2.x models.
Execution Patterns
Single Task (Direct)
gemini -m gemini-3-pro-preview -y "Fix the bug in src/foo.rkt on line 42. Read the file first, then implement the fix and run tests."
Parallel Tasks (Via Subagents)
Use the Task tool to spawn subagents, each invoking gemini:
<Task>
<description>Fix Issue #1: Description</description>
<prompt>Use the gemini CLI to fix Issue #1.
Run this command:
```bash
cd /path/to/project && gemini -m gemini-3-pro-preview -y "Detailed task description with:
1. Files to read
2. Specific changes needed
3. Tests to run after"
Report back what changes were made.
### Key Flags
| Flag | Purpose |
|------|---------|
| `-m MODEL` | Specify model (required for consistent results) |
| `-y` | Auto-accept all actions (YOLO mode) - use for automated tasks |
| `-d` | Debug mode for troubleshooting |
| `-s` | Sandbox mode for safer execution |
| `--approval-mode auto_edit` | Auto-approve edits only, prompt for other actions |
## Task Description Best Practices
Structure prompts for gemini with:
1. **Context**: What file(s) to read first
2. **Requirements**: Numbered list of specific changes
3. **Verification**: Test command to run after changes
4. **Scope**: Be explicit about what NOT to change
Example:
"Fix the ANSI parser in src/tui/text/ansi.rkt to support 256-color codes.
Requirements:
- Read the current implementation first
- Add parsing for 38;5;N (256-color) sequences
- Add parsing for 38;2;R;G;B (TrueColor) sequences
- Add tests for new functionality
- Do NOT modify existing 16-color handling
After changes, run: raco test src/tui/text/ansi.rkt"
## Creating GitHub Issues First
Before delegating, create detailed issues with `gh`:
```bash
gh issue create \
--title "[Component] Brief description" \
--label "bug" \
--body 'Detailed markdown with:
- Problem description
- File locations with line numbers
- Root cause analysis
- Proposed solution
- Acceptance criteria'
Then reference issues in gemini prompts for traceability.
Workflow: Issue Batch Processing
- Analyze codebase for issues (grep TODOs, review docs, find bugs)
- Create GitHub issues with
gh issue create including file:line references
- Spawn subagents each running gemini for one issue
- Collect results from subagent summaries
- Verify with build/test commands
- Report consolidated status to user
Error Handling
If gemini hits quota limits:
The model is overloaded. Please try again later.
Fallback options:
- Switch to
gemini-3-flash if using pro (or vice versa)
- Implement the fix directly in the subagent
- Queue the task for retry
Verification After Delegation
Always verify gemini's work:
raco make main.rkt
raco test src/
git status
git diff --stat
Example: Full Workflow
gh issue create --title "[TUI] Fix scroll bug" --label "bug" --body '...'
raco test src/tui/
git diff