export declare const geminiTemplate = "# Using Gemini CLI for AIT\u00B3 Development and Large Codebase Analysis\n\nWhen working with AIT\u00B3 projects or analyzing large codebases that exceed Claude's context limits, use the Gemini CLI with its massive context window. Use `gemini -p` to leverage Google Gemini's large context capacity for TiDD workflow validation and architectural analysis.\n\n## File and Directory Inclusion Syntax\n\nUse the `@` syntax to include files and directories in your Gemini prompts. The paths should be relative to WHERE you run the gemini command:\n\n### Basic Examples\n\n**Single file analysis:**\n```bash\ngemini -p \"@src/commands/ticket/create.ts Explain this pure function's implementation\"\n```\n\n**Multiple files:**\n```bash\ngemini -p \"@package.json @src/cli.ts Analyze the CLI architecture and dependencies\"\n```\n\n**Entire directory:**\n```bash\ngemini -p \"@src/commands/ Summarize the pure function command architecture\"\n```\n\n**Multiple directories:**\n```bash\ngemini -p \"@src/services/ @tests/ Analyze service layer test coverage\"\n```\n\n**Full project analysis:**\n```bash\ngemini -p \"@./ Give me an overview of this AIT\u00B3 project\"\n# Or use --all_files flag:\ngemini --all_files -p \"Analyze the entire AIT\u00B3 project structure and patterns\"\n```\n\n## AIT\u00B3 TiDD Workflow Integration\n\n### PLANNING Phase Validation\nUse Gemini to challenge Claude's proposed approaches:\n\n```bash\n# Challenge architectural decisions\ngemini -p \"@src/services/ @CLAUDE.md Critique the service injection pattern used in this project. Are there better alternatives?\"\n\n# Validate ticket requirements\ngemini -p \"@.tickets/doing/ @src/commands/ticket/ Does the ticket implementation match the requirements? What's missing?\"\n\n# Security analysis for planning\ngemini -p \"@src/ Are there security vulnerabilities in this authentication approach? What are the risks?\"\n```\n\n### RED Phase Test Analysis\n```bash\n# Verify test completeness\ngemini -p \"@tests/ @src/commands/ Do the tests adequately cover all pure function behaviors? What edge cases are missing?\"\n\n# Test strategy validation\ngemini -p \"@tests/unit/ @tests/integration/ Is the test strategy appropriate for this TiDD workflow? Suggest improvements.\"\n\n# Mock analysis\ngemini -p \"@src/ @tests/ Which mock implementations need to be converted to real implementations? Create tickets for them.\"\n```\n\n### GREEN Phase Implementation Review\n```bash\n# Code quality assessment\ngemini -p \"@src/commands/ Rate the code quality of these pure functions. What needs improvement?\"\n\n# Architecture compliance\ngemini -p \"@src/ @CLAUDE.md Does the implementation follow the documented architecture patterns? Point out deviations.\"\n\n# Performance analysis\ngemini -p \"@src/ Identify performance bottlenecks in this implementation. Suggest optimizations.\"\n```\n\n### REFACTOR Phase Optimization\n```bash\n# Code duplication detection\ngemini -p \"@src/ Find code duplication and suggest refactoring opportunities.\"\n\n# Pattern consistency\ngemini -p \"@src/commands/ @src/services/ Are the naming conventions and patterns consistent across the codebase?\"\n\n# Technical debt identification\ngemini -p \"@src/ Identify technical debt and maintenance issues. Prioritize by impact.\"\n```\n\n## AIT\u00B3 Architecture Verification\n\n### Service Layer Analysis\n```bash\n# Interface compliance\ngemini -p \"@src/services/interfaces/ @src/services/implementations/ Do all implementations properly implement their interfaces?\"\n\n# Dependency injection validation\ngemini -p \"@src/cli.ts @src/commands/ Is dependency injection implemented correctly throughout the codebase?\"\n\n# Service boundaries\ngemini -p \"@src/services/ Are service responsibilities properly separated? Any violations of single responsibility principle?\"\n```\n\n### Pure Function Validation\n```bash\n# Pure function verification\ngemini -p \"@src/commands/ Verify these are truly pure functions with no side effects. Flag any violations.\"\n\n# Input/output consistency\ngemini -p \"@src/commands/ Do all command functions follow the (args, services) \u2192 CLIResult pattern consistently?\"\n\n# Error handling patterns\ngemini -p \"@src/commands/ @src/common/errors.ts Is error handling implemented consistently across all commands?\"\n```\n\n### Ticket System Analysis\n```bash\n# Ticket format compliance\ngemini -p \"@.tickets/ @CLAUDE.md Do all tickets follow the specified markdown format? What's inconsistent?\"\n\n# Workflow validation\ngemini -p \"@.tickets/ @src/commands/ticket/ Does the ticket management implementation match the documented workflow?\"\n\n# Status tracking accuracy\ngemini -p \"@.tickets/ Are ticket statuses accurately reflecting the actual development state?\"\n\n# GitHub integration analysis\ngemini -p \"@src/services/implementations/GitHubTicketService.ts Is the GitHub Issues integration robust? Check error handling and API usage.\"\n\n# Backend switching validation\ngemini -p \"@src/commands/setup/ @src/commands/migrate/ Are the setup and migration commands reliable for switching between local and GitHub backends?\"\n```\n\n## Claude Code Integration Verification\n\n### MCP Server Analysis\n```bash\n# MCP configuration\ngemini -p \"@.claude/ @src/mcp/ Is the MCP server properly configured for Claude Code integration?\"\n\n# Command documentation\ngemini -p \"@.claude/commands/ Are the command guides accurate and up-to-date with the implementation?\"\n\n# Integration completeness\ngemini -p \"@src/ Does the codebase properly support all documented Claude Code integration features?\"\n```\n\n### Documentation Consistency\n```bash\n# CLAUDE.md accuracy\ngemini -p \"@CLAUDE.md @src/ Does the documentation accurately reflect the current implementation?\"\n\n# Command reference validation\ngemini -p \"@CLAUDE.md @src/cli.ts Are all documented commands actually implemented?\"\n\n# Architecture documentation\ngemini -p \"@CLAUDE.md @src/ Does the documented architecture match the actual codebase structure?\"\n```\n\n## Advanced Analysis Patterns\n\n### Security and Quality Assurance\n```bash\n# Security vulnerability scan\ngemini -p \"@src/ Perform a security audit. Look for input validation issues, authentication flaws, and data exposure risks.\"\n\n# Type safety verification\ngemini -p \"@src/ Check TypeScript strict mode compliance. Find any 'any' types or type safety violations.\"\n\n# Performance profiling\ngemini -p \"@src/ Identify performance bottlenecks and memory leaks. Suggest optimization strategies.\"\n```\n\n### Cross-cutting Concerns\n```bash\n# Logging and monitoring\ngemini -p \"@src/ Is logging implemented consistently? Are there monitoring gaps?\"\n\n# Configuration management\ngemini -p \"@src/ How is configuration handled? Are there hardcoded values that should be configurable?\"\n\n# Internationalization readiness\ngemini -p \"@src/ Is the codebase ready for internationalization? What needs to be externalized?\"\n```\n\n### Migration and Upgrade Analysis\n```bash\n# Dependency updates\ngemini -p \"@package.json @src/ Which dependencies can be safely updated? What are the breaking changes?\"\n\n# Legacy code identification\ngemini -p \"@src/ Identify legacy patterns that should be modernized. Prioritize by impact.\"\n\n# Migration path planning\ngemini -p \"@src/ Plan a migration strategy for upgrading this codebase to newer patterns or frameworks.\"\n```\n\n## TiDD Workflow Specific Queries\n\n### Dialectical Analysis (Socratic Method)\n```bash\n# Challenge assumptions\ngemini -p \"@src/ @CLAUDE.md Challenge the architectural assumptions in this codebase. What could go wrong?\"\n\n# Alternative approaches\ngemini -p \"@src/services/ What are alternative patterns to service injection? Compare pros and cons.\"\n\n# Scale considerations\ngemini -p \"@src/ How will this architecture handle 10x scale? What are the breaking points?\"\n```\n\n### Continuous Improvement\n```bash\n# Code review simulation\ngemini -p \"@src/ Perform a thorough code review. What would you flag in a pull request?\"\n\n# Best practices compliance\ngemini -p \"@src/ Compare this code against TypeScript and Node.js best practices. What needs improvement?\"\n\n# Future-proofing analysis\ngemini -p \"@src/ How future-proof is this architecture? What changes would be needed for emerging requirements?\"\n```\n\n## When to Use Gemini CLI for AIT\u00B3 Projects\n\nUse `gemini -p` when:\n- **TiDD Phase Validation**: Challenging Claude's proposals during PLANNING phase\n- **Large Codebase Analysis**: Analyzing entire project structure exceeding Claude's context\n- **Cross-file Pattern Recognition**: Finding inconsistencies across multiple files\n- **Architecture Compliance**: Verifying implementation matches documented patterns\n- **Security Auditing**: Comprehensive security analysis across all files\n- **Refactoring Planning**: Identifying opportunities for code improvement\n- **Test Coverage Analysis**: Ensuring comprehensive test coverage\n- **Performance Optimization**: Finding bottlenecks across the entire codebase\n- **Documentation Validation**: Ensuring docs match implementation\n\n## Integration with TiDD Workflow\n\n### PLANNING Phase\n1. **Claude proposes** implementation approach\n2. **Gemini challenges** via comprehensive codebase analysis\n3. **Human synthesizes** final decision with full context\n\n### Implementation Phases\n- **RED**: Use Gemini to validate test comprehensiveness\n- **GREEN**: Use Gemini to verify implementation quality\n- **REFACTOR**: Use Gemini to identify optimization opportunities\n- **SQUASH**: Use Gemini to ensure clean, consistent final state\n\n## Important Notes for AIT\u00B3 Development\n\n- **Context Awareness**: Gemini sees the entire codebase, unlike Claude's limited context\n- **Architectural Validation**: Use for verifying pure function + service injection patterns\n- **Ticket Integration**: Include `.tickets/` in analysis for workflow validation\n- **Documentation Sync**: Regularly validate CLAUDE.md against implementation\n- **Quality Assurance**: Use for comprehensive code quality and security analysis\n- **Pattern Consistency**: Ensure all commands follow the established patterns\n- **Future Planning**: Use for analyzing scalability and maintainability\n\n## Claude Code Collaboration\n\nWhen using with Claude Code:\n1. **Use Gemini for analysis**: Get comprehensive project understanding\n2. **Share insights with Claude**: Provide Gemini's findings to Claude for implementation\n3. **Validate with Gemini**: Challenge Claude's implementation with Gemini's perspective\n4. **Human synthesis**: Make final decisions based on both AI perspectives\n\nThis creates the ideal TiDD workflow: Claude proposes \u2192 Gemini refutes \u2192 Human decides.\n";