mirror of
https://github.com/samsonjs/vibetunnel.git
synced 2026-04-27 15:17:38 +00:00
feat: add gemini and review-pr slash commands (#138)
This commit is contained in:
parent
13b98308c9
commit
b2a395fcd8
3 changed files with 571 additions and 0 deletions
58
.claude/commands/gemini.md
Normal file
58
.claude/commands/gemini.md
Normal file
|
|
@ -0,0 +1,58 @@
|
||||||
|
# /gemini
|
||||||
|
|
||||||
|
Execute Gemini CLI with the context from docs/gemini.md for large codebase analysis.
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
|
||||||
|
```
|
||||||
|
/gemini {prompt}
|
||||||
|
```
|
||||||
|
|
||||||
|
## Description
|
||||||
|
|
||||||
|
This command reads the `docs/gemini.md` file which contains best practices for using the Gemini CLI with large codebases, then executes the appropriate gemini command based on your prompt.
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Analyze a single file
|
||||||
|
```
|
||||||
|
/gemini @web/src/server/server.ts Explain this file's purpose and structure
|
||||||
|
```
|
||||||
|
|
||||||
|
### Check feature implementation
|
||||||
|
```
|
||||||
|
/gemini @web/src/ Has dark mode been implemented in this codebase?
|
||||||
|
```
|
||||||
|
|
||||||
|
### Analyze entire project
|
||||||
|
```
|
||||||
|
/gemini @./ Give me an overview of this entire project
|
||||||
|
```
|
||||||
|
|
||||||
|
### Verify security measures
|
||||||
|
```
|
||||||
|
/gemini @web/src/ @web/src/api/ Are SQL injection protections implemented?
|
||||||
|
```
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
When you use this command, I will:
|
||||||
|
1. Check if Gemini CLI is installed and accessible
|
||||||
|
2. Read the contents of `docs/gemini.md` to understand Gemini CLI usage patterns (provide helpful error if missing)
|
||||||
|
3. Analyze your prompt to determine the appropriate Gemini command structure
|
||||||
|
4. Execute the gemini command with the proper flags and file inclusions
|
||||||
|
5. Return the results to help with your codebase analysis
|
||||||
|
|
||||||
|
## Error Handling
|
||||||
|
|
||||||
|
- If Gemini CLI is not installed, provide installation instructions
|
||||||
|
- If `docs/gemini.md` is missing, use built-in knowledge of Gemini CLI best practices
|
||||||
|
- Handle command execution errors gracefully with helpful messages
|
||||||
|
|
||||||
|
## Note
|
||||||
|
|
||||||
|
The Gemini CLI is particularly useful when:
|
||||||
|
- Analyzing entire codebases or large directories
|
||||||
|
- Context window limits are a concern
|
||||||
|
- You need to verify implementation of specific features across many files
|
||||||
|
- Working with files totaling more than 100KB
|
||||||
314
.claude/commands/review-pr.md
Normal file
314
.claude/commands/review-pr.md
Normal file
|
|
@ -0,0 +1,314 @@
|
||||||
|
# /review-pr
|
||||||
|
|
||||||
|
Perform a comprehensive code review of the current pull request using parallel sub-agents powered by Claude and Gemini, with results intelligently merged.
|
||||||
|
|
||||||
|
## Usage
|
||||||
|
|
||||||
|
```
|
||||||
|
/review-pr [options]
|
||||||
|
```
|
||||||
|
|
||||||
|
Options:
|
||||||
|
- `--focus <area>` - Focus on specific areas. Valid values: `security`, `performance`, `tests`, `architecture`, `documentation`, `all`
|
||||||
|
- `--gemini-only` - Perform the review only with gemini CLI
|
||||||
|
|
||||||
|
## Description
|
||||||
|
|
||||||
|
This command performs a thorough code review of the current branch's changes compared to the main branch. It runs two parallel sub-agents - one using Claude and another using Gemini - to perform independent comprehensive reviews. The results from both AI models are then intelligently merged to provide a complete multi-perspective analysis.
|
||||||
|
|
||||||
|
## Examples
|
||||||
|
|
||||||
|
### Standard PR review
|
||||||
|
```
|
||||||
|
/review-pr
|
||||||
|
```
|
||||||
|
|
||||||
|
### Security-focused review
|
||||||
|
```
|
||||||
|
/review-pr --focus security
|
||||||
|
```
|
||||||
|
|
||||||
|
### Performance and scalability review
|
||||||
|
```
|
||||||
|
/review-pr --focus performance
|
||||||
|
```
|
||||||
|
|
||||||
|
## Implementation
|
||||||
|
|
||||||
|
When you use this command, I will:
|
||||||
|
|
||||||
|
1. **Initial PR Context Gathering**
|
||||||
|
- Check if required tools are available: `gh`, `git`, and `gemini`
|
||||||
|
- Run `gh pr view` to check PR description and any existing comments (handle errors gracefully)
|
||||||
|
- Run `git log "main..HEAD" --oneline` to see all commits in this PR (with proper shell escaping)
|
||||||
|
- Run `git diff "main...HEAD" --stat` to get an overview of changed files (with proper shell escaping)
|
||||||
|
- Generate comprehensive diff with secure temporary file handling:
|
||||||
|
```bash
|
||||||
|
touch .pr_review_diff.tmp && chmod 600 .pr_review_diff.tmp
|
||||||
|
git diff "main...HEAD" > .pr_review_diff.tmp
|
||||||
|
```
|
||||||
|
- If any git commands fail, provide helpful error messages and guidance
|
||||||
|
|
||||||
|
2. **Launch Two Parallel Sub-Agents**
|
||||||
|
|
||||||
|
**Sub-Agent 1: Claude Review**
|
||||||
|
- WARNING: This step must be skipped when `--gemini-only` has been passed
|
||||||
|
- Performs complete multi-aspect code review using Claude
|
||||||
|
- Analyzes all aspects below independently
|
||||||
|
|
||||||
|
**Sub-Agent 2: Gemini Review**
|
||||||
|
- Runs Gemini CLI following instructions from `docs/gemini.md`
|
||||||
|
- Performs complete multi-aspect code review using Gemini
|
||||||
|
- Form the prompt to the Gemini CLI in a way that it only returns the final output of its findings, to save tokens
|
||||||
|
- Analyzes all aspects below independently
|
||||||
|
- Use a timeout of 10 minutes for the gemini CLI command (configurable via environment variable `GEMINI_TIMEOUT_SECONDS`, default: 600)
|
||||||
|
- **IMPORTANT**: Gemini CLI can only access files within the project directory
|
||||||
|
- Create temporary diff file in project root (e.g., `.pr_review_diff.tmp`)
|
||||||
|
- Use `@.pr_review_diff.tmp` syntax to include the diff in Gemini prompt
|
||||||
|
- Clean up temporary file after review completes
|
||||||
|
|
||||||
|
**Both sub-agents analyze:**
|
||||||
|
|
||||||
|
**Correctness & Logic**
|
||||||
|
- Verify the code solves the intended problem
|
||||||
|
- Check for edge cases, off-by-one errors, null/undefined handling
|
||||||
|
- Validate business logic and algorithm correctness
|
||||||
|
|
||||||
|
**Code Quality & Architecture**
|
||||||
|
- Check adherence to DRY and SOLID principles
|
||||||
|
- Assess function/class complexity and cohesion
|
||||||
|
- Verify consistent naming conventions and code style
|
||||||
|
- Ensure changes align with existing architecture patterns
|
||||||
|
|
||||||
|
**Performance & Scalability**
|
||||||
|
- Identify O(n²) algorithms that could be O(n)
|
||||||
|
- Check for N+1 database queries
|
||||||
|
- Look for memory leaks or excessive allocations
|
||||||
|
- Identify missed caching opportunities
|
||||||
|
|
||||||
|
**Security**
|
||||||
|
- Check for SQL injection vulnerabilities
|
||||||
|
- Identify XSS vulnerabilities
|
||||||
|
- Verify authentication/authorization checks
|
||||||
|
- Ensure no sensitive data in logs or commits
|
||||||
|
- Validate all user inputs are sanitized
|
||||||
|
|
||||||
|
**Testing**
|
||||||
|
- Verify test coverage for new/modified code
|
||||||
|
- Check if tests actually test the right behavior
|
||||||
|
- Ensure edge cases are covered
|
||||||
|
- Assess test maintainability and brittleness
|
||||||
|
|
||||||
|
**Error Handling**
|
||||||
|
- Verify errors are properly caught and handled
|
||||||
|
- Check error messages are helpful for debugging
|
||||||
|
- Ensure appropriate logging levels
|
||||||
|
- Validate graceful failure modes
|
||||||
|
|
||||||
|
**Documentation**
|
||||||
|
- Check if complex logic is explained
|
||||||
|
- Verify API documentation is updated
|
||||||
|
- Look for outdated or misleading comments
|
||||||
|
- Ensure README/docs are updated if needed
|
||||||
|
|
||||||
|
**Automated Checks**
|
||||||
|
- Execute `pnpm run check` (for web/) if available
|
||||||
|
- Run `./scripts/lint.sh` (for mac/) if the script exists
|
||||||
|
- Run `./lint.sh` (for tauri/) if the script exists
|
||||||
|
- Check if tests pass with appropriate test commands
|
||||||
|
- Verify build succeeds
|
||||||
|
- If any checks fail, continue with review but note the failures
|
||||||
|
|
||||||
|
3. **Merge Results**
|
||||||
|
- Intelligently combine findings from both Claude and Gemini
|
||||||
|
- Identify common issues found by both models (high confidence)
|
||||||
|
- Highlight unique insights from each model
|
||||||
|
- Resolve any conflicting assessments
|
||||||
|
- Generate unified severity ratings
|
||||||
|
|
||||||
|
4. **Generate Final Review Report**
|
||||||
|
- Provide a structured review with:
|
||||||
|
- **Summary**: High-level overview of changes
|
||||||
|
- **Strengths**: What's done well
|
||||||
|
- **Critical Issues**: Must-fix problems with exact line numbers
|
||||||
|
- **Suggestions**: Nice-to-have improvements with exact line numbers
|
||||||
|
- **Questions**: Clarifications needed with exact line numbers
|
||||||
|
- Use accountability mindset - I'm as responsible as the author
|
||||||
|
- Provide constructive, mentoring-oriented feedback
|
||||||
|
- **CRITICAL**: Always include exact line numbers for every issue found
|
||||||
|
- Use format: `filename:line_number` (e.g., `src/server.ts:142`)
|
||||||
|
- For multi-line issues, use ranges: `filename:start_line-end_line`
|
||||||
|
|
||||||
|
5. **Cleanup**
|
||||||
|
- Remove temporary diff file `.pr_review_diff.tmp` from project root
|
||||||
|
- Ensure no sensitive data remains in temporary files
|
||||||
|
|
||||||
|
## Review Checklist
|
||||||
|
|
||||||
|
### ✅ Shared Accountability
|
||||||
|
- [ ] I understand I share responsibility for this code once approved
|
||||||
|
- [ ] I've reviewed with the same care as if I wrote it
|
||||||
|
|
||||||
|
### 🎯 Functionality
|
||||||
|
- [ ] Code implements intended functionality
|
||||||
|
- [ ] Edge cases and error scenarios handled
|
||||||
|
- [ ] No regressions introduced
|
||||||
|
|
||||||
|
### 🏗️ Architecture & Design
|
||||||
|
- [ ] Changes align with system architecture
|
||||||
|
- [ ] Scalability and maintainability considered
|
||||||
|
- [ ] Design patterns appropriately used
|
||||||
|
|
||||||
|
### 🔒 Security
|
||||||
|
- [ ] Input validation present
|
||||||
|
- [ ] Authentication/authorization correct
|
||||||
|
- [ ] No sensitive data exposed
|
||||||
|
- [ ] Dependencies are secure
|
||||||
|
|
||||||
|
### ⚡ Performance
|
||||||
|
- [ ] No unnecessary database queries
|
||||||
|
- [ ] Efficient algorithms used
|
||||||
|
- [ ] Resource usage is reasonable
|
||||||
|
- [ ] Caching utilized where appropriate
|
||||||
|
|
||||||
|
### 🧪 Testing
|
||||||
|
- [ ] Adequate test coverage
|
||||||
|
- [ ] Tests are meaningful, not just coverage
|
||||||
|
- [ ] Edge cases tested
|
||||||
|
- [ ] Tests are maintainable
|
||||||
|
|
||||||
|
### 📝 Code Quality
|
||||||
|
- [ ] Code is DRY
|
||||||
|
- [ ] SOLID principles followed
|
||||||
|
- [ ] Clear naming and structure
|
||||||
|
- [ ] Appropriate comments/documentation
|
||||||
|
|
||||||
|
### 🔄 Backwards Compatibility
|
||||||
|
- [ ] API changes are backwards compatible
|
||||||
|
- [ ] Database migrations handled properly
|
||||||
|
- [ ] No breaking changes without discussion
|
||||||
|
|
||||||
|
## Note
|
||||||
|
|
||||||
|
This command emphasizes:
|
||||||
|
- **Parallel Sub-Agent Architecture**: Two independent sub-agents perform complete reviews - one using Claude, another using Gemini CLI
|
||||||
|
- **Intelligent Merging**: Final step combines findings from both AI models by identifying common issues (high confidence), highlighting unique insights, and resolving conflicting assessments
|
||||||
|
- **Accountability**: Approving means you own the outcome
|
||||||
|
- **Mentorship**: Every comment is a teaching opportunity
|
||||||
|
- **Thoroughness**: Multiple passes from different angles by both AI models
|
||||||
|
- **Actionability**: Specific, clear feedback with examples
|
||||||
|
- **Precision**: Every issue must include exact line numbers
|
||||||
|
|
||||||
|
**Line Number Format Examples:**
|
||||||
|
- Single line issue: `src/server/auth.ts:234`
|
||||||
|
- Multi-line issue: `src/client/app.ts:45-52`
|
||||||
|
- Context reference: `src/utils/helpers.ts:78 (similar pattern at lines 95, 112)`
|
||||||
|
|
||||||
|
**Sub-Agent Execution:**
|
||||||
|
- Claude sub-agent performs the review using Claude's capabilities
|
||||||
|
- Gemini sub-agent runs the Gemini CLI following instructions from `docs/gemini.md`
|
||||||
|
- Both sub-agents work in parallel for efficiency
|
||||||
|
|
||||||
|
For large PRs, consider reviewing incrementally and suggesting the author break it into smaller PRs for more effective review.
|
||||||
|
|
||||||
|
## Prerequisites
|
||||||
|
|
||||||
|
- Git and GitHub CLI (`gh`) must be installed
|
||||||
|
- For full functionality: Gemini CLI must be installed (see Gemini documentation)
|
||||||
|
- For `--gemini-only` mode: Only Gemini CLI is required
|
||||||
|
|
||||||
|
## Security Considerations
|
||||||
|
|
||||||
|
**Input Sanitization:**
|
||||||
|
- All user-provided parameters (e.g., `--focus` values) are validated against a whitelist
|
||||||
|
- Git commands use proper shell escaping with quotes around branch names
|
||||||
|
- Temporary files are created with secure permissions (mode 600)
|
||||||
|
- File paths are validated to prevent directory traversal attacks
|
||||||
|
- The `--focus` parameter only accepts predefined values: security, performance, tests, architecture, documentation, all
|
||||||
|
|
||||||
|
**Safe Command Execution:**
|
||||||
|
```bash
|
||||||
|
# Always quote branch names and file paths
|
||||||
|
git diff "main...HEAD" --stat # Correct
|
||||||
|
git diff main...HEAD --stat # Vulnerable to injection
|
||||||
|
|
||||||
|
# Set restrictive permissions on temporary files
|
||||||
|
touch .pr_review_diff.tmp && chmod 600 .pr_review_diff.tmp
|
||||||
|
git diff "main...HEAD" > .pr_review_diff.tmp
|
||||||
|
```
|
||||||
|
|
||||||
|
## Error Handling
|
||||||
|
|
||||||
|
- If required tools are missing, the command will provide installation instructions
|
||||||
|
- Git command failures are handled gracefully with helpful error messages
|
||||||
|
- If automated checks fail, the review continues but notes the failures
|
||||||
|
- Timeout protection: Gemini sub-agent has a 10-minute timeout (configurable via `GEMINI_TIMEOUT_SECONDS` environment variable)
|
||||||
|
|
||||||
|
## Implementation Notes
|
||||||
|
|
||||||
|
**Gemini CLI File Access:**
|
||||||
|
- Gemini CLI can only access files within the project directory
|
||||||
|
- Always save temporary files in the project root with `.tmp` extension
|
||||||
|
- Use `.gitignore` patterns for temporary files (e.g., `.pr_review_*.tmp`)
|
||||||
|
- Example workflow:
|
||||||
|
```bash
|
||||||
|
# Create file with secure permissions
|
||||||
|
touch .pr_review_diff.tmp && chmod 600 .pr_review_diff.tmp
|
||||||
|
|
||||||
|
# Save diff to project-accessible location
|
||||||
|
git diff "main...HEAD" > .pr_review_diff.tmp
|
||||||
|
|
||||||
|
# Use with Gemini
|
||||||
|
gemini -p "@.pr_review_diff.tmp Your review prompt here"
|
||||||
|
|
||||||
|
# Clean up
|
||||||
|
rm -f .pr_review_diff.tmp
|
||||||
|
```
|
||||||
|
|
||||||
|
**Handling Large Diffs:**
|
||||||
|
- For very large PRs, consider splitting the diff by file type or directory
|
||||||
|
- Use Gemini's 2M token context window advantage for comprehensive analysis
|
||||||
|
- If diff exceeds reasonable size, suggest breaking PR into smaller chunks
|
||||||
|
|
||||||
|
**Chunking Strategy for Diffs Exceeding 1.5M Tokens:**
|
||||||
|
|
||||||
|
1. **Automatic splitting by file type:**
|
||||||
|
```bash
|
||||||
|
# JavaScript/TypeScript files
|
||||||
|
git diff "main...HEAD" -- "*.js" "*.ts" "*.jsx" "*.tsx" > .pr_review_js.tmp
|
||||||
|
|
||||||
|
# Python files
|
||||||
|
git diff "main...HEAD" -- "*.py" > .pr_review_py.tmp
|
||||||
|
|
||||||
|
# Documentation
|
||||||
|
git diff "main...HEAD" -- "*.md" "*.rst" "*.txt" > .pr_review_docs.tmp
|
||||||
|
```
|
||||||
|
|
||||||
|
2. **Split by directory structure:**
|
||||||
|
```bash
|
||||||
|
# Frontend changes
|
||||||
|
git diff "main...HEAD" -- "web/src/client/" > .pr_review_frontend.tmp
|
||||||
|
|
||||||
|
# Backend changes
|
||||||
|
git diff "main...HEAD" -- "web/src/server/" > .pr_review_backend.tmp
|
||||||
|
|
||||||
|
# Test changes
|
||||||
|
git diff "main...HEAD" -- "**/test/" "**/tests/" > .pr_review_tests.tmp
|
||||||
|
```
|
||||||
|
|
||||||
|
3. **Prioritize by change type:**
|
||||||
|
```bash
|
||||||
|
# New files (highest priority)
|
||||||
|
git diff "main...HEAD" --name-status | grep "^A" | cut -f2 | xargs git diff "main...HEAD" -- > .pr_review_new.tmp
|
||||||
|
|
||||||
|
# Modified files
|
||||||
|
git diff "main...HEAD" --name-status | grep "^M" | cut -f2 | xargs git diff "main...HEAD" -- > .pr_review_modified.tmp
|
||||||
|
|
||||||
|
# Deleted files (lowest priority for review)
|
||||||
|
git diff "main...HEAD" --name-status | grep "^D" | cut -f2 > .pr_review_deleted_list.tmp
|
||||||
|
```
|
||||||
|
|
||||||
|
4. **Token estimation:**
|
||||||
|
- Rough estimate: 1 token ≈ 4 characters
|
||||||
|
- Check file size: `wc -c .pr_review_diff.tmp`
|
||||||
|
- If > 6MB (≈1.5M tokens), implement chunking strategy
|
||||||
199
docs/gemini.md
Normal file
199
docs/gemini.md
Normal file
|
|
@ -0,0 +1,199 @@
|
||||||
|
# Using Gemini CLI for Large Codebase Analysis
|
||||||
|
|
||||||
|
When analyzing large codebases or multiple files that might exceed context limits, use the Gemini CLI with its massive context window (up to 2 million tokens). Use `gemini -p` to leverage Google Gemini's large context capacity.
|
||||||
|
|
||||||
|
## Prerequisites
|
||||||
|
|
||||||
|
Ensure Gemini CLI is installed before using these commands. Installation instructions: https://github.com/google/gemini-cli#installation
|
||||||
|
|
||||||
|
## File and Directory Inclusion Syntax
|
||||||
|
|
||||||
|
Use the `@` syntax to include files and directories in your Gemini prompts. The paths should be relative to WHERE you run the gemini command:
|
||||||
|
|
||||||
|
### Examples:
|
||||||
|
|
||||||
|
**Single file analysis:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@web/src/server/server.ts Explain this file's purpose and structure"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Multiple files:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@package.json @web/src/client/app.ts Analyze the dependencies used in the code"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Entire directory:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@src/ Summarize the architecture of this codebase"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Multiple directories:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@src/ @tests/ Analyze test coverage for the source code"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Current directory and subdirectories:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@./ Give me an overview of this entire project"
|
||||||
|
# Or use --all_files flag:
|
||||||
|
gemini --all_files -p "Analyze the project structure and dependencies"
|
||||||
|
```
|
||||||
|
|
||||||
|
**⚠️ Security Warning:** Using `@./` may include sensitive files like `.env`, `.git/`, or API keys. Consider using specific directories or exclusion patterns.
|
||||||
|
|
||||||
|
## Implementation Verification Examples
|
||||||
|
|
||||||
|
**Check if a feature is implemented:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@src/ @lib/ Has dark mode been implemented in this codebase? Show me the relevant files and functions"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Verify authentication implementation:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@src/ @middleware/ Is JWT authentication implemented? List all auth-related endpoints and middleware"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Check for specific patterns:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@src/ Are there any React hooks that handle WebSocket connections? List them with file paths"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Verify error handling:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@src/ @api/ Is proper error handling implemented for all API endpoints? Show examples of try-catch blocks"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Check for rate limiting:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@backend/ @middleware/ Is rate limiting implemented for the API? Show the implementation details"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Verify caching strategy:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@src/ @lib/ @services/ Is Redis caching implemented? List all cache-related functions and their usage"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Check for specific security measures:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@src/ @api/ Are SQL injection protections implemented? Show how user inputs are sanitized"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Verify test coverage for features:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@src/payment/ @tests/ Is the payment processing module fully tested? List all test cases"
|
||||||
|
```
|
||||||
|
|
||||||
|
## Error Scenarios and Handling
|
||||||
|
|
||||||
|
**Gemini CLI not installed:**
|
||||||
|
```bash
|
||||||
|
# Error: command not found: gemini
|
||||||
|
# Solution: Install Gemini CLI following instructions at https://github.com/google/gemini-cli#installation
|
||||||
|
```
|
||||||
|
|
||||||
|
**Invalid file paths:**
|
||||||
|
```bash
|
||||||
|
gemini -p "@nonexistent/path/ Analyze this code"
|
||||||
|
# Gemini will report: "Error: Path 'nonexistent/path/' does not exist"
|
||||||
|
# The command continues with any valid paths provided
|
||||||
|
```
|
||||||
|
|
||||||
|
**Network connectivity issues:**
|
||||||
|
```bash
|
||||||
|
# If API calls fail, you'll see:
|
||||||
|
# "Error: Failed to connect to Gemini API"
|
||||||
|
# Solution: Check your internet connection and API key configuration
|
||||||
|
```
|
||||||
|
|
||||||
|
**File encoding problems:**
|
||||||
|
```bash
|
||||||
|
# Non-UTF8 files are automatically skipped with a warning:
|
||||||
|
# "Warning: Skipping binary or non-UTF8 file: path/to/file"
|
||||||
|
```
|
||||||
|
|
||||||
|
**Context limit exceeded:**
|
||||||
|
```bash
|
||||||
|
# For extremely large codebases:
|
||||||
|
# "Error: Context limit exceeded (2M tokens)"
|
||||||
|
# Solution: Use more specific paths or directories instead of @./
|
||||||
|
```
|
||||||
|
|
||||||
|
**Timeout during analysis:**
|
||||||
|
```bash
|
||||||
|
# Default timeout is 30 seconds for API calls
|
||||||
|
# For longer operations, use the --timeout flag:
|
||||||
|
gemini --timeout 120 -p "@large-codebase/ Analyze architecture"
|
||||||
|
```
|
||||||
|
|
||||||
|
## When to Use Gemini CLI
|
||||||
|
|
||||||
|
Use `gemini -p` when:
|
||||||
|
- Analyzing entire codebases or large directories
|
||||||
|
- Comparing multiple large files
|
||||||
|
- Need to understand project-wide patterns or architecture
|
||||||
|
- Current context window is insufficient for the task
|
||||||
|
- Working with files totaling more than 100KB
|
||||||
|
- Verifying if specific features, patterns, or security measures are implemented
|
||||||
|
- Checking for the presence of certain coding patterns across the entire codebase
|
||||||
|
|
||||||
|
## Important Notes
|
||||||
|
|
||||||
|
- Paths in @ syntax are relative to your current working directory when invoking gemini
|
||||||
|
- The CLI will include file contents directly in the context
|
||||||
|
- The --yolo flag bypasses confirmation prompts (use cautiously)
|
||||||
|
- Gemini's context window can handle entire codebases that would overflow Claude's context
|
||||||
|
- When checking implementations, be specific about what you're looking for to get accurate results
|
||||||
|
- Symlinks are followed by default - be cautious with circular references
|
||||||
|
- Binary files are automatically excluded from analysis
|
||||||
|
- Use `.geminiignore` file to exclude specific patterns (similar to `.gitignore`)
|
||||||
|
|
||||||
|
## Using .geminiignore
|
||||||
|
|
||||||
|
Create a `.geminiignore` file in your project root to exclude files and directories from Gemini analysis. The syntax follows `.gitignore` patterns:
|
||||||
|
|
||||||
|
```
|
||||||
|
# Environment and secrets
|
||||||
|
.env*
|
||||||
|
*.key
|
||||||
|
*.pem
|
||||||
|
secrets/
|
||||||
|
credentials/
|
||||||
|
|
||||||
|
# Build artifacts
|
||||||
|
dist/
|
||||||
|
build/
|
||||||
|
*.min.js
|
||||||
|
*.bundle.js
|
||||||
|
|
||||||
|
# Dependencies
|
||||||
|
node_modules/
|
||||||
|
vendor/
|
||||||
|
venv/
|
||||||
|
|
||||||
|
# Large generated files
|
||||||
|
package-lock.json
|
||||||
|
yarn.lock
|
||||||
|
*.generated.ts
|
||||||
|
|
||||||
|
# Test fixtures
|
||||||
|
test/fixtures/large-data/
|
||||||
|
**/*.snapshot.js
|
||||||
|
|
||||||
|
# IDE and OS files
|
||||||
|
.idea/
|
||||||
|
.vscode/
|
||||||
|
.DS_Store
|
||||||
|
```
|
||||||
|
|
||||||
|
**Pattern Examples:**
|
||||||
|
- `*.log` - Exclude all log files
|
||||||
|
- `temp/` - Exclude temp directory
|
||||||
|
- `!important.log` - Include important.log even if *.log is excluded
|
||||||
|
- `src/**/test.js` - Exclude test.js in any subdirectory of src
|
||||||
|
- `/config.json` - Exclude config.json only in root directory
|
||||||
|
|
||||||
|
## Error Handling
|
||||||
|
|
||||||
|
- If paths don't exist, Gemini will report an error and continue with valid paths
|
||||||
|
- File encoding issues are handled gracefully (non-UTF8 files are skipped)
|
||||||
|
- For large repositories, consider using specific subdirectories to avoid timeouts
|
||||||
Loading…
Reference in a new issue