feat: implement Gemini CLI integration for large codebase analysis
Combined Option A + B implementation providing comprehensive large context analysis: Core Integration: - Add gemini-analysis.md task for massive context window operations - Configure geminiCli settings in core-config.yaml with safety controls - Support @file/directory syntax and --all-files mode for project-wide analysis - Implement configurable approval modes and timeout protections Agent Capabilities: - Add *gemini-analyze command to analyst, architect, and dev agents - Enable large codebase discovery, architecture analysis, and debugging - Support feature verification and pattern discovery across entire projects - Maintain read-only default with approval prompts for modifications Team Configurations: - Create team-gemini-analysis.yaml for specialized large context work - Include comprehensive command templates and usage examples - Integrate with existing fullstack and development workflows Documentation & Safety: - Update CLAUDE.md with comprehensive Gemini CLI usage guide - Provide command templates for common analysis patterns - Include safety measures, path validation, and error handling - Document integration patterns with existing BMAD workflow The system enables analysis of large codebases that exceed normal context limits while maintaining BMAD's safety-first approach and task-based architecture. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
LNKB82REZ2GE4
parent
bbefb25d5f
commit
8324a95286
|
|
@ -0,0 +1,11 @@
|
|||
# <!-- Powered by BMAD™ Core -->
|
||||
bundle:
|
||||
name: Gemini Analysis Team
|
||||
icon: 🔍
|
||||
description: Specialized team for large codebase analysis and comprehensive project understanding using Gemini CLI's massive context window. Ideal for brownfield discovery, architecture analysis, and multi-file investigations.
|
||||
agents:
|
||||
- bmad-orchestrator
|
||||
- analyst
|
||||
- architect
|
||||
- dev
|
||||
workflows: null
|
||||
|
|
@ -65,6 +65,7 @@ commands:
|
|||
- perform-market-research: use task create-doc with market-research-tmpl.yaml
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt.md
|
||||
- gemini-analyze {target}: Analyze large codebases or files using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
|
|
@ -77,6 +78,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- facilitate-brainstorming-session.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- brainstorming-output-tmpl.yaml
|
||||
|
|
|
|||
|
|
@ -65,6 +65,7 @@ commands:
|
|||
- execute-checklist {checklist}: Run task execute-checklist (default->architect-checklist)
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt
|
||||
- gemini-analyze {target}: Analyze large codebases or architectural patterns using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- shard-prd: run the task shard-doc.md for the provided architecture.md (ask if not found)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Architect, and then abandon inhabiting this persona
|
||||
|
|
@ -78,6 +79,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- execute-checklist.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- architecture-tmpl.yaml
|
||||
|
|
|
|||
|
|
@ -69,6 +69,7 @@ commands:
|
|||
- explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
|
||||
- review-qa: run task `apply-qa-fixes.md'
|
||||
- run-tests: Execute linting and tests
|
||||
- gemini-analyze {target}: Analyze large files or debug complex multi-file issues using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
|
||||
|
||||
dependencies:
|
||||
|
|
@ -77,5 +78,6 @@ dependencies:
|
|||
tasks:
|
||||
- apply-qa-fixes.md
|
||||
- execute-checklist.md
|
||||
- gemini-analysis.md
|
||||
- validate-next-story.md
|
||||
```
|
||||
|
|
|
|||
|
|
@ -21,3 +21,19 @@ devLoadAlwaysFiles:
|
|||
devDebugLog: .ai/debug-log.md
|
||||
devStoryLocation: docs/stories
|
||||
slashPrefix: BMad
|
||||
geminiCli:
|
||||
enabled: true
|
||||
defaultApprovalMode: default
|
||||
analysisLocation: docs/analysis
|
||||
commandTemplates:
|
||||
fileAnalysis: 'gemini "@{path} Analyze this file''s structure, purpose, and key patterns"'
|
||||
directoryAnalysis: 'gemini "@{path} Summarize the architecture and patterns in this directory"'
|
||||
projectOverview: 'gemini --all-files "Provide comprehensive overview of this project''s architecture, technology stack, and key decisions"'
|
||||
featureVerification: 'gemini "@{paths} Has {feature} been implemented? Show relevant files and implementation details"'
|
||||
patternSearch: 'gemini "@{paths} Find all instances of {pattern} and list with file paths and examples"'
|
||||
multiFileAnalysis: 'gemini "{paths} {prompt}"'
|
||||
safetySettings:
|
||||
readOnlyDefault: true
|
||||
requireApproval: true
|
||||
maxContextSize: "2GB"
|
||||
timeoutSeconds: 300
|
||||
|
|
|
|||
|
|
@ -0,0 +1,204 @@
|
|||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Gemini CLI Command Templates
|
||||
|
||||
## Standard Analysis Templates
|
||||
|
||||
### Single File Analysis
|
||||
|
||||
```bash
|
||||
gemini "@{file_path} Analyze this file's structure, purpose, and key patterns"
|
||||
gemini "@{file_path} Explain the implementation and identify potential issues"
|
||||
gemini "@{file_path} Document this file's API and usage patterns"
|
||||
```
|
||||
|
||||
### Directory Analysis
|
||||
|
||||
```bash
|
||||
gemini "@{directory}/ Summarize the architecture and patterns in this directory"
|
||||
gemini "@{directory}/ List all components and their responsibilities"
|
||||
gemini "@{directory}/ Identify coding patterns and conventions used"
|
||||
```
|
||||
|
||||
### Project Overview
|
||||
|
||||
```bash
|
||||
gemini --all-files "Provide comprehensive overview of this project's architecture"
|
||||
gemini --all-files "Analyze the technology stack and architectural decisions"
|
||||
gemini --all-files "Document the project structure and key components"
|
||||
```
|
||||
|
||||
## Feature Verification Templates
|
||||
|
||||
### Authentication & Security
|
||||
|
||||
```bash
|
||||
gemini "@src/ @api/ @middleware/ Is JWT authentication fully implemented? Show all auth-related files"
|
||||
gemini "@src/ @lib/ What security measures are implemented? Look for input validation, sanitization"
|
||||
gemini "@api/ @middleware/ Is rate limiting implemented? Show implementation details"
|
||||
gemini "@src/ @config/ Are security headers and CORS properly configured?"
|
||||
```
|
||||
|
||||
### Testing & Quality
|
||||
|
||||
```bash
|
||||
gemini "@src/ @tests/ Analyze test coverage. Which areas are well-tested and need improvement?"
|
||||
gemini "@src/ @__tests__/ What testing patterns are used? Are tests comprehensive?"
|
||||
gemini "@src/ @cypress/ @jest/ What testing frameworks are implemented?"
|
||||
```
|
||||
|
||||
### Performance & Optimization
|
||||
|
||||
```bash
|
||||
gemini "@src/ @lib/ What performance optimizations are in place? Identify bottlenecks"
|
||||
gemini "@webpack.config.js @package.json @src/ How is the build system optimized?"
|
||||
gemini "@src/ @public/ How are assets and static files handled for performance?"
|
||||
```
|
||||
|
||||
### State Management & Data Flow
|
||||
|
||||
```bash
|
||||
gemini "@src/store/ @src/context/ How is state management implemented?"
|
||||
gemini "@src/hooks/ @src/components/ What state management patterns are used?"
|
||||
gemini "@src/api/ @src/services/ How is data fetching and caching handled?"
|
||||
```
|
||||
|
||||
## Architecture Analysis Templates
|
||||
|
||||
### Frontend Architecture
|
||||
|
||||
```bash
|
||||
gemini "@src/components/ @src/pages/ Analyze the frontend component architecture"
|
||||
gemini "@src/hooks/ @src/utils/ What custom hooks and utilities are implemented?"
|
||||
gemini "@src/styles/ @src/assets/ How is styling and theming implemented?"
|
||||
```
|
||||
|
||||
### Backend Architecture
|
||||
|
||||
```bash
|
||||
gemini "@api/ @routes/ @controllers/ Analyze the backend API architecture"
|
||||
gemini "@models/ @schemas/ @database/ How is data modeling implemented?"
|
||||
gemini "@middleware/ @services/ @utils/ What backend services and utilities exist?"
|
||||
```
|
||||
|
||||
### Database & Data Layer
|
||||
|
||||
```bash
|
||||
gemini "@models/ @migrations/ @seeders/ Analyze database structure and migrations"
|
||||
gemini "@queries/ @repositories/ @services/ How is data access layer implemented?"
|
||||
gemini "@config/database.js @models/ What ORM patterns and relationships are used?"
|
||||
```
|
||||
|
||||
## Code Quality Analysis Templates
|
||||
|
||||
### Error Handling
|
||||
|
||||
```bash
|
||||
gemini "@src/ @api/ How is error handling implemented throughout the codebase?"
|
||||
gemini "@middleware/ @utils/ What error handling patterns and utilities exist?"
|
||||
gemini "@src/ @api/ Are try-catch blocks and error boundaries properly implemented?"
|
||||
```
|
||||
|
||||
### Code Organization
|
||||
|
||||
```bash
|
||||
gemini "@src/ How is the code organized? What are the main modules and responsibilities?"
|
||||
gemini "@src/ @lib/ @utils/ What shared utilities and helper functions exist?"
|
||||
gemini "@src/ What naming conventions and coding standards are followed?"
|
||||
```
|
||||
|
||||
### Dependencies & Configuration
|
||||
|
||||
```bash
|
||||
gemini "@package.json @yarn.lock @src/ Analyze dependencies and their usage in code"
|
||||
gemini "@config/ @env/ @src/ How is configuration management implemented?"
|
||||
gemini "@Dockerfile @docker-compose.yml How is containerization configured?"
|
||||
```
|
||||
|
||||
## Debugging & Investigation Templates
|
||||
|
||||
### Bug Investigation
|
||||
|
||||
```bash
|
||||
gemini "@src/components/{component}/ @src/hooks/ Debug {specific_issue} in this component"
|
||||
gemini "@api/routes/{route}/ @middleware/ Investigate {issue} in this API endpoint"
|
||||
gemini "@src/store/ @src/hooks/ Debug state management issues with {feature}"
|
||||
```
|
||||
|
||||
### Performance Investigation
|
||||
|
||||
```bash
|
||||
gemini "@src/ @webpack.config.js Identify performance bottlenecks in build process"
|
||||
gemini "@src/components/ @src/hooks/ Find performance issues in React components"
|
||||
gemini "@api/ @database/ Identify database query performance issues"
|
||||
```
|
||||
|
||||
### Integration Analysis
|
||||
|
||||
```bash
|
||||
gemini "@frontend/ @backend/ How do frontend and backend communicate?"
|
||||
gemini "@src/api/ @services/ How are external services integrated?"
|
||||
gemini "@src/auth/ @api/auth/ How does authentication work across the application?"
|
||||
```
|
||||
|
||||
## Multi-Project Templates
|
||||
|
||||
### Monorepo Analysis
|
||||
|
||||
```bash
|
||||
gemini "@packages/ @apps/ Analyze this monorepo structure and dependencies"
|
||||
gemini "@lerna.json @package.json @packages/ How is the monorepo managed?"
|
||||
gemini "@packages/ What shared components and utilities exist across packages?"
|
||||
```
|
||||
|
||||
### Microservices Analysis
|
||||
|
||||
```bash
|
||||
gemini "@services/ @docker-compose.yml Analyze microservices architecture"
|
||||
gemini "@api-gateway/ @services/ How is service communication implemented?"
|
||||
gemini "@services/ @shared/ What shared code exists between services?"
|
||||
```
|
||||
|
||||
## Safety Command Templates
|
||||
|
||||
### Read-Only Analysis (Safest)
|
||||
|
||||
```bash
|
||||
gemini --approval-mode default "@{paths} {prompt}"
|
||||
```
|
||||
|
||||
### Auto-Edit Mode (Edit files automatically)
|
||||
|
||||
```bash
|
||||
gemini --approval-mode auto_edit "@{paths} {prompt}"
|
||||
```
|
||||
|
||||
### Sandbox Mode (Safe environment)
|
||||
|
||||
```bash
|
||||
gemini --sandbox "@{paths} {prompt}"
|
||||
```
|
||||
|
||||
## Command Construction Patterns
|
||||
|
||||
### Path Validation
|
||||
|
||||
- Always validate paths exist before construction
|
||||
- Use relative paths from current working directory
|
||||
- Include trailing slash for directories: `@src/`
|
||||
- Specific files without slash: `@package.json`
|
||||
|
||||
### Prompt Construction
|
||||
|
||||
- Be specific about what you want analyzed
|
||||
- Include context about the codebase/project type
|
||||
- Specify output format if needed (list, summary, detailed)
|
||||
- Ask for file paths in responses for follow-up
|
||||
|
||||
### Common Path Combinations
|
||||
|
||||
- **Full Stack**: `@src/ @api/ @database/ @config/`
|
||||
- **Frontend Only**: `@src/ @public/ @package.json`
|
||||
- **Backend Only**: `@api/ @services/ @models/ @config/`
|
||||
- **Testing Focus**: `@src/ @tests/ @__tests__/ @cypress/`
|
||||
- **Documentation**: `@docs/ @README.md @CHANGELOG.md`
|
||||
|
|
@ -0,0 +1,289 @@
|
|||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Gemini Analysis Task
|
||||
|
||||
## Purpose
|
||||
|
||||
This task provides access to Google Gemini CLI's massive context window for analyzing large codebases, big files, or complex multi-file operations that exceed normal context limits. Gemini CLI can handle entire project contexts that would overflow standard AI context windows.
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- **Massive Context Window**: Analyze entire codebases without context limitations
|
||||
- **File & Directory Inclusion**: Use `@` syntax for precise file/directory targeting
|
||||
- **Multi-File Analysis**: Compare and analyze multiple large files simultaneously
|
||||
- **Codebase Flattening**: Alternative to local flattener for large projects
|
||||
- **Feature Verification**: Check if specific features are implemented across entire projects
|
||||
- **Pattern Discovery**: Find patterns, implementations, and architectural decisions project-wide
|
||||
|
||||
## When to Use Gemini Analysis
|
||||
|
||||
### Ideal Use Cases
|
||||
|
||||
- **Large Codebase Architecture Analysis**: Understanding overall system design
|
||||
- **Multi-File Pattern Searching**: Finding implementations across multiple files
|
||||
- **Feature Implementation Verification**: Checking if features exist project-wide
|
||||
- **Brownfield Project Discovery**: Understanding existing large codebases
|
||||
- **Context-Heavy Debugging**: Analyzing complex interactions across many files
|
||||
- **Comprehensive Code Reviews**: Reviewing entire feature implementations
|
||||
|
||||
### Context Size Triggers
|
||||
|
||||
- Files or directories totaling >100KB of content
|
||||
- Analysis requiring >20 files simultaneously
|
||||
- Project-wide architectural understanding needed
|
||||
- Current context window insufficient for task
|
||||
|
||||
## Analysis Modes
|
||||
|
||||
### 1. Single File Analysis
|
||||
|
||||
**Use Case**: Deep analysis of large individual files
|
||||
**Command Pattern**: `gemini "@file/path Analyze this file's structure and purpose"`
|
||||
**Examples**:
|
||||
|
||||
- `@src/main.py Explain this file's architecture and key patterns`
|
||||
- `@config/webpack.config.js Break down this configuration and its impact`
|
||||
|
||||
### 2. Directory Analysis
|
||||
|
||||
**Use Case**: Understanding structure and patterns within specific directories
|
||||
**Command Pattern**: `gemini "@directory/ Analyze the architecture of this codebase section"`
|
||||
**Examples**:
|
||||
|
||||
- `@src/components/ Summarize the component architecture and patterns`
|
||||
- `@api/routes/ Document all API endpoints and their purposes`
|
||||
|
||||
### 3. Multi-Path Analysis
|
||||
|
||||
**Use Case**: Comparing and analyzing relationships between multiple areas
|
||||
**Command Pattern**: `gemini "@path1 @path2 Analyze relationships between these areas"`
|
||||
**Examples**:
|
||||
|
||||
- `@src/ @tests/ Analyze test coverage for the source code`
|
||||
- `@frontend/ @backend/ How do these communicate and what are the integration points?`
|
||||
|
||||
### 4. Project Overview
|
||||
|
||||
**Use Case**: Comprehensive understanding of entire project
|
||||
**Command Pattern**: `gemini --all-files "Provide comprehensive project analysis"`
|
||||
**Examples**:
|
||||
|
||||
- `--all-files "Give me an architectural overview of this entire project"`
|
||||
- `--all-files "Summarize the technology stack and key architectural decisions"`
|
||||
|
||||
### 5. Feature Verification
|
||||
|
||||
**Use Case**: Checking if specific features or patterns are implemented
|
||||
**Command Pattern**: `gemini "@codebase/ Has [feature] been implemented? Show relevant files"`
|
||||
**Examples**:
|
||||
|
||||
- `@src/ @lib/ Has dark mode been implemented? Show relevant files and functions`
|
||||
- `@api/ @middleware/ Is rate limiting implemented? Show the implementation details`
|
||||
|
||||
### 6. Pattern Discovery
|
||||
|
||||
**Use Case**: Finding specific coding patterns, security measures, or architectural decisions
|
||||
**Command Pattern**: `gemini "@codebase/ Find all instances of [pattern] and list with file paths"`
|
||||
**Examples**:
|
||||
|
||||
- `@src/ Are there any React hooks that handle WebSocket connections?`
|
||||
- `@backend/ Is proper error handling implemented for all endpoints?`
|
||||
|
||||
## Task Process
|
||||
|
||||
### 1. Analysis Request Processing
|
||||
|
||||
#### Gather Requirements
|
||||
|
||||
- **Analysis Type**: Which mode fits the user's need?
|
||||
- **Target Paths**: What files/directories should be included?
|
||||
- **Analysis Depth**: High-level overview vs detailed analysis?
|
||||
- **Specific Questions**: What particular aspects to focus on?
|
||||
- **Output Format**: How should results be presented?
|
||||
|
||||
#### Path Validation
|
||||
|
||||
- **Existence Check**: Verify all specified paths exist
|
||||
- **Size Assessment**: Estimate total content size
|
||||
- **Permission Validation**: Ensure readable access
|
||||
- **Safety Check**: Confirm read-only analysis scope
|
||||
|
||||
### 2. Command Construction
|
||||
|
||||
#### Basic Command Structure
|
||||
|
||||
```bash
|
||||
gemini [options] "@path1 @path2 [prompt]"
|
||||
```
|
||||
|
||||
#### Option Selection
|
||||
|
||||
- **Standard Mode**: `gemini "@path prompt"`
|
||||
- **All Files Mode**: `gemini --all-files "prompt"`
|
||||
- **Safe Mode**: `gemini --approval-mode default "@path prompt"`
|
||||
- **Sandbox Mode**: `gemini --sandbox "@path prompt"` (if editing needed)
|
||||
|
||||
#### Path Formatting
|
||||
|
||||
- **Single File**: `@src/main.py`
|
||||
- **Directory**: `@src/components/`
|
||||
- **Multiple Paths**: `@src/ @tests/ @docs/`
|
||||
- **Current Directory**: `@./`
|
||||
- **Specific Files**: `@package.json @README.md`
|
||||
|
||||
### 3. Safety and Validation
|
||||
|
||||
#### Pre-Execution Checks
|
||||
|
||||
- **Read-Only Confirmation**: Ensure analysis-only intent
|
||||
- **Path Sanitization**: Validate and clean file paths
|
||||
- **Size Warnings**: Alert for extremely large contexts
|
||||
- **Approval Mode**: Set appropriate safety level
|
||||
|
||||
#### Command Safety Options
|
||||
|
||||
```yaml
|
||||
safety_levels:
|
||||
read_only: 'Default - analysis only, no modifications'
|
||||
default: 'Prompt for any file modifications'
|
||||
auto_edit: 'Auto-approve edit tools only'
|
||||
sandbox: 'Run in safe sandbox environment'
|
||||
```
|
||||
|
||||
### 4. Execution and Results
|
||||
|
||||
#### Command Execution
|
||||
|
||||
1. **Validate Paths**: Confirm all targets exist and are accessible
|
||||
2. **Construct Command**: Build proper Gemini CLI command
|
||||
3. **Execute Analysis**: Run Gemini CLI with specified parameters
|
||||
4. **Capture Output**: Collect and format analysis results
|
||||
5. **Error Handling**: Manage CLI failures or timeouts
|
||||
|
||||
#### Result Processing
|
||||
|
||||
- **Output Formatting**: Structure results for readability
|
||||
- **Key Insights Extraction**: Highlight critical findings
|
||||
- **Follow-up Suggestions**: Recommend next steps
|
||||
- **Source Documentation**: Reference analyzed files/paths
|
||||
|
||||
### 5. Integration with BMAD Workflow
|
||||
|
||||
#### Result Documentation
|
||||
|
||||
- **Store in Project**: Save significant analyses in `docs/analysis/`
|
||||
- **Reference in Stories**: Link analyses to relevant development stories
|
||||
- **Architecture Updates**: Update architecture docs with findings
|
||||
- **Knowledge Preservation**: Maintain analysis artifacts for team reference
|
||||
|
||||
#### Follow-Up Actions
|
||||
|
||||
- **Story Creation**: Generate development stories from findings
|
||||
- **Architecture Review**: Update architectural documentation
|
||||
- **Technical Debt**: Identify and document technical debt items
|
||||
- **Research Coordination**: Trigger detailed research if needed
|
||||
|
||||
## Command Templates
|
||||
|
||||
### Architecture Analysis
|
||||
|
||||
```bash
|
||||
# Overall project architecture
|
||||
gemini --all-files "Analyze the overall architecture of this project. Include technology stack, key patterns, and architectural decisions."
|
||||
|
||||
# Specific component architecture
|
||||
gemini "@src/components/ Analyze the component architecture. What patterns are used and how are components organized?"
|
||||
|
||||
# Backend architecture
|
||||
gemini "@api/ @services/ @middleware/ Analyze the backend architecture. How are routes organized and what patterns are used?"
|
||||
```
|
||||
|
||||
### Feature Verification
|
||||
|
||||
```bash
|
||||
# Authentication implementation
|
||||
gemini "@src/ @api/ Is JWT authentication fully implemented? Show all auth-related files and middleware."
|
||||
|
||||
# Security measures
|
||||
gemini "@src/ @api/ What security measures are implemented? Look for input validation, CORS, rate limiting."
|
||||
|
||||
# Testing coverage
|
||||
gemini "@src/ @tests/ Analyze test coverage. Which areas are well-tested and which need more tests?"
|
||||
```
|
||||
|
||||
### Code Quality Analysis
|
||||
|
||||
```bash
|
||||
# Error handling patterns
|
||||
gemini "@src/ @api/ How is error handling implemented throughout the codebase? Show examples."
|
||||
|
||||
# Performance considerations
|
||||
gemini "@src/ @lib/ What performance optimizations are in place? Identify potential bottlenecks."
|
||||
|
||||
# Code organization
|
||||
gemini "@src/ How is the code organized? What are the main modules and their responsibilities?"
|
||||
```
|
||||
|
||||
### Technology Assessment
|
||||
|
||||
```bash
|
||||
# Dependency analysis
|
||||
gemini "@package.json @src/ What are the key dependencies and how are they used in the code?"
|
||||
|
||||
# Build system analysis
|
||||
gemini "@webpack.config.js @package.json @src/ How is the build system configured and what optimizations are in place?"
|
||||
|
||||
# Database integration
|
||||
gemini "@models/ @migrations/ @src/ How is the database integrated? What ORM patterns are used?"
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Issues
|
||||
|
||||
- **Path Not Found**: Specified files/directories don't exist
|
||||
- **Context Too Large**: Even Gemini's context has limits
|
||||
- **CLI Unavailable**: Gemini CLI not installed or configured
|
||||
- **Permission Denied**: Cannot read specified files
|
||||
- **Command Timeout**: Analysis takes too long to complete
|
||||
|
||||
### Error Recovery
|
||||
|
||||
- **Path Validation**: Pre-validate all paths before execution
|
||||
- **Graceful Degradation**: Suggest smaller scope if context too large
|
||||
- **Alternative Approaches**: Offer local flattener or partial analysis
|
||||
- **Clear Error Messages**: Provide actionable error information
|
||||
- **Fallback Options**: Suggest manual analysis approaches
|
||||
|
||||
### Safety Measures
|
||||
|
||||
- **Read-Only Default**: Never modify files without explicit permission
|
||||
- **Approval Prompts**: Confirm any file modifications
|
||||
- **Sandbox Options**: Use sandbox mode for risky operations
|
||||
- **Timeout Protection**: Prevent hanging operations
|
||||
- **Resource Monitoring**: Track memory and processing usage
|
||||
|
||||
## Integration Notes
|
||||
|
||||
### With Existing BMAD Tools
|
||||
|
||||
- **Flattener Integration**: Use existing flattener for preprocessing when needed
|
||||
- **Research Coordination**: Can trigger research system for follow-up analysis
|
||||
- **Story Generation**: Results can inform story creation
|
||||
- **Architecture Documentation**: Updates architectural understanding
|
||||
|
||||
### With Core Configuration
|
||||
|
||||
- **Command Templates**: Stored in core-config.yaml for consistency
|
||||
- **Default Settings**: Safety and approval modes configured globally
|
||||
- **Path Patterns**: Common path combinations for different project types
|
||||
- **Integration Points**: How Gemini analysis feeds into BMAD workflow
|
||||
|
||||
### Agent Accessibility
|
||||
|
||||
All agents with Gemini analysis capability will have access to:
|
||||
|
||||
- **Standard Analysis**: `*gemini-analyze` command for common patterns
|
||||
- **Custom Queries**: Ability to specify custom analysis prompts
|
||||
- **Result Integration**: Automatic integration with agent workflows
|
||||
- **Safety Controls**: Appropriate safety measures for agent context
|
||||
|
|
@ -84,6 +84,7 @@ commands:
|
|||
- perform-market-research: use task create-doc with market-research-tmpl.yaml
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt.md
|
||||
- gemini-analyze {target}: Analyze large codebases or files using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
|
|
@ -96,6 +97,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- facilitate-brainstorming-session.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- brainstorming-output-tmpl.yaml
|
||||
|
|
@ -1105,6 +1107,262 @@ Generate structured document with these sections:
|
|||
- Respect their process and timing
|
||||
==================== END: .bmad-core/tasks/facilitate-brainstorming-session.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Gemini Analysis Task
|
||||
|
||||
## Purpose
|
||||
|
||||
This task provides access to Google Gemini CLI's massive context window for analyzing large codebases, big files, or complex multi-file operations that exceed normal context limits. Gemini CLI can handle entire project contexts that would overflow standard AI context windows.
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- **Massive Context Window**: Analyze entire codebases without context limitations
|
||||
- **File & Directory Inclusion**: Use `@` syntax for precise file/directory targeting
|
||||
- **Multi-File Analysis**: Compare and analyze multiple large files simultaneously
|
||||
- **Codebase Flattening**: Alternative to local flattener for large projects
|
||||
- **Feature Verification**: Check if specific features are implemented across entire projects
|
||||
- **Pattern Discovery**: Find patterns, implementations, and architectural decisions project-wide
|
||||
|
||||
## When to Use Gemini Analysis
|
||||
|
||||
### Ideal Use Cases
|
||||
- **Large Codebase Architecture Analysis**: Understanding overall system design
|
||||
- **Multi-File Pattern Searching**: Finding implementations across multiple files
|
||||
- **Feature Implementation Verification**: Checking if features exist project-wide
|
||||
- **Brownfield Project Discovery**: Understanding existing large codebases
|
||||
- **Context-Heavy Debugging**: Analyzing complex interactions across many files
|
||||
- **Comprehensive Code Reviews**: Reviewing entire feature implementations
|
||||
|
||||
### Context Size Triggers
|
||||
- Files or directories totaling >100KB of content
|
||||
- Analysis requiring >20 files simultaneously
|
||||
- Project-wide architectural understanding needed
|
||||
- Current context window insufficient for task
|
||||
|
||||
## Analysis Modes
|
||||
|
||||
### 1. Single File Analysis
|
||||
**Use Case**: Deep analysis of large individual files
|
||||
**Command Pattern**: `gemini "@file/path Analyze this file's structure and purpose"`
|
||||
**Examples**:
|
||||
- `@src/main.py Explain this file's architecture and key patterns`
|
||||
- `@config/webpack.config.js Break down this configuration and its impact`
|
||||
|
||||
### 2. Directory Analysis
|
||||
**Use Case**: Understanding structure and patterns within specific directories
|
||||
**Command Pattern**: `gemini "@directory/ Analyze the architecture of this codebase section"`
|
||||
**Examples**:
|
||||
- `@src/components/ Summarize the component architecture and patterns`
|
||||
- `@api/routes/ Document all API endpoints and their purposes`
|
||||
|
||||
### 3. Multi-Path Analysis
|
||||
**Use Case**: Comparing and analyzing relationships between multiple areas
|
||||
**Command Pattern**: `gemini "@path1 @path2 Analyze relationships between these areas"`
|
||||
**Examples**:
|
||||
- `@src/ @tests/ Analyze test coverage for the source code`
|
||||
- `@frontend/ @backend/ How do these communicate and what are the integration points?`
|
||||
|
||||
### 4. Project Overview
|
||||
**Use Case**: Comprehensive understanding of entire project
|
||||
**Command Pattern**: `gemini --all-files "Provide comprehensive project analysis"`
|
||||
**Examples**:
|
||||
- `--all-files "Give me an architectural overview of this entire project"`
|
||||
- `--all-files "Summarize the technology stack and key architectural decisions"`
|
||||
|
||||
### 5. Feature Verification
|
||||
**Use Case**: Checking if specific features or patterns are implemented
|
||||
**Command Pattern**: `gemini "@codebase/ Has [feature] been implemented? Show relevant files"`
|
||||
**Examples**:
|
||||
- `@src/ @lib/ Has dark mode been implemented? Show relevant files and functions`
|
||||
- `@api/ @middleware/ Is rate limiting implemented? Show the implementation details`
|
||||
|
||||
### 6. Pattern Discovery
|
||||
**Use Case**: Finding specific coding patterns, security measures, or architectural decisions
|
||||
**Command Pattern**: `gemini "@codebase/ Find all instances of [pattern] and list with file paths"`
|
||||
**Examples**:
|
||||
- `@src/ Are there any React hooks that handle WebSocket connections?`
|
||||
- `@backend/ Is proper error handling implemented for all endpoints?`
|
||||
|
||||
## Task Process
|
||||
|
||||
### 1. Analysis Request Processing
|
||||
|
||||
#### Gather Requirements
|
||||
- **Analysis Type**: Which mode fits the user's need?
|
||||
- **Target Paths**: What files/directories should be included?
|
||||
- **Analysis Depth**: High-level overview vs detailed analysis?
|
||||
- **Specific Questions**: What particular aspects to focus on?
|
||||
- **Output Format**: How should results be presented?
|
||||
|
||||
#### Path Validation
|
||||
- **Existence Check**: Verify all specified paths exist
|
||||
- **Size Assessment**: Estimate total content size
|
||||
- **Permission Validation**: Ensure readable access
|
||||
- **Safety Check**: Confirm read-only analysis scope
|
||||
|
||||
### 2. Command Construction
|
||||
|
||||
#### Basic Command Structure
|
||||
```bash
|
||||
gemini [options] "@path1 @path2 [prompt]"
|
||||
```
|
||||
|
||||
#### Option Selection
|
||||
- **Standard Mode**: `gemini "@path prompt"`
|
||||
- **All Files Mode**: `gemini --all-files "prompt"`
|
||||
- **Safe Mode**: `gemini --approval-mode default "@path prompt"`
|
||||
- **Sandbox Mode**: `gemini --sandbox "@path prompt"` (if editing needed)
|
||||
|
||||
#### Path Formatting
|
||||
- **Single File**: `@src/main.py`
|
||||
- **Directory**: `@src/components/`
|
||||
- **Multiple Paths**: `@src/ @tests/ @docs/`
|
||||
- **Current Directory**: `@./`
|
||||
- **Specific Files**: `@package.json @README.md`
|
||||
|
||||
### 3. Safety and Validation
|
||||
|
||||
#### Pre-Execution Checks
|
||||
- **Read-Only Confirmation**: Ensure analysis-only intent
|
||||
- **Path Sanitization**: Validate and clean file paths
|
||||
- **Size Warnings**: Alert for extremely large contexts
|
||||
- **Approval Mode**: Set appropriate safety level
|
||||
|
||||
#### Command Safety Options
|
||||
```yaml
|
||||
safety_levels:
|
||||
read_only: "Default - analysis only, no modifications"
|
||||
default: "Prompt for any file modifications"
|
||||
auto_edit: "Auto-approve edit tools only"
|
||||
sandbox: "Run in safe sandbox environment"
|
||||
```
|
||||
|
||||
### 4. Execution and Results
|
||||
|
||||
#### Command Execution
|
||||
1. **Validate Paths**: Confirm all targets exist and are accessible
|
||||
2. **Construct Command**: Build proper Gemini CLI command
|
||||
3. **Execute Analysis**: Run Gemini CLI with specified parameters
|
||||
4. **Capture Output**: Collect and format analysis results
|
||||
5. **Error Handling**: Manage CLI failures or timeouts
|
||||
|
||||
#### Result Processing
|
||||
- **Output Formatting**: Structure results for readability
|
||||
- **Key Insights Extraction**: Highlight critical findings
|
||||
- **Follow-up Suggestions**: Recommend next steps
|
||||
- **Source Documentation**: Reference analyzed files/paths
|
||||
|
||||
### 5. Integration with BMAD Workflow
|
||||
|
||||
#### Result Documentation
|
||||
- **Store in Project**: Save significant analyses in `docs/analysis/`
|
||||
- **Reference in Stories**: Link analyses to relevant development stories
|
||||
- **Architecture Updates**: Update architecture docs with findings
|
||||
- **Knowledge Preservation**: Maintain analysis artifacts for team reference
|
||||
|
||||
#### Follow-Up Actions
|
||||
- **Story Creation**: Generate development stories from findings
|
||||
- **Architecture Review**: Update architectural documentation
|
||||
- **Technical Debt**: Identify and document technical debt items
|
||||
- **Research Coordination**: Trigger detailed research if needed
|
||||
|
||||
## Command Templates
|
||||
|
||||
### Architecture Analysis
|
||||
```bash
|
||||
# Overall project architecture
|
||||
gemini --all-files "Analyze the overall architecture of this project. Include technology stack, key patterns, and architectural decisions."
|
||||
|
||||
# Specific component architecture
|
||||
gemini "@src/components/ Analyze the component architecture. What patterns are used and how are components organized?"
|
||||
|
||||
# Backend architecture
|
||||
gemini "@api/ @services/ @middleware/ Analyze the backend architecture. How are routes organized and what patterns are used?"
|
||||
```
|
||||
|
||||
### Feature Verification
|
||||
```bash
|
||||
# Authentication implementation
|
||||
gemini "@src/ @api/ Is JWT authentication fully implemented? Show all auth-related files and middleware."
|
||||
|
||||
# Security measures
|
||||
gemini "@src/ @api/ What security measures are implemented? Look for input validation, CORS, rate limiting."
|
||||
|
||||
# Testing coverage
|
||||
gemini "@src/ @tests/ Analyze test coverage. Which areas are well-tested and which need more tests?"
|
||||
```
|
||||
|
||||
### Code Quality Analysis
|
||||
```bash
|
||||
# Error handling patterns
|
||||
gemini "@src/ @api/ How is error handling implemented throughout the codebase? Show examples."
|
||||
|
||||
# Performance considerations
|
||||
gemini "@src/ @lib/ What performance optimizations are in place? Identify potential bottlenecks."
|
||||
|
||||
# Code organization
|
||||
gemini "@src/ How is the code organized? What are the main modules and their responsibilities?"
|
||||
```
|
||||
|
||||
### Technology Assessment
|
||||
```bash
|
||||
# Dependency analysis
|
||||
gemini "@package.json @src/ What are the key dependencies and how are they used in the code?"
|
||||
|
||||
# Build system analysis
|
||||
gemini "@webpack.config.js @package.json @src/ How is the build system configured and what optimizations are in place?"
|
||||
|
||||
# Database integration
|
||||
gemini "@models/ @migrations/ @src/ How is the database integrated? What ORM patterns are used?"
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Issues
|
||||
- **Path Not Found**: Specified files/directories don't exist
|
||||
- **Context Too Large**: Even Gemini's context has limits
|
||||
- **CLI Unavailable**: Gemini CLI not installed or configured
|
||||
- **Permission Denied**: Cannot read specified files
|
||||
- **Command Timeout**: Analysis takes too long to complete
|
||||
|
||||
### Error Recovery
|
||||
- **Path Validation**: Pre-validate all paths before execution
|
||||
- **Graceful Degradation**: Suggest smaller scope if context too large
|
||||
- **Alternative Approaches**: Offer local flattener or partial analysis
|
||||
- **Clear Error Messages**: Provide actionable error information
|
||||
- **Fallback Options**: Suggest manual analysis approaches
|
||||
|
||||
### Safety Measures
|
||||
- **Read-Only Default**: Never modify files without explicit permission
|
||||
- **Approval Prompts**: Confirm any file modifications
|
||||
- **Sandbox Options**: Use sandbox mode for risky operations
|
||||
- **Timeout Protection**: Prevent hanging operations
|
||||
- **Resource Monitoring**: Track memory and processing usage
|
||||
|
||||
## Integration Notes
|
||||
|
||||
### With Existing BMAD Tools
|
||||
- **Flattener Integration**: Use existing flattener for preprocessing when needed
|
||||
- **Research Coordination**: Can trigger research system for follow-up analysis
|
||||
- **Story Generation**: Results can inform story creation
|
||||
- **Architecture Documentation**: Updates architectural understanding
|
||||
|
||||
### With Core Configuration
|
||||
- **Command Templates**: Stored in core-config.yaml for consistency
|
||||
- **Default Settings**: Safety and approval modes configured globally
|
||||
- **Path Patterns**: Common path combinations for different project types
|
||||
- **Integration Points**: How Gemini analysis feeds into BMAD workflow
|
||||
|
||||
### Agent Accessibility
|
||||
All agents with Gemini analysis capability will have access to:
|
||||
- **Standard Analysis**: `*gemini-analyze` command for common patterns
|
||||
- **Custom Queries**: Ability to specify custom analysis prompts
|
||||
- **Result Integration**: Automatic integration with agent workflows
|
||||
- **Safety Controls**: Appropriate safety measures for agent context
|
||||
==================== END: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/request-research.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
|
|
@ -1125,6 +1383,7 @@ This task provides a unified interface for any agent to request specialized rese
|
|||
## Usage Scenarios
|
||||
|
||||
### From Any Agent
|
||||
|
||||
Any agent can call this task to get specialized research assistance:
|
||||
|
||||
```yaml
|
||||
|
|
@ -1146,24 +1405,28 @@ Any agent can call this task to get specialized research assistance:
|
|||
The task will elicit a structured research request with these components:
|
||||
|
||||
#### Research Context
|
||||
|
||||
- **Requesting Agent**: Which agent is making the request
|
||||
- **Project Context**: Current project phase and relevant background
|
||||
- **Previous Research**: Check research log for related prior work
|
||||
- **Urgency Level**: Timeline constraints and priority
|
||||
|
||||
#### Research Objective
|
||||
|
||||
- **Primary Goal**: What specific question or problem needs researching
|
||||
- **Success Criteria**: How to measure if research achieved its objective
|
||||
- **Scope Boundaries**: What to include/exclude from research
|
||||
- **Decision Impact**: How results will be used
|
||||
|
||||
#### Domain Specialization Requirements
|
||||
|
||||
- **Primary Domain**: Main area of expertise needed (technical, market, user, etc.)
|
||||
- **Secondary Domains**: Additional perspectives required
|
||||
- **Specific Expertise**: Particular skills or knowledge areas
|
||||
- **Research Depth**: High-level overview vs deep technical analysis
|
||||
|
||||
#### Output Requirements
|
||||
|
||||
- **Format**: Executive summary, detailed report, comparison matrix, etc.
|
||||
- **Audience**: Who will consume the research results
|
||||
- **Integration**: How results feed into next steps
|
||||
|
|
@ -1192,12 +1455,14 @@ Each Researcher Agent will:
|
|||
### 4. Result Delivery
|
||||
|
||||
#### To Requesting Agent
|
||||
|
||||
- **Executive Summary**: Key findings and recommendations
|
||||
- **Detailed Analysis**: Comprehensive research results
|
||||
- **Source Documentation**: Links and citations for verification
|
||||
- **Next Steps**: Recommended actions or follow-up research
|
||||
|
||||
#### To Research Log
|
||||
|
||||
- **Research Entry**: Concise summary stored in `docs/research/YYYY-MM-DD-research-topic.md`
|
||||
- **Index Update**: Add entry to `docs/research/research-index.md`
|
||||
- **Tag Classification**: Add searchable tags for future reference
|
||||
|
|
@ -1216,40 +1481,40 @@ When executing this task, use this structure for research requests:
|
|||
```yaml
|
||||
research_request:
|
||||
metadata:
|
||||
requesting_agent: "[agent-id]"
|
||||
request_date: "[YYYY-MM-DD]"
|
||||
priority: "[high|medium|low]"
|
||||
timeline: "[timeframe needed]"
|
||||
requesting_agent: '[agent-id]'
|
||||
request_date: '[YYYY-MM-DD]'
|
||||
priority: '[high|medium|low]'
|
||||
timeline: '[timeframe needed]'
|
||||
|
||||
context:
|
||||
project_phase: "[planning|development|validation|etc]"
|
||||
background: "[relevant project context]"
|
||||
related_docs: "[PRD, architecture, stories, etc]"
|
||||
previous_research: "[check research log references]"
|
||||
project_phase: '[planning|development|validation|etc]'
|
||||
background: '[relevant project context]'
|
||||
related_docs: '[PRD, architecture, stories, etc]'
|
||||
previous_research: '[check research log references]'
|
||||
|
||||
objective:
|
||||
primary_goal: "[specific research question]"
|
||||
success_criteria: "[how to measure success]"
|
||||
scope: "[boundaries and limitations]"
|
||||
decision_impact: "[how results will be used]"
|
||||
primary_goal: '[specific research question]'
|
||||
success_criteria: '[how to measure success]'
|
||||
scope: '[boundaries and limitations]'
|
||||
decision_impact: '[how results will be used]'
|
||||
|
||||
specialization:
|
||||
primary_domain: "[technical|market|user|competitive|regulatory|etc]"
|
||||
secondary_domains: "[additional perspectives needed]"
|
||||
specific_expertise: "[particular skills required]"
|
||||
research_depth: "[overview|detailed|comprehensive]"
|
||||
primary_domain: '[technical|market|user|competitive|regulatory|etc]'
|
||||
secondary_domains: '[additional perspectives needed]'
|
||||
specific_expertise: '[particular skills required]'
|
||||
research_depth: '[overview|detailed|comprehensive]'
|
||||
|
||||
team_config:
|
||||
researcher_count: "[1-3, default 3]"
|
||||
perspective_1: "[domain and focus area]"
|
||||
perspective_2: "[domain and focus area]"
|
||||
perspective_3: "[domain and focus area]"
|
||||
researcher_count: '[1-3, default 3]'
|
||||
perspective_1: '[domain and focus area]'
|
||||
perspective_2: '[domain and focus area]'
|
||||
perspective_3: '[domain and focus area]'
|
||||
|
||||
output:
|
||||
format: "[executive_summary|detailed_report|comparison_matrix|etc]"
|
||||
audience: "[who will use results]"
|
||||
integration: "[how results feed into workflow]"
|
||||
citation_level: "[minimal|standard|comprehensive]"
|
||||
format: '[executive_summary|detailed_report|comparison_matrix|etc]'
|
||||
audience: '[who will use results]'
|
||||
integration: '[how results feed into workflow]'
|
||||
citation_level: '[minimal|standard|comprehensive]'
|
||||
```
|
||||
|
||||
## Integration with Existing Agents
|
||||
|
|
@ -1281,26 +1546,32 @@ commands:
|
|||
## Research Log Structure
|
||||
|
||||
### Research Index (`docs/research/research-index.md`)
|
||||
|
||||
```markdown
|
||||
# Research Index
|
||||
|
||||
## Recent Research
|
||||
|
||||
- [2024-01-15: AI Model Comparison](2024-01-15-ai-model-comparison.md) - Technical analysis of LLM options
|
||||
- [2024-01-12: Payment Gateway Analysis](2024-01-12-payment-gateway-analysis.md) - Market comparison of payment solutions
|
||||
|
||||
## Research by Category
|
||||
|
||||
### Technical Research
|
||||
|
||||
- AI/ML Models
|
||||
- Architecture Decisions
|
||||
- Technology Stacks
|
||||
|
||||
### Market Research
|
||||
|
||||
- Competitive Analysis
|
||||
- User Behavior
|
||||
- Industry Trends
|
||||
```
|
||||
|
||||
### Individual Research Files (`docs/research/YYYY-MM-DD-topic.md`)
|
||||
|
||||
```markdown
|
||||
# Research: [Topic]
|
||||
|
||||
|
|
@ -1309,31 +1580,41 @@ commands:
|
|||
**Research Team**: [perspectives used]
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[Key findings and recommendations]
|
||||
|
||||
## Research Objective
|
||||
|
||||
[What was being researched and why]
|
||||
|
||||
## Key Findings
|
||||
|
||||
[Main insights from all perspectives]
|
||||
|
||||
## Recommendations
|
||||
|
||||
[Actionable next steps]
|
||||
|
||||
## Research Team Perspectives
|
||||
|
||||
### Perspective 1: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 2: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 3: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
## Sources and References
|
||||
|
||||
[Credible sources cited by research team]
|
||||
|
||||
## Tags
|
||||
|
||||
[Searchable tags for future reference]
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -84,6 +84,7 @@ commands:
|
|||
- execute-checklist {checklist}: Run task execute-checklist (default->architect-checklist)
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt
|
||||
- gemini-analyze {target}: Analyze large codebases or architectural patterns using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- shard-prd: run the task shard-doc.md for the provided architecture.md (ask if not found)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Architect, and then abandon inhabiting this persona
|
||||
|
|
@ -97,6 +98,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- execute-checklist.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- architecture-tmpl.yaml
|
||||
|
|
@ -934,6 +936,262 @@ The LLM will:
|
|||
- Offer to provide detailed analysis of any section, especially those with warnings or failures
|
||||
==================== END: .bmad-core/tasks/execute-checklist.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Gemini Analysis Task
|
||||
|
||||
## Purpose
|
||||
|
||||
This task provides access to Google Gemini CLI's massive context window for analyzing large codebases, big files, or complex multi-file operations that exceed normal context limits. Gemini CLI can handle entire project contexts that would overflow standard AI context windows.
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- **Massive Context Window**: Analyze entire codebases without context limitations
|
||||
- **File & Directory Inclusion**: Use `@` syntax for precise file/directory targeting
|
||||
- **Multi-File Analysis**: Compare and analyze multiple large files simultaneously
|
||||
- **Codebase Flattening**: Alternative to local flattener for large projects
|
||||
- **Feature Verification**: Check if specific features are implemented across entire projects
|
||||
- **Pattern Discovery**: Find patterns, implementations, and architectural decisions project-wide
|
||||
|
||||
## When to Use Gemini Analysis
|
||||
|
||||
### Ideal Use Cases
|
||||
- **Large Codebase Architecture Analysis**: Understanding overall system design
|
||||
- **Multi-File Pattern Searching**: Finding implementations across multiple files
|
||||
- **Feature Implementation Verification**: Checking if features exist project-wide
|
||||
- **Brownfield Project Discovery**: Understanding existing large codebases
|
||||
- **Context-Heavy Debugging**: Analyzing complex interactions across many files
|
||||
- **Comprehensive Code Reviews**: Reviewing entire feature implementations
|
||||
|
||||
### Context Size Triggers
|
||||
- Files or directories totaling >100KB of content
|
||||
- Analysis requiring >20 files simultaneously
|
||||
- Project-wide architectural understanding needed
|
||||
- Current context window insufficient for task
|
||||
|
||||
## Analysis Modes
|
||||
|
||||
### 1. Single File Analysis
|
||||
**Use Case**: Deep analysis of large individual files
|
||||
**Command Pattern**: `gemini "@file/path Analyze this file's structure and purpose"`
|
||||
**Examples**:
|
||||
- `@src/main.py Explain this file's architecture and key patterns`
|
||||
- `@config/webpack.config.js Break down this configuration and its impact`
|
||||
|
||||
### 2. Directory Analysis
|
||||
**Use Case**: Understanding structure and patterns within specific directories
|
||||
**Command Pattern**: `gemini "@directory/ Analyze the architecture of this codebase section"`
|
||||
**Examples**:
|
||||
- `@src/components/ Summarize the component architecture and patterns`
|
||||
- `@api/routes/ Document all API endpoints and their purposes`
|
||||
|
||||
### 3. Multi-Path Analysis
|
||||
**Use Case**: Comparing and analyzing relationships between multiple areas
|
||||
**Command Pattern**: `gemini "@path1 @path2 Analyze relationships between these areas"`
|
||||
**Examples**:
|
||||
- `@src/ @tests/ Analyze test coverage for the source code`
|
||||
- `@frontend/ @backend/ How do these communicate and what are the integration points?`
|
||||
|
||||
### 4. Project Overview
|
||||
**Use Case**: Comprehensive understanding of entire project
|
||||
**Command Pattern**: `gemini --all-files "Provide comprehensive project analysis"`
|
||||
**Examples**:
|
||||
- `--all-files "Give me an architectural overview of this entire project"`
|
||||
- `--all-files "Summarize the technology stack and key architectural decisions"`
|
||||
|
||||
### 5. Feature Verification
|
||||
**Use Case**: Checking if specific features or patterns are implemented
|
||||
**Command Pattern**: `gemini "@codebase/ Has [feature] been implemented? Show relevant files"`
|
||||
**Examples**:
|
||||
- `@src/ @lib/ Has dark mode been implemented? Show relevant files and functions`
|
||||
- `@api/ @middleware/ Is rate limiting implemented? Show the implementation details`
|
||||
|
||||
### 6. Pattern Discovery
|
||||
**Use Case**: Finding specific coding patterns, security measures, or architectural decisions
|
||||
**Command Pattern**: `gemini "@codebase/ Find all instances of [pattern] and list with file paths"`
|
||||
**Examples**:
|
||||
- `@src/ Are there any React hooks that handle WebSocket connections?`
|
||||
- `@backend/ Is proper error handling implemented for all endpoints?`
|
||||
|
||||
## Task Process
|
||||
|
||||
### 1. Analysis Request Processing
|
||||
|
||||
#### Gather Requirements
|
||||
- **Analysis Type**: Which mode fits the user's need?
|
||||
- **Target Paths**: What files/directories should be included?
|
||||
- **Analysis Depth**: High-level overview vs detailed analysis?
|
||||
- **Specific Questions**: What particular aspects to focus on?
|
||||
- **Output Format**: How should results be presented?
|
||||
|
||||
#### Path Validation
|
||||
- **Existence Check**: Verify all specified paths exist
|
||||
- **Size Assessment**: Estimate total content size
|
||||
- **Permission Validation**: Ensure readable access
|
||||
- **Safety Check**: Confirm read-only analysis scope
|
||||
|
||||
### 2. Command Construction
|
||||
|
||||
#### Basic Command Structure
|
||||
```bash
|
||||
gemini [options] "@path1 @path2 [prompt]"
|
||||
```
|
||||
|
||||
#### Option Selection
|
||||
- **Standard Mode**: `gemini "@path prompt"`
|
||||
- **All Files Mode**: `gemini --all-files "prompt"`
|
||||
- **Safe Mode**: `gemini --approval-mode default "@path prompt"`
|
||||
- **Sandbox Mode**: `gemini --sandbox "@path prompt"` (if editing needed)
|
||||
|
||||
#### Path Formatting
|
||||
- **Single File**: `@src/main.py`
|
||||
- **Directory**: `@src/components/`
|
||||
- **Multiple Paths**: `@src/ @tests/ @docs/`
|
||||
- **Current Directory**: `@./`
|
||||
- **Specific Files**: `@package.json @README.md`
|
||||
|
||||
### 3. Safety and Validation
|
||||
|
||||
#### Pre-Execution Checks
|
||||
- **Read-Only Confirmation**: Ensure analysis-only intent
|
||||
- **Path Sanitization**: Validate and clean file paths
|
||||
- **Size Warnings**: Alert for extremely large contexts
|
||||
- **Approval Mode**: Set appropriate safety level
|
||||
|
||||
#### Command Safety Options
|
||||
```yaml
|
||||
safety_levels:
|
||||
read_only: "Default - analysis only, no modifications"
|
||||
default: "Prompt for any file modifications"
|
||||
auto_edit: "Auto-approve edit tools only"
|
||||
sandbox: "Run in safe sandbox environment"
|
||||
```
|
||||
|
||||
### 4. Execution and Results
|
||||
|
||||
#### Command Execution
|
||||
1. **Validate Paths**: Confirm all targets exist and are accessible
|
||||
2. **Construct Command**: Build proper Gemini CLI command
|
||||
3. **Execute Analysis**: Run Gemini CLI with specified parameters
|
||||
4. **Capture Output**: Collect and format analysis results
|
||||
5. **Error Handling**: Manage CLI failures or timeouts
|
||||
|
||||
#### Result Processing
|
||||
- **Output Formatting**: Structure results for readability
|
||||
- **Key Insights Extraction**: Highlight critical findings
|
||||
- **Follow-up Suggestions**: Recommend next steps
|
||||
- **Source Documentation**: Reference analyzed files/paths
|
||||
|
||||
### 5. Integration with BMAD Workflow
|
||||
|
||||
#### Result Documentation
|
||||
- **Store in Project**: Save significant analyses in `docs/analysis/`
|
||||
- **Reference in Stories**: Link analyses to relevant development stories
|
||||
- **Architecture Updates**: Update architecture docs with findings
|
||||
- **Knowledge Preservation**: Maintain analysis artifacts for team reference
|
||||
|
||||
#### Follow-Up Actions
|
||||
- **Story Creation**: Generate development stories from findings
|
||||
- **Architecture Review**: Update architectural documentation
|
||||
- **Technical Debt**: Identify and document technical debt items
|
||||
- **Research Coordination**: Trigger detailed research if needed
|
||||
|
||||
## Command Templates
|
||||
|
||||
### Architecture Analysis
|
||||
```bash
|
||||
# Overall project architecture
|
||||
gemini --all-files "Analyze the overall architecture of this project. Include technology stack, key patterns, and architectural decisions."
|
||||
|
||||
# Specific component architecture
|
||||
gemini "@src/components/ Analyze the component architecture. What patterns are used and how are components organized?"
|
||||
|
||||
# Backend architecture
|
||||
gemini "@api/ @services/ @middleware/ Analyze the backend architecture. How are routes organized and what patterns are used?"
|
||||
```
|
||||
|
||||
### Feature Verification
|
||||
```bash
|
||||
# Authentication implementation
|
||||
gemini "@src/ @api/ Is JWT authentication fully implemented? Show all auth-related files and middleware."
|
||||
|
||||
# Security measures
|
||||
gemini "@src/ @api/ What security measures are implemented? Look for input validation, CORS, rate limiting."
|
||||
|
||||
# Testing coverage
|
||||
gemini "@src/ @tests/ Analyze test coverage. Which areas are well-tested and which need more tests?"
|
||||
```
|
||||
|
||||
### Code Quality Analysis
|
||||
```bash
|
||||
# Error handling patterns
|
||||
gemini "@src/ @api/ How is error handling implemented throughout the codebase? Show examples."
|
||||
|
||||
# Performance considerations
|
||||
gemini "@src/ @lib/ What performance optimizations are in place? Identify potential bottlenecks."
|
||||
|
||||
# Code organization
|
||||
gemini "@src/ How is the code organized? What are the main modules and their responsibilities?"
|
||||
```
|
||||
|
||||
### Technology Assessment
|
||||
```bash
|
||||
# Dependency analysis
|
||||
gemini "@package.json @src/ What are the key dependencies and how are they used in the code?"
|
||||
|
||||
# Build system analysis
|
||||
gemini "@webpack.config.js @package.json @src/ How is the build system configured and what optimizations are in place?"
|
||||
|
||||
# Database integration
|
||||
gemini "@models/ @migrations/ @src/ How is the database integrated? What ORM patterns are used?"
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Issues
|
||||
- **Path Not Found**: Specified files/directories don't exist
|
||||
- **Context Too Large**: Even Gemini's context has limits
|
||||
- **CLI Unavailable**: Gemini CLI not installed or configured
|
||||
- **Permission Denied**: Cannot read specified files
|
||||
- **Command Timeout**: Analysis takes too long to complete
|
||||
|
||||
### Error Recovery
|
||||
- **Path Validation**: Pre-validate all paths before execution
|
||||
- **Graceful Degradation**: Suggest smaller scope if context too large
|
||||
- **Alternative Approaches**: Offer local flattener or partial analysis
|
||||
- **Clear Error Messages**: Provide actionable error information
|
||||
- **Fallback Options**: Suggest manual analysis approaches
|
||||
|
||||
### Safety Measures
|
||||
- **Read-Only Default**: Never modify files without explicit permission
|
||||
- **Approval Prompts**: Confirm any file modifications
|
||||
- **Sandbox Options**: Use sandbox mode for risky operations
|
||||
- **Timeout Protection**: Prevent hanging operations
|
||||
- **Resource Monitoring**: Track memory and processing usage
|
||||
|
||||
## Integration Notes
|
||||
|
||||
### With Existing BMAD Tools
|
||||
- **Flattener Integration**: Use existing flattener for preprocessing when needed
|
||||
- **Research Coordination**: Can trigger research system for follow-up analysis
|
||||
- **Story Generation**: Results can inform story creation
|
||||
- **Architecture Documentation**: Updates architectural understanding
|
||||
|
||||
### With Core Configuration
|
||||
- **Command Templates**: Stored in core-config.yaml for consistency
|
||||
- **Default Settings**: Safety and approval modes configured globally
|
||||
- **Path Patterns**: Common path combinations for different project types
|
||||
- **Integration Points**: How Gemini analysis feeds into BMAD workflow
|
||||
|
||||
### Agent Accessibility
|
||||
All agents with Gemini analysis capability will have access to:
|
||||
- **Standard Analysis**: `*gemini-analyze` command for common patterns
|
||||
- **Custom Queries**: Ability to specify custom analysis prompts
|
||||
- **Result Integration**: Automatic integration with agent workflows
|
||||
- **Safety Controls**: Appropriate safety measures for agent context
|
||||
==================== END: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/request-research.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
|
|
@ -954,6 +1212,7 @@ This task provides a unified interface for any agent to request specialized rese
|
|||
## Usage Scenarios
|
||||
|
||||
### From Any Agent
|
||||
|
||||
Any agent can call this task to get specialized research assistance:
|
||||
|
||||
```yaml
|
||||
|
|
@ -975,24 +1234,28 @@ Any agent can call this task to get specialized research assistance:
|
|||
The task will elicit a structured research request with these components:
|
||||
|
||||
#### Research Context
|
||||
|
||||
- **Requesting Agent**: Which agent is making the request
|
||||
- **Project Context**: Current project phase and relevant background
|
||||
- **Previous Research**: Check research log for related prior work
|
||||
- **Urgency Level**: Timeline constraints and priority
|
||||
|
||||
#### Research Objective
|
||||
|
||||
- **Primary Goal**: What specific question or problem needs researching
|
||||
- **Success Criteria**: How to measure if research achieved its objective
|
||||
- **Scope Boundaries**: What to include/exclude from research
|
||||
- **Decision Impact**: How results will be used
|
||||
|
||||
#### Domain Specialization Requirements
|
||||
|
||||
- **Primary Domain**: Main area of expertise needed (technical, market, user, etc.)
|
||||
- **Secondary Domains**: Additional perspectives required
|
||||
- **Specific Expertise**: Particular skills or knowledge areas
|
||||
- **Research Depth**: High-level overview vs deep technical analysis
|
||||
|
||||
#### Output Requirements
|
||||
|
||||
- **Format**: Executive summary, detailed report, comparison matrix, etc.
|
||||
- **Audience**: Who will consume the research results
|
||||
- **Integration**: How results feed into next steps
|
||||
|
|
@ -1021,12 +1284,14 @@ Each Researcher Agent will:
|
|||
### 4. Result Delivery
|
||||
|
||||
#### To Requesting Agent
|
||||
|
||||
- **Executive Summary**: Key findings and recommendations
|
||||
- **Detailed Analysis**: Comprehensive research results
|
||||
- **Source Documentation**: Links and citations for verification
|
||||
- **Next Steps**: Recommended actions or follow-up research
|
||||
|
||||
#### To Research Log
|
||||
|
||||
- **Research Entry**: Concise summary stored in `docs/research/YYYY-MM-DD-research-topic.md`
|
||||
- **Index Update**: Add entry to `docs/research/research-index.md`
|
||||
- **Tag Classification**: Add searchable tags for future reference
|
||||
|
|
@ -1045,40 +1310,40 @@ When executing this task, use this structure for research requests:
|
|||
```yaml
|
||||
research_request:
|
||||
metadata:
|
||||
requesting_agent: "[agent-id]"
|
||||
request_date: "[YYYY-MM-DD]"
|
||||
priority: "[high|medium|low]"
|
||||
timeline: "[timeframe needed]"
|
||||
requesting_agent: '[agent-id]'
|
||||
request_date: '[YYYY-MM-DD]'
|
||||
priority: '[high|medium|low]'
|
||||
timeline: '[timeframe needed]'
|
||||
|
||||
context:
|
||||
project_phase: "[planning|development|validation|etc]"
|
||||
background: "[relevant project context]"
|
||||
related_docs: "[PRD, architecture, stories, etc]"
|
||||
previous_research: "[check research log references]"
|
||||
project_phase: '[planning|development|validation|etc]'
|
||||
background: '[relevant project context]'
|
||||
related_docs: '[PRD, architecture, stories, etc]'
|
||||
previous_research: '[check research log references]'
|
||||
|
||||
objective:
|
||||
primary_goal: "[specific research question]"
|
||||
success_criteria: "[how to measure success]"
|
||||
scope: "[boundaries and limitations]"
|
||||
decision_impact: "[how results will be used]"
|
||||
primary_goal: '[specific research question]'
|
||||
success_criteria: '[how to measure success]'
|
||||
scope: '[boundaries and limitations]'
|
||||
decision_impact: '[how results will be used]'
|
||||
|
||||
specialization:
|
||||
primary_domain: "[technical|market|user|competitive|regulatory|etc]"
|
||||
secondary_domains: "[additional perspectives needed]"
|
||||
specific_expertise: "[particular skills required]"
|
||||
research_depth: "[overview|detailed|comprehensive]"
|
||||
primary_domain: '[technical|market|user|competitive|regulatory|etc]'
|
||||
secondary_domains: '[additional perspectives needed]'
|
||||
specific_expertise: '[particular skills required]'
|
||||
research_depth: '[overview|detailed|comprehensive]'
|
||||
|
||||
team_config:
|
||||
researcher_count: "[1-3, default 3]"
|
||||
perspective_1: "[domain and focus area]"
|
||||
perspective_2: "[domain and focus area]"
|
||||
perspective_3: "[domain and focus area]"
|
||||
researcher_count: '[1-3, default 3]'
|
||||
perspective_1: '[domain and focus area]'
|
||||
perspective_2: '[domain and focus area]'
|
||||
perspective_3: '[domain and focus area]'
|
||||
|
||||
output:
|
||||
format: "[executive_summary|detailed_report|comparison_matrix|etc]"
|
||||
audience: "[who will use results]"
|
||||
integration: "[how results feed into workflow]"
|
||||
citation_level: "[minimal|standard|comprehensive]"
|
||||
format: '[executive_summary|detailed_report|comparison_matrix|etc]'
|
||||
audience: '[who will use results]'
|
||||
integration: '[how results feed into workflow]'
|
||||
citation_level: '[minimal|standard|comprehensive]'
|
||||
```
|
||||
|
||||
## Integration with Existing Agents
|
||||
|
|
@ -1110,26 +1375,32 @@ commands:
|
|||
## Research Log Structure
|
||||
|
||||
### Research Index (`docs/research/research-index.md`)
|
||||
|
||||
```markdown
|
||||
# Research Index
|
||||
|
||||
## Recent Research
|
||||
|
||||
- [2024-01-15: AI Model Comparison](2024-01-15-ai-model-comparison.md) - Technical analysis of LLM options
|
||||
- [2024-01-12: Payment Gateway Analysis](2024-01-12-payment-gateway-analysis.md) - Market comparison of payment solutions
|
||||
|
||||
## Research by Category
|
||||
|
||||
### Technical Research
|
||||
|
||||
- AI/ML Models
|
||||
- Architecture Decisions
|
||||
- Technology Stacks
|
||||
|
||||
### Market Research
|
||||
|
||||
- Competitive Analysis
|
||||
- User Behavior
|
||||
- Industry Trends
|
||||
```
|
||||
|
||||
### Individual Research Files (`docs/research/YYYY-MM-DD-topic.md`)
|
||||
|
||||
```markdown
|
||||
# Research: [Topic]
|
||||
|
||||
|
|
@ -1138,31 +1409,41 @@ commands:
|
|||
**Research Team**: [perspectives used]
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[Key findings and recommendations]
|
||||
|
||||
## Research Objective
|
||||
|
||||
[What was being researched and why]
|
||||
|
||||
## Key Findings
|
||||
|
||||
[Main insights from all perspectives]
|
||||
|
||||
## Recommendations
|
||||
|
||||
[Actionable next steps]
|
||||
|
||||
## Research Team Perspectives
|
||||
|
||||
### Perspective 1: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 2: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 3: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
## Sources and References
|
||||
|
||||
[Credible sources cited by research team]
|
||||
|
||||
## Tags
|
||||
|
||||
[Searchable tags for future reference]
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -82,6 +82,7 @@ commands:
|
|||
- explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
|
||||
- review-qa: run task `apply-qa-fixes.md'
|
||||
- run-tests: Execute linting and tests
|
||||
- gemini-analyze {target}: Analyze large files or debug complex multi-file issues using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
checklists:
|
||||
|
|
@ -89,6 +90,7 @@ dependencies:
|
|||
tasks:
|
||||
- apply-qa-fixes.md
|
||||
- execute-checklist.md
|
||||
- gemini-analysis.md
|
||||
- validate-next-story.md
|
||||
```
|
||||
==================== END: .bmad-core/agents/dev.md ====================
|
||||
|
|
@ -337,6 +339,262 @@ The LLM will:
|
|||
- Offer to provide detailed analysis of any section, especially those with warnings or failures
|
||||
==================== END: .bmad-core/tasks/execute-checklist.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Gemini Analysis Task
|
||||
|
||||
## Purpose
|
||||
|
||||
This task provides access to Google Gemini CLI's massive context window for analyzing large codebases, big files, or complex multi-file operations that exceed normal context limits. Gemini CLI can handle entire project contexts that would overflow standard AI context windows.
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- **Massive Context Window**: Analyze entire codebases without context limitations
|
||||
- **File & Directory Inclusion**: Use `@` syntax for precise file/directory targeting
|
||||
- **Multi-File Analysis**: Compare and analyze multiple large files simultaneously
|
||||
- **Codebase Flattening**: Alternative to local flattener for large projects
|
||||
- **Feature Verification**: Check if specific features are implemented across entire projects
|
||||
- **Pattern Discovery**: Find patterns, implementations, and architectural decisions project-wide
|
||||
|
||||
## When to Use Gemini Analysis
|
||||
|
||||
### Ideal Use Cases
|
||||
- **Large Codebase Architecture Analysis**: Understanding overall system design
|
||||
- **Multi-File Pattern Searching**: Finding implementations across multiple files
|
||||
- **Feature Implementation Verification**: Checking if features exist project-wide
|
||||
- **Brownfield Project Discovery**: Understanding existing large codebases
|
||||
- **Context-Heavy Debugging**: Analyzing complex interactions across many files
|
||||
- **Comprehensive Code Reviews**: Reviewing entire feature implementations
|
||||
|
||||
### Context Size Triggers
|
||||
- Files or directories totaling >100KB of content
|
||||
- Analysis requiring >20 files simultaneously
|
||||
- Project-wide architectural understanding needed
|
||||
- Current context window insufficient for task
|
||||
|
||||
## Analysis Modes
|
||||
|
||||
### 1. Single File Analysis
|
||||
**Use Case**: Deep analysis of large individual files
|
||||
**Command Pattern**: `gemini "@file/path Analyze this file's structure and purpose"`
|
||||
**Examples**:
|
||||
- `@src/main.py Explain this file's architecture and key patterns`
|
||||
- `@config/webpack.config.js Break down this configuration and its impact`
|
||||
|
||||
### 2. Directory Analysis
|
||||
**Use Case**: Understanding structure and patterns within specific directories
|
||||
**Command Pattern**: `gemini "@directory/ Analyze the architecture of this codebase section"`
|
||||
**Examples**:
|
||||
- `@src/components/ Summarize the component architecture and patterns`
|
||||
- `@api/routes/ Document all API endpoints and their purposes`
|
||||
|
||||
### 3. Multi-Path Analysis
|
||||
**Use Case**: Comparing and analyzing relationships between multiple areas
|
||||
**Command Pattern**: `gemini "@path1 @path2 Analyze relationships between these areas"`
|
||||
**Examples**:
|
||||
- `@src/ @tests/ Analyze test coverage for the source code`
|
||||
- `@frontend/ @backend/ How do these communicate and what are the integration points?`
|
||||
|
||||
### 4. Project Overview
|
||||
**Use Case**: Comprehensive understanding of entire project
|
||||
**Command Pattern**: `gemini --all-files "Provide comprehensive project analysis"`
|
||||
**Examples**:
|
||||
- `--all-files "Give me an architectural overview of this entire project"`
|
||||
- `--all-files "Summarize the technology stack and key architectural decisions"`
|
||||
|
||||
### 5. Feature Verification
|
||||
**Use Case**: Checking if specific features or patterns are implemented
|
||||
**Command Pattern**: `gemini "@codebase/ Has [feature] been implemented? Show relevant files"`
|
||||
**Examples**:
|
||||
- `@src/ @lib/ Has dark mode been implemented? Show relevant files and functions`
|
||||
- `@api/ @middleware/ Is rate limiting implemented? Show the implementation details`
|
||||
|
||||
### 6. Pattern Discovery
|
||||
**Use Case**: Finding specific coding patterns, security measures, or architectural decisions
|
||||
**Command Pattern**: `gemini "@codebase/ Find all instances of [pattern] and list with file paths"`
|
||||
**Examples**:
|
||||
- `@src/ Are there any React hooks that handle WebSocket connections?`
|
||||
- `@backend/ Is proper error handling implemented for all endpoints?`
|
||||
|
||||
## Task Process
|
||||
|
||||
### 1. Analysis Request Processing
|
||||
|
||||
#### Gather Requirements
|
||||
- **Analysis Type**: Which mode fits the user's need?
|
||||
- **Target Paths**: What files/directories should be included?
|
||||
- **Analysis Depth**: High-level overview vs detailed analysis?
|
||||
- **Specific Questions**: What particular aspects to focus on?
|
||||
- **Output Format**: How should results be presented?
|
||||
|
||||
#### Path Validation
|
||||
- **Existence Check**: Verify all specified paths exist
|
||||
- **Size Assessment**: Estimate total content size
|
||||
- **Permission Validation**: Ensure readable access
|
||||
- **Safety Check**: Confirm read-only analysis scope
|
||||
|
||||
### 2. Command Construction
|
||||
|
||||
#### Basic Command Structure
|
||||
```bash
|
||||
gemini [options] "@path1 @path2 [prompt]"
|
||||
```
|
||||
|
||||
#### Option Selection
|
||||
- **Standard Mode**: `gemini "@path prompt"`
|
||||
- **All Files Mode**: `gemini --all-files "prompt"`
|
||||
- **Safe Mode**: `gemini --approval-mode default "@path prompt"`
|
||||
- **Sandbox Mode**: `gemini --sandbox "@path prompt"` (if editing needed)
|
||||
|
||||
#### Path Formatting
|
||||
- **Single File**: `@src/main.py`
|
||||
- **Directory**: `@src/components/`
|
||||
- **Multiple Paths**: `@src/ @tests/ @docs/`
|
||||
- **Current Directory**: `@./`
|
||||
- **Specific Files**: `@package.json @README.md`
|
||||
|
||||
### 3. Safety and Validation
|
||||
|
||||
#### Pre-Execution Checks
|
||||
- **Read-Only Confirmation**: Ensure analysis-only intent
|
||||
- **Path Sanitization**: Validate and clean file paths
|
||||
- **Size Warnings**: Alert for extremely large contexts
|
||||
- **Approval Mode**: Set appropriate safety level
|
||||
|
||||
#### Command Safety Options
|
||||
```yaml
|
||||
safety_levels:
|
||||
read_only: "Default - analysis only, no modifications"
|
||||
default: "Prompt for any file modifications"
|
||||
auto_edit: "Auto-approve edit tools only"
|
||||
sandbox: "Run in safe sandbox environment"
|
||||
```
|
||||
|
||||
### 4. Execution and Results
|
||||
|
||||
#### Command Execution
|
||||
1. **Validate Paths**: Confirm all targets exist and are accessible
|
||||
2. **Construct Command**: Build proper Gemini CLI command
|
||||
3. **Execute Analysis**: Run Gemini CLI with specified parameters
|
||||
4. **Capture Output**: Collect and format analysis results
|
||||
5. **Error Handling**: Manage CLI failures or timeouts
|
||||
|
||||
#### Result Processing
|
||||
- **Output Formatting**: Structure results for readability
|
||||
- **Key Insights Extraction**: Highlight critical findings
|
||||
- **Follow-up Suggestions**: Recommend next steps
|
||||
- **Source Documentation**: Reference analyzed files/paths
|
||||
|
||||
### 5. Integration with BMAD Workflow
|
||||
|
||||
#### Result Documentation
|
||||
- **Store in Project**: Save significant analyses in `docs/analysis/`
|
||||
- **Reference in Stories**: Link analyses to relevant development stories
|
||||
- **Architecture Updates**: Update architecture docs with findings
|
||||
- **Knowledge Preservation**: Maintain analysis artifacts for team reference
|
||||
|
||||
#### Follow-Up Actions
|
||||
- **Story Creation**: Generate development stories from findings
|
||||
- **Architecture Review**: Update architectural documentation
|
||||
- **Technical Debt**: Identify and document technical debt items
|
||||
- **Research Coordination**: Trigger detailed research if needed
|
||||
|
||||
## Command Templates
|
||||
|
||||
### Architecture Analysis
|
||||
```bash
|
||||
# Overall project architecture
|
||||
gemini --all-files "Analyze the overall architecture of this project. Include technology stack, key patterns, and architectural decisions."
|
||||
|
||||
# Specific component architecture
|
||||
gemini "@src/components/ Analyze the component architecture. What patterns are used and how are components organized?"
|
||||
|
||||
# Backend architecture
|
||||
gemini "@api/ @services/ @middleware/ Analyze the backend architecture. How are routes organized and what patterns are used?"
|
||||
```
|
||||
|
||||
### Feature Verification
|
||||
```bash
|
||||
# Authentication implementation
|
||||
gemini "@src/ @api/ Is JWT authentication fully implemented? Show all auth-related files and middleware."
|
||||
|
||||
# Security measures
|
||||
gemini "@src/ @api/ What security measures are implemented? Look for input validation, CORS, rate limiting."
|
||||
|
||||
# Testing coverage
|
||||
gemini "@src/ @tests/ Analyze test coverage. Which areas are well-tested and which need more tests?"
|
||||
```
|
||||
|
||||
### Code Quality Analysis
|
||||
```bash
|
||||
# Error handling patterns
|
||||
gemini "@src/ @api/ How is error handling implemented throughout the codebase? Show examples."
|
||||
|
||||
# Performance considerations
|
||||
gemini "@src/ @lib/ What performance optimizations are in place? Identify potential bottlenecks."
|
||||
|
||||
# Code organization
|
||||
gemini "@src/ How is the code organized? What are the main modules and their responsibilities?"
|
||||
```
|
||||
|
||||
### Technology Assessment
|
||||
```bash
|
||||
# Dependency analysis
|
||||
gemini "@package.json @src/ What are the key dependencies and how are they used in the code?"
|
||||
|
||||
# Build system analysis
|
||||
gemini "@webpack.config.js @package.json @src/ How is the build system configured and what optimizations are in place?"
|
||||
|
||||
# Database integration
|
||||
gemini "@models/ @migrations/ @src/ How is the database integrated? What ORM patterns are used?"
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Issues
|
||||
- **Path Not Found**: Specified files/directories don't exist
|
||||
- **Context Too Large**: Even Gemini's context has limits
|
||||
- **CLI Unavailable**: Gemini CLI not installed or configured
|
||||
- **Permission Denied**: Cannot read specified files
|
||||
- **Command Timeout**: Analysis takes too long to complete
|
||||
|
||||
### Error Recovery
|
||||
- **Path Validation**: Pre-validate all paths before execution
|
||||
- **Graceful Degradation**: Suggest smaller scope if context too large
|
||||
- **Alternative Approaches**: Offer local flattener or partial analysis
|
||||
- **Clear Error Messages**: Provide actionable error information
|
||||
- **Fallback Options**: Suggest manual analysis approaches
|
||||
|
||||
### Safety Measures
|
||||
- **Read-Only Default**: Never modify files without explicit permission
|
||||
- **Approval Prompts**: Confirm any file modifications
|
||||
- **Sandbox Options**: Use sandbox mode for risky operations
|
||||
- **Timeout Protection**: Prevent hanging operations
|
||||
- **Resource Monitoring**: Track memory and processing usage
|
||||
|
||||
## Integration Notes
|
||||
|
||||
### With Existing BMAD Tools
|
||||
- **Flattener Integration**: Use existing flattener for preprocessing when needed
|
||||
- **Research Coordination**: Can trigger research system for follow-up analysis
|
||||
- **Story Generation**: Results can inform story creation
|
||||
- **Architecture Documentation**: Updates architectural understanding
|
||||
|
||||
### With Core Configuration
|
||||
- **Command Templates**: Stored in core-config.yaml for consistency
|
||||
- **Default Settings**: Safety and approval modes configured globally
|
||||
- **Path Patterns**: Common path combinations for different project types
|
||||
- **Integration Points**: How Gemini analysis feeds into BMAD workflow
|
||||
|
||||
### Agent Accessibility
|
||||
All agents with Gemini analysis capability will have access to:
|
||||
- **Standard Analysis**: `*gemini-analyze` command for common patterns
|
||||
- **Custom Queries**: Ability to specify custom analysis prompts
|
||||
- **Result Integration**: Automatic integration with agent workflows
|
||||
- **Safety Controls**: Appropriate safety measures for agent context
|
||||
==================== END: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/validate-next-story.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
|
|
|
|||
|
|
@ -997,6 +997,7 @@ This task provides a unified interface for any agent to request specialized rese
|
|||
## Usage Scenarios
|
||||
|
||||
### From Any Agent
|
||||
|
||||
Any agent can call this task to get specialized research assistance:
|
||||
|
||||
```yaml
|
||||
|
|
@ -1018,24 +1019,28 @@ Any agent can call this task to get specialized research assistance:
|
|||
The task will elicit a structured research request with these components:
|
||||
|
||||
#### Research Context
|
||||
|
||||
- **Requesting Agent**: Which agent is making the request
|
||||
- **Project Context**: Current project phase and relevant background
|
||||
- **Previous Research**: Check research log for related prior work
|
||||
- **Urgency Level**: Timeline constraints and priority
|
||||
|
||||
#### Research Objective
|
||||
|
||||
- **Primary Goal**: What specific question or problem needs researching
|
||||
- **Success Criteria**: How to measure if research achieved its objective
|
||||
- **Scope Boundaries**: What to include/exclude from research
|
||||
- **Decision Impact**: How results will be used
|
||||
|
||||
#### Domain Specialization Requirements
|
||||
|
||||
- **Primary Domain**: Main area of expertise needed (technical, market, user, etc.)
|
||||
- **Secondary Domains**: Additional perspectives required
|
||||
- **Specific Expertise**: Particular skills or knowledge areas
|
||||
- **Research Depth**: High-level overview vs deep technical analysis
|
||||
|
||||
#### Output Requirements
|
||||
|
||||
- **Format**: Executive summary, detailed report, comparison matrix, etc.
|
||||
- **Audience**: Who will consume the research results
|
||||
- **Integration**: How results feed into next steps
|
||||
|
|
@ -1064,12 +1069,14 @@ Each Researcher Agent will:
|
|||
### 4. Result Delivery
|
||||
|
||||
#### To Requesting Agent
|
||||
|
||||
- **Executive Summary**: Key findings and recommendations
|
||||
- **Detailed Analysis**: Comprehensive research results
|
||||
- **Source Documentation**: Links and citations for verification
|
||||
- **Next Steps**: Recommended actions or follow-up research
|
||||
|
||||
#### To Research Log
|
||||
|
||||
- **Research Entry**: Concise summary stored in `docs/research/YYYY-MM-DD-research-topic.md`
|
||||
- **Index Update**: Add entry to `docs/research/research-index.md`
|
||||
- **Tag Classification**: Add searchable tags for future reference
|
||||
|
|
@ -1088,40 +1095,40 @@ When executing this task, use this structure for research requests:
|
|||
```yaml
|
||||
research_request:
|
||||
metadata:
|
||||
requesting_agent: "[agent-id]"
|
||||
request_date: "[YYYY-MM-DD]"
|
||||
priority: "[high|medium|low]"
|
||||
timeline: "[timeframe needed]"
|
||||
requesting_agent: '[agent-id]'
|
||||
request_date: '[YYYY-MM-DD]'
|
||||
priority: '[high|medium|low]'
|
||||
timeline: '[timeframe needed]'
|
||||
|
||||
context:
|
||||
project_phase: "[planning|development|validation|etc]"
|
||||
background: "[relevant project context]"
|
||||
related_docs: "[PRD, architecture, stories, etc]"
|
||||
previous_research: "[check research log references]"
|
||||
project_phase: '[planning|development|validation|etc]'
|
||||
background: '[relevant project context]'
|
||||
related_docs: '[PRD, architecture, stories, etc]'
|
||||
previous_research: '[check research log references]'
|
||||
|
||||
objective:
|
||||
primary_goal: "[specific research question]"
|
||||
success_criteria: "[how to measure success]"
|
||||
scope: "[boundaries and limitations]"
|
||||
decision_impact: "[how results will be used]"
|
||||
primary_goal: '[specific research question]'
|
||||
success_criteria: '[how to measure success]'
|
||||
scope: '[boundaries and limitations]'
|
||||
decision_impact: '[how results will be used]'
|
||||
|
||||
specialization:
|
||||
primary_domain: "[technical|market|user|competitive|regulatory|etc]"
|
||||
secondary_domains: "[additional perspectives needed]"
|
||||
specific_expertise: "[particular skills required]"
|
||||
research_depth: "[overview|detailed|comprehensive]"
|
||||
primary_domain: '[technical|market|user|competitive|regulatory|etc]'
|
||||
secondary_domains: '[additional perspectives needed]'
|
||||
specific_expertise: '[particular skills required]'
|
||||
research_depth: '[overview|detailed|comprehensive]'
|
||||
|
||||
team_config:
|
||||
researcher_count: "[1-3, default 3]"
|
||||
perspective_1: "[domain and focus area]"
|
||||
perspective_2: "[domain and focus area]"
|
||||
perspective_3: "[domain and focus area]"
|
||||
researcher_count: '[1-3, default 3]'
|
||||
perspective_1: '[domain and focus area]'
|
||||
perspective_2: '[domain and focus area]'
|
||||
perspective_3: '[domain and focus area]'
|
||||
|
||||
output:
|
||||
format: "[executive_summary|detailed_report|comparison_matrix|etc]"
|
||||
audience: "[who will use results]"
|
||||
integration: "[how results feed into workflow]"
|
||||
citation_level: "[minimal|standard|comprehensive]"
|
||||
format: '[executive_summary|detailed_report|comparison_matrix|etc]'
|
||||
audience: '[who will use results]'
|
||||
integration: '[how results feed into workflow]'
|
||||
citation_level: '[minimal|standard|comprehensive]'
|
||||
```
|
||||
|
||||
## Integration with Existing Agents
|
||||
|
|
@ -1153,26 +1160,32 @@ commands:
|
|||
## Research Log Structure
|
||||
|
||||
### Research Index (`docs/research/research-index.md`)
|
||||
|
||||
```markdown
|
||||
# Research Index
|
||||
|
||||
## Recent Research
|
||||
|
||||
- [2024-01-15: AI Model Comparison](2024-01-15-ai-model-comparison.md) - Technical analysis of LLM options
|
||||
- [2024-01-12: Payment Gateway Analysis](2024-01-12-payment-gateway-analysis.md) - Market comparison of payment solutions
|
||||
|
||||
## Research by Category
|
||||
|
||||
### Technical Research
|
||||
|
||||
- AI/ML Models
|
||||
- Architecture Decisions
|
||||
- Technology Stacks
|
||||
|
||||
### Market Research
|
||||
|
||||
- Competitive Analysis
|
||||
- User Behavior
|
||||
- Industry Trends
|
||||
```
|
||||
|
||||
### Individual Research Files (`docs/research/YYYY-MM-DD-topic.md`)
|
||||
|
||||
```markdown
|
||||
# Research: [Topic]
|
||||
|
||||
|
|
@ -1181,31 +1194,41 @@ commands:
|
|||
**Research Team**: [perspectives used]
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[Key findings and recommendations]
|
||||
|
||||
## Research Objective
|
||||
|
||||
[What was being researched and why]
|
||||
|
||||
## Key Findings
|
||||
|
||||
[Main insights from all perspectives]
|
||||
|
||||
## Recommendations
|
||||
|
||||
[Actionable next steps]
|
||||
|
||||
## Research Team Perspectives
|
||||
|
||||
### Perspective 1: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 2: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 3: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
## Sources and References
|
||||
|
||||
[Credible sources cited by research team]
|
||||
|
||||
## Tags
|
||||
|
||||
[Searchable tags for future reference]
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -127,19 +127,23 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 1. Research Request Intake
|
||||
|
||||
#### Process Incoming Request
|
||||
|
||||
**If called via unified request-research task:**
|
||||
|
||||
- Extract research request YAML structure
|
||||
- Validate all required fields are present
|
||||
- Understand requesting agent context and needs
|
||||
- Assess urgency and timeline constraints
|
||||
|
||||
**If called directly by user/agent:**
|
||||
|
||||
- Elicit research requirements using structured approach
|
||||
- Guide user through research request specification
|
||||
- Ensure clarity on objectives and expected outcomes
|
||||
- Document request in standard format
|
||||
|
||||
#### Critical Elements to Capture
|
||||
|
||||
- **Requesting Agent**: Which agent needs the research
|
||||
- **Research Objective**: Specific question or problem
|
||||
- **Context**: Project phase, background, constraints
|
||||
|
|
@ -151,6 +155,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 2. Research Log Analysis
|
||||
|
||||
#### Check for Existing Research
|
||||
|
||||
1. **Search Research Index**: Look for related prior research
|
||||
- Search by topic keywords
|
||||
- Check domain tags and categories
|
||||
|
|
@ -172,6 +177,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 3. Research Strategy Design
|
||||
|
||||
#### Multi-Perspective Planning
|
||||
|
||||
1. **Determine Research Team Size**
|
||||
- Default: 3 researchers for comprehensive coverage
|
||||
- Configurable based on complexity and timeline
|
||||
|
|
@ -184,6 +190,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
- **Maximize Coverage**: Balance breadth vs depth
|
||||
|
||||
#### Common Research Team Configurations
|
||||
|
||||
- **Technology Assessment**: Technical + Scalability + Security
|
||||
- **Market Analysis**: Market + Competitive + User
|
||||
- **Product Decision**: Technical + Business + User
|
||||
|
|
@ -193,6 +200,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 4. Researcher Deployment
|
||||
|
||||
#### Configure Research Teams
|
||||
|
||||
For each researcher agent:
|
||||
|
||||
1. **Specialization Configuration**
|
||||
|
|
@ -214,28 +222,31 @@ For each researcher agent:
|
|||
- Quality standards and source requirements
|
||||
|
||||
#### Research Assignment Template
|
||||
|
||||
```yaml
|
||||
researcher_briefing:
|
||||
research_context: "[Context from original request]"
|
||||
assigned_domain: "[Primary specialization]"
|
||||
perspective_focus: "[Specific angle to investigate]"
|
||||
research_questions: "[Domain-specific questions to address]"
|
||||
source_priorities: "[Types of sources to prioritize]"
|
||||
analysis_framework: "[How to analyze information]"
|
||||
coordination_role: "[How this fits with other researchers]"
|
||||
deliverable_format: "[Expected output structure]"
|
||||
timeline: "[Deadlines and checkpoints]"
|
||||
research_context: '[Context from original request]'
|
||||
assigned_domain: '[Primary specialization]'
|
||||
perspective_focus: '[Specific angle to investigate]'
|
||||
research_questions: '[Domain-specific questions to address]'
|
||||
source_priorities: '[Types of sources to prioritize]'
|
||||
analysis_framework: '[How to analyze information]'
|
||||
coordination_role: '[How this fits with other researchers]'
|
||||
deliverable_format: '[Expected output structure]'
|
||||
timeline: '[Deadlines and checkpoints]'
|
||||
```
|
||||
|
||||
### 5. Research Coordination
|
||||
|
||||
#### Monitor Research Progress
|
||||
|
||||
- **Progress Checkpoints**: Regular status updates from researchers
|
||||
- **Quality Review**: Interim assessment of findings quality
|
||||
- **Coordination Adjustments**: Modify approach based on early findings
|
||||
- **Conflict Resolution**: Address disagreements between researchers
|
||||
|
||||
#### Handle Research Challenges
|
||||
|
||||
- **Information Gaps**: Redirect research focus if sources unavailable
|
||||
- **Conflicting Findings**: Document disagreements for synthesis
|
||||
- **Scope Creep**: Keep research focused on original objectives
|
||||
|
|
@ -244,6 +255,7 @@ researcher_briefing:
|
|||
### 6. Findings Synthesis
|
||||
|
||||
#### Synthesis Process
|
||||
|
||||
1. **Gather Individual Reports**
|
||||
- Collect findings from each researcher
|
||||
- Review quality and completeness
|
||||
|
|
@ -263,6 +275,7 @@ researcher_briefing:
|
|||
- Identify areas needing additional research
|
||||
|
||||
#### Synthesis Output Structure
|
||||
|
||||
Using research-synthesis-tmpl.yaml:
|
||||
|
||||
1. **Executive Summary**: Key insights and recommendations
|
||||
|
|
@ -276,12 +289,14 @@ Using research-synthesis-tmpl.yaml:
|
|||
### 7. Delivery and Documentation
|
||||
|
||||
#### Deliver to Requesting Agent
|
||||
|
||||
1. **Primary Deliverable**: Synthesized research report
|
||||
2. **Executive Summary**: Key findings and recommendations
|
||||
3. **Supporting Detail**: Access to full analysis as needed
|
||||
4. **Next Steps**: Recommended actions and follow-up research
|
||||
|
||||
#### Update Research Index
|
||||
|
||||
Using research-log-entry-tmpl.yaml:
|
||||
|
||||
1. **Add Index Entry**: New research to chronological list
|
||||
|
|
@ -290,6 +305,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
4. **Cross-References**: Link to related prior research
|
||||
|
||||
#### Store Research Artifacts
|
||||
|
||||
- **Primary Report**: Store in docs/research/ with date-topic filename
|
||||
- **Research Index**: Update research-index.md with new entry
|
||||
- **Source Documentation**: Preserve links and references
|
||||
|
|
@ -298,6 +314,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 8. Quality Assurance
|
||||
|
||||
#### Research Quality Checklist
|
||||
|
||||
- **Objective Completion**: All research questions addressed
|
||||
- **Source Credibility**: Reliable, recent, and relevant sources
|
||||
- **Perspective Diversity**: Genuinely different analytical angles
|
||||
|
|
@ -307,6 +324,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
- **Uncertainty Documentation**: Limitations and gaps clearly stated
|
||||
|
||||
#### Validation Steps
|
||||
|
||||
1. **Internal Review**: Coordinator validates synthesis quality
|
||||
2. **Source Verification**: Spot-check key sources and evidence
|
||||
3. **Logic Check**: Ensure recommendations follow from findings
|
||||
|
|
@ -315,12 +333,14 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 9. Error Handling and Edge Cases
|
||||
|
||||
#### Common Challenges
|
||||
|
||||
- **Researcher Unavailability**: Adjust team size or perspective assignments
|
||||
- **Source Access Issues**: Graceful degradation to available information
|
||||
- **Conflicting Deadlines**: Prioritize critical research elements
|
||||
- **Quality Problems**: Reassign research or adjust scope
|
||||
|
||||
#### Escalation Triggers
|
||||
|
||||
- **Irreconcilable Conflicts**: Major disagreements between researchers
|
||||
- **Missing Critical Information**: Gaps that prevent objective completion
|
||||
- **Quality Failures**: Repeated issues with source credibility or analysis
|
||||
|
|
@ -329,12 +349,14 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 10. Continuous Improvement
|
||||
|
||||
#### Research Process Optimization
|
||||
|
||||
- **Track Research Effectiveness**: Monitor how research informs decisions
|
||||
- **Identify Common Patterns**: Frequently requested research types
|
||||
- **Optimize Team Configurations**: Most effective perspective combinations
|
||||
- **Improve Synthesis Quality**: Better integration techniques
|
||||
|
||||
#### Knowledge Base Enhancement
|
||||
|
||||
- **Update Domain Profiles**: Refine specialization descriptions
|
||||
- **Expand Source Directories**: Add new credible source types
|
||||
- **Improve Methodologies**: Better research and analysis frameworks
|
||||
|
|
@ -363,6 +385,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
### 1. Search Strategy
|
||||
|
||||
#### Check Research Index
|
||||
|
||||
1. **Load Research Index**: Read `docs/research/research-index.md`
|
||||
2. **Keyword Search**: Search for related terms in:
|
||||
- Research titles and descriptions
|
||||
|
|
@ -371,6 +394,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
- Requesting agent information
|
||||
|
||||
#### Search Parameters
|
||||
|
||||
- **Topic Keywords**: Core subject terms from research request
|
||||
- **Domain Tags**: Technical, market, user, competitive, etc.
|
||||
- **Date Range**: Recent research vs historical
|
||||
|
|
@ -379,6 +403,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
### 2. Analysis Process
|
||||
|
||||
#### Evaluate Matches
|
||||
|
||||
For each potential match:
|
||||
|
||||
1. **Relevance Assessment**
|
||||
|
|
@ -399,21 +424,25 @@ For each potential match:
|
|||
### 3. Output Options
|
||||
|
||||
#### Full Coverage Exists
|
||||
|
||||
- **Recommendation**: Refer to existing research
|
||||
- **Action**: Provide link and summary of relevant findings
|
||||
- **Update Strategy**: Consider if refresh needed due to age
|
||||
|
||||
#### Partial Coverage Available
|
||||
|
||||
- **Recommendation**: Build on existing research
|
||||
- **Action**: Identify specific gaps to focus new research
|
||||
- **Integration Strategy**: How to combine old and new findings
|
||||
|
||||
#### No Relevant Coverage
|
||||
|
||||
- **Recommendation**: Proceed with full research effort
|
||||
- **Action**: Document search results to avoid future confusion
|
||||
- **Baseline**: Use existing research as context background
|
||||
|
||||
#### Outdated Coverage
|
||||
|
||||
- **Recommendation**: Update/refresh existing research
|
||||
- **Action**: Compare current request to prior research scope
|
||||
- **Strategy**: Full refresh vs targeted updates
|
||||
|
|
@ -421,6 +450,7 @@ For each potential match:
|
|||
### 4. Documentation
|
||||
|
||||
#### Search Results Summary
|
||||
|
||||
```markdown
|
||||
## Research Log Search Results
|
||||
|
||||
|
|
@ -429,6 +459,7 @@ For each potential match:
|
|||
**Matches Found**: [number of potential matches]
|
||||
|
||||
### Relevant Prior Research
|
||||
|
||||
1. **[Research Title]** (Date: YYYY-MM-DD)
|
||||
- **Relevance**: [how closely it matches]
|
||||
- **Coverage**: [what aspects are covered]
|
||||
|
|
@ -437,6 +468,7 @@ For each potential match:
|
|||
- **Recommendation**: [use as-is/build-on/refresh/ignore]
|
||||
|
||||
### Search Conclusion
|
||||
|
||||
- **Overall Assessment**: [full/partial/no/outdated coverage]
|
||||
- **Recommended Action**: [refer/build-on/proceed/refresh]
|
||||
- **Integration Strategy**: [how to use prior work]
|
||||
|
|
@ -445,12 +477,14 @@ For each potential match:
|
|||
### 5. Integration Recommendations
|
||||
|
||||
#### Building on Prior Research
|
||||
|
||||
- **Reference Strategy**: How to cite and build upon existing work
|
||||
- **Gap Focus**: Specific areas to concentrate new research efforts
|
||||
- **Perspective Additions**: New angles not covered in prior research
|
||||
- **Update Requirements**: Refresh outdated information
|
||||
|
||||
#### Avoiding Duplication
|
||||
|
||||
- **Scope Differentiation**: How current request differs from prior work
|
||||
- **Methodology Variation**: Different research approaches to try
|
||||
- **Source Expansion**: New information sources to explore
|
||||
|
|
@ -753,6 +787,7 @@ sections:
|
|||
## Pre-Research Planning
|
||||
|
||||
### Research Objective Clarity
|
||||
|
||||
- [ ] Research objective is specific and measurable
|
||||
- [ ] Success criteria are clearly defined
|
||||
- [ ] Scope boundaries are explicitly stated
|
||||
|
|
@ -760,6 +795,7 @@ sections:
|
|||
- [ ] Timeline and priority constraints are documented
|
||||
|
||||
### Research Strategy Design
|
||||
|
||||
- [ ] Multi-perspective approach is appropriate for complexity
|
||||
- [ ] Domain specializations are properly assigned
|
||||
- [ ] Research team size matches scope and timeline
|
||||
|
|
@ -767,6 +803,7 @@ sections:
|
|||
- [ ] Research methodologies are appropriate for objectives
|
||||
|
||||
### Prior Research Review
|
||||
|
||||
- [ ] Research log has been searched for related work
|
||||
- [ ] Prior research relevance has been assessed
|
||||
- [ ] Strategy for building on existing work is defined
|
||||
|
|
@ -775,6 +812,7 @@ sections:
|
|||
## During Research Execution
|
||||
|
||||
### Source Quality and Credibility
|
||||
|
||||
- [ ] Sources are credible and authoritative
|
||||
- [ ] Information recency is appropriate for topic
|
||||
- [ ] Source diversity provides multiple viewpoints
|
||||
|
|
@ -782,6 +820,7 @@ sections:
|
|||
- [ ] Primary sources are prioritized over secondary when available
|
||||
|
||||
### Research Methodology
|
||||
|
||||
- [ ] Research approach is systematic and thorough
|
||||
- [ ] Domain expertise lens is consistently applied
|
||||
- [ ] Web search capabilities are effectively utilized
|
||||
|
|
@ -789,6 +828,7 @@ sections:
|
|||
- [ ] Analysis frameworks are appropriate for domain
|
||||
|
||||
### Quality Assurance
|
||||
|
||||
- [ ] Key findings are supported by multiple sources
|
||||
- [ ] Conflicting information is properly documented
|
||||
- [ ] Uncertainty levels are clearly identified
|
||||
|
|
@ -798,6 +838,7 @@ sections:
|
|||
## Synthesis and Integration
|
||||
|
||||
### Multi-Perspective Synthesis
|
||||
|
||||
- [ ] Findings from all researchers are properly integrated
|
||||
- [ ] Convergent insights are clearly identified
|
||||
- [ ] Divergent viewpoints are fairly represented
|
||||
|
|
@ -805,6 +846,7 @@ sections:
|
|||
- [ ] Gaps requiring additional research are documented
|
||||
|
||||
### Analysis Quality
|
||||
|
||||
- [ ] Key findings directly address research objectives
|
||||
- [ ] Evidence supports conclusions and recommendations
|
||||
- [ ] Limitations and uncertainties are transparently documented
|
||||
|
|
@ -812,6 +854,7 @@ sections:
|
|||
- [ ] Recommendations are actionable and specific
|
||||
|
||||
### Documentation Standards
|
||||
|
||||
- [ ] Executive summary captures key insights effectively
|
||||
- [ ] Detailed analysis is well-organized and comprehensive
|
||||
- [ ] Source documentation enables verification
|
||||
|
|
@ -821,6 +864,7 @@ sections:
|
|||
## Final Deliverable Review
|
||||
|
||||
### Completeness
|
||||
|
||||
- [ ] All research questions have been addressed
|
||||
- [ ] Success criteria have been met
|
||||
- [ ] Output format matches requestor requirements
|
||||
|
|
@ -828,6 +872,7 @@ sections:
|
|||
- [ ] Next steps and follow-up needs are identified
|
||||
|
||||
### Decision Support Quality
|
||||
|
||||
- [ ] Findings directly inform decision-making needs
|
||||
- [ ] Confidence levels help assess decision risk
|
||||
- [ ] Recommendations are prioritized and actionable
|
||||
|
|
@ -835,6 +880,7 @@ sections:
|
|||
- [ ] Risk factors and mitigation strategies are provided
|
||||
|
||||
### Integration and Handoff
|
||||
|
||||
- [ ] Results are properly formatted for requesting agent
|
||||
- [ ] Research log has been updated with new entry
|
||||
- [ ] Index categorization is accurate and searchable
|
||||
|
|
@ -844,6 +890,7 @@ sections:
|
|||
## Post-Research Evaluation
|
||||
|
||||
### Research Effectiveness
|
||||
|
||||
- [ ] Research objectives were successfully achieved
|
||||
- [ ] Timeline and resource constraints were managed effectively
|
||||
- [ ] Quality standards were maintained throughout process
|
||||
|
|
@ -851,6 +898,7 @@ sections:
|
|||
- [ ] Lessons learned are documented for process improvement
|
||||
|
||||
### Knowledge Management
|
||||
|
||||
- [ ] Research artifacts are properly stored and indexed
|
||||
- [ ] Key insights are preserved for future reference
|
||||
- [ ] Research methodology insights can inform future efforts
|
||||
|
|
@ -860,6 +908,7 @@ sections:
|
|||
## Quality Escalation Triggers
|
||||
|
||||
### Immediate Review Required
|
||||
|
||||
- [ ] Major conflicts between research perspectives cannot be reconciled
|
||||
- [ ] Key sources are found to be unreliable or biased
|
||||
- [ ] Research scope significantly exceeds original boundaries
|
||||
|
|
@ -867,6 +916,7 @@ sections:
|
|||
- [ ] Timeline constraints threaten quality standards
|
||||
|
||||
### Process Improvement Needed
|
||||
|
||||
- [ ] Repeated issues with source credibility or access
|
||||
- [ ] Frequent scope creep or objective changes
|
||||
- [ ] Consistent challenges with perspective coordination
|
||||
|
|
@ -876,6 +926,7 @@ sections:
|
|||
## Continuous Improvement
|
||||
|
||||
### Research Process Enhancement
|
||||
|
||||
- [ ] Track research effectiveness and decision impact
|
||||
- [ ] Identify patterns in research requests and optimize approaches
|
||||
- [ ] Refine domain specialization profiles based on experience
|
||||
|
|
@ -883,6 +934,7 @@ sections:
|
|||
- [ ] Enhance coordination methods between research perspectives
|
||||
|
||||
### Knowledge Base Development
|
||||
|
||||
- [ ] Update research methodologies based on lessons learned
|
||||
- [ ] Expand credible source directories with new discoveries
|
||||
- [ ] Improve domain expertise profiles with refined specializations
|
||||
|
|
@ -900,6 +952,7 @@ sections:
|
|||
### Technical Research Methodologies
|
||||
|
||||
#### Technology Assessment Framework
|
||||
|
||||
- **Capability Analysis**: Feature sets, performance characteristics, scalability limits
|
||||
- **Implementation Evaluation**: Complexity, learning curve, integration requirements
|
||||
- **Ecosystem Assessment**: Community support, documentation quality, maintenance status
|
||||
|
|
@ -907,6 +960,7 @@ sections:
|
|||
- **Security Analysis**: Vulnerability assessment, security model evaluation
|
||||
|
||||
#### Technical Source Priorities
|
||||
|
||||
1. **Official Documentation**: Primary source for capabilities and limitations
|
||||
2. **GitHub Repositories**: Code quality, activity level, issue resolution patterns
|
||||
3. **Technical Blogs**: Implementation experiences, best practices, lessons learned
|
||||
|
|
@ -916,6 +970,7 @@ sections:
|
|||
### Market Research Methodologies
|
||||
|
||||
#### Market Analysis Framework
|
||||
|
||||
- **Market Sizing**: TAM/SAM/SOM analysis, growth rate assessment
|
||||
- **Competitive Landscape**: Player mapping, market share analysis, positioning
|
||||
- **Customer Segmentation**: Demographics, psychographics, behavioral patterns
|
||||
|
|
@ -923,6 +978,7 @@ sections:
|
|||
- **Opportunity Assessment**: Market gaps, underserved segments, entry barriers
|
||||
|
||||
#### Market Source Priorities
|
||||
|
||||
1. **Industry Reports**: Analyst research, market studies, trend analyses
|
||||
2. **Financial Data**: Public company reports, funding announcements, valuations
|
||||
3. **Survey Data**: Customer research, market studies, adoption surveys
|
||||
|
|
@ -932,6 +988,7 @@ sections:
|
|||
### User Research Methodologies
|
||||
|
||||
#### User-Centered Research Framework
|
||||
|
||||
- **Behavioral Analysis**: User journey mapping, interaction patterns, pain points
|
||||
- **Needs Assessment**: Jobs-to-be-done analysis, unmet needs identification
|
||||
- **Experience Evaluation**: Usability assessment, satisfaction measurement
|
||||
|
|
@ -939,6 +996,7 @@ sections:
|
|||
- **Context Analysis**: Use case scenarios, environmental factors, constraints
|
||||
|
||||
#### User Research Source Priorities
|
||||
|
||||
1. **User Studies**: Direct research, surveys, interviews, focus groups
|
||||
2. **Product Reviews**: Customer feedback, ratings, detailed experiences
|
||||
3. **Social Media**: User discussions, complaints, feature requests
|
||||
|
|
@ -948,6 +1006,7 @@ sections:
|
|||
### Competitive Research Methodologies
|
||||
|
||||
#### Competitive Intelligence Framework
|
||||
|
||||
- **Feature Comparison**: Capability matrices, feature gap analysis
|
||||
- **Strategic Analysis**: Business model evaluation, positioning assessment
|
||||
- **Performance Benchmarking**: Speed, reliability, user experience comparisons
|
||||
|
|
@ -955,6 +1014,7 @@ sections:
|
|||
- **Innovation Tracking**: Product roadmaps, patent filings, investment areas
|
||||
|
||||
#### Competitive Source Priorities
|
||||
|
||||
1. **Competitor Websites**: Product information, pricing, positioning messages
|
||||
2. **Product Demos**: Hands-on evaluation, feature testing, user experience
|
||||
3. **Press Releases**: Strategic announcements, product launches, partnerships
|
||||
|
|
@ -964,6 +1024,7 @@ sections:
|
|||
### Scientific Research Methodologies
|
||||
|
||||
#### Scientific Analysis Framework
|
||||
|
||||
- **Literature Review**: Peer-reviewed research, citation analysis, consensus building
|
||||
- **Methodology Assessment**: Research design quality, statistical validity, reproducibility
|
||||
- **Evidence Evaluation**: Study quality, sample sizes, control factors
|
||||
|
|
@ -971,6 +1032,7 @@ sections:
|
|||
- **Application Assessment**: Practical implications, implementation feasibility
|
||||
|
||||
#### Scientific Source Priorities
|
||||
|
||||
1. **Peer-Reviewed Journals**: Primary research, systematic reviews, meta-analyses
|
||||
2. **Academic Databases**: Research repositories, citation networks, preprints
|
||||
3. **Conference Proceedings**: Latest research, emerging trends, expert presentations
|
||||
|
|
@ -982,6 +1044,7 @@ sections:
|
|||
### Source Credibility Assessment
|
||||
|
||||
#### Primary Source Evaluation
|
||||
|
||||
- **Authority**: Expertise of authors, institutional affiliation, credentials
|
||||
- **Accuracy**: Fact-checking, peer review process, error correction mechanisms
|
||||
- **Objectivity**: Bias assessment, funding sources, conflict of interest disclosure
|
||||
|
|
@ -989,6 +1052,7 @@ sections:
|
|||
- **Coverage**: Scope comprehensiveness, detail level, methodology transparency
|
||||
|
||||
#### Secondary Source Validation
|
||||
|
||||
- **Citation Quality**: Primary source references, citation accuracy, source diversity
|
||||
- **Synthesis Quality**: Analysis depth, logical coherence, balanced perspective
|
||||
- **Author Expertise**: Subject matter knowledge, track record, reputation
|
||||
|
|
@ -998,6 +1062,7 @@ sections:
|
|||
### Information Synthesis Approaches
|
||||
|
||||
#### Multi-Perspective Integration
|
||||
|
||||
- **Convergence Analysis**: Identify areas where sources agree consistently
|
||||
- **Divergence Documentation**: Note significant disagreements and analyze causes
|
||||
- **Confidence Weighting**: Assign confidence levels based on source quality and consensus
|
||||
|
|
@ -1005,6 +1070,7 @@ sections:
|
|||
- **Uncertainty Quantification**: Document limitations and areas of unclear evidence
|
||||
|
||||
#### Evidence Hierarchy
|
||||
|
||||
1. **High Confidence**: Multiple credible sources, recent information, expert consensus
|
||||
2. **Medium Confidence**: Some credible sources, mixed consensus, moderate currency
|
||||
3. **Low Confidence**: Limited sources, significant disagreement, dated information
|
||||
|
|
@ -1014,6 +1080,7 @@ sections:
|
|||
## Domain-Specific Analysis Frameworks
|
||||
|
||||
### Technical Analysis Framework
|
||||
|
||||
- **Feasibility Assessment**: Technical viability, implementation complexity, resource requirements
|
||||
- **Scalability Analysis**: Performance under load, growth accommodation, architectural limits
|
||||
- **Integration Evaluation**: Compatibility assessment, integration complexity, ecosystem fit
|
||||
|
|
@ -1021,6 +1088,7 @@ sections:
|
|||
- **Risk Assessment**: Technical risks, dependency risks, obsolescence potential
|
||||
|
||||
### Business Analysis Framework
|
||||
|
||||
- **Value Proposition**: Customer value delivery, competitive advantage, market differentiation
|
||||
- **Financial Impact**: Cost analysis, revenue potential, ROI assessment, budget implications
|
||||
- **Strategic Alignment**: Goal consistency, priority alignment, resource allocation fit
|
||||
|
|
@ -1028,6 +1096,7 @@ sections:
|
|||
- **Risk-Benefit Analysis**: Potential rewards vs implementation risks and costs
|
||||
|
||||
### User Impact Framework
|
||||
|
||||
- **User Experience**: Ease of use, learning curve, satisfaction factors, accessibility
|
||||
- **Adoption Factors**: Barriers to adoption, motivation drivers, change management needs
|
||||
- **Value Delivery**: User benefit realization, problem solving effectiveness, outcome achievement
|
||||
|
|
@ -1037,6 +1106,7 @@ sections:
|
|||
## Research Coordination Best Practices
|
||||
|
||||
### Multi-Researcher Coordination
|
||||
|
||||
- **Perspective Assignment**: Clear domain boundaries, minimal overlap, comprehensive coverage
|
||||
- **Communication Protocols**: Regular check-ins, conflict resolution processes, coordination methods
|
||||
- **Quality Standards**: Consistent source credibility requirements, analysis depth expectations
|
||||
|
|
@ -1044,6 +1114,7 @@ sections:
|
|||
- **Integration Planning**: Synthesis approach design, conflict resolution strategies, gap handling
|
||||
|
||||
### Research Efficiency Optimization
|
||||
|
||||
- **Source Sharing**: Avoid duplicate source evaluation across researchers
|
||||
- **Finding Coordination**: Share relevant discoveries between perspectives
|
||||
- **Quality Checks**: Cross-validation of key findings, source verification collaboration
|
||||
|
|
|
|||
|
|
@ -160,6 +160,7 @@ dependencies:
|
|||
## Pre-Research Planning
|
||||
|
||||
### Research Objective Clarity
|
||||
|
||||
- [ ] Research objective is specific and measurable
|
||||
- [ ] Success criteria are clearly defined
|
||||
- [ ] Scope boundaries are explicitly stated
|
||||
|
|
@ -167,6 +168,7 @@ dependencies:
|
|||
- [ ] Timeline and priority constraints are documented
|
||||
|
||||
### Research Strategy Design
|
||||
|
||||
- [ ] Multi-perspective approach is appropriate for complexity
|
||||
- [ ] Domain specializations are properly assigned
|
||||
- [ ] Research team size matches scope and timeline
|
||||
|
|
@ -174,6 +176,7 @@ dependencies:
|
|||
- [ ] Research methodologies are appropriate for objectives
|
||||
|
||||
### Prior Research Review
|
||||
|
||||
- [ ] Research log has been searched for related work
|
||||
- [ ] Prior research relevance has been assessed
|
||||
- [ ] Strategy for building on existing work is defined
|
||||
|
|
@ -182,6 +185,7 @@ dependencies:
|
|||
## During Research Execution
|
||||
|
||||
### Source Quality and Credibility
|
||||
|
||||
- [ ] Sources are credible and authoritative
|
||||
- [ ] Information recency is appropriate for topic
|
||||
- [ ] Source diversity provides multiple viewpoints
|
||||
|
|
@ -189,6 +193,7 @@ dependencies:
|
|||
- [ ] Primary sources are prioritized over secondary when available
|
||||
|
||||
### Research Methodology
|
||||
|
||||
- [ ] Research approach is systematic and thorough
|
||||
- [ ] Domain expertise lens is consistently applied
|
||||
- [ ] Web search capabilities are effectively utilized
|
||||
|
|
@ -196,6 +201,7 @@ dependencies:
|
|||
- [ ] Analysis frameworks are appropriate for domain
|
||||
|
||||
### Quality Assurance
|
||||
|
||||
- [ ] Key findings are supported by multiple sources
|
||||
- [ ] Conflicting information is properly documented
|
||||
- [ ] Uncertainty levels are clearly identified
|
||||
|
|
@ -205,6 +211,7 @@ dependencies:
|
|||
## Synthesis and Integration
|
||||
|
||||
### Multi-Perspective Synthesis
|
||||
|
||||
- [ ] Findings from all researchers are properly integrated
|
||||
- [ ] Convergent insights are clearly identified
|
||||
- [ ] Divergent viewpoints are fairly represented
|
||||
|
|
@ -212,6 +219,7 @@ dependencies:
|
|||
- [ ] Gaps requiring additional research are documented
|
||||
|
||||
### Analysis Quality
|
||||
|
||||
- [ ] Key findings directly address research objectives
|
||||
- [ ] Evidence supports conclusions and recommendations
|
||||
- [ ] Limitations and uncertainties are transparently documented
|
||||
|
|
@ -219,6 +227,7 @@ dependencies:
|
|||
- [ ] Recommendations are actionable and specific
|
||||
|
||||
### Documentation Standards
|
||||
|
||||
- [ ] Executive summary captures key insights effectively
|
||||
- [ ] Detailed analysis is well-organized and comprehensive
|
||||
- [ ] Source documentation enables verification
|
||||
|
|
@ -228,6 +237,7 @@ dependencies:
|
|||
## Final Deliverable Review
|
||||
|
||||
### Completeness
|
||||
|
||||
- [ ] All research questions have been addressed
|
||||
- [ ] Success criteria have been met
|
||||
- [ ] Output format matches requestor requirements
|
||||
|
|
@ -235,6 +245,7 @@ dependencies:
|
|||
- [ ] Next steps and follow-up needs are identified
|
||||
|
||||
### Decision Support Quality
|
||||
|
||||
- [ ] Findings directly inform decision-making needs
|
||||
- [ ] Confidence levels help assess decision risk
|
||||
- [ ] Recommendations are prioritized and actionable
|
||||
|
|
@ -242,6 +253,7 @@ dependencies:
|
|||
- [ ] Risk factors and mitigation strategies are provided
|
||||
|
||||
### Integration and Handoff
|
||||
|
||||
- [ ] Results are properly formatted for requesting agent
|
||||
- [ ] Research log has been updated with new entry
|
||||
- [ ] Index categorization is accurate and searchable
|
||||
|
|
@ -251,6 +263,7 @@ dependencies:
|
|||
## Post-Research Evaluation
|
||||
|
||||
### Research Effectiveness
|
||||
|
||||
- [ ] Research objectives were successfully achieved
|
||||
- [ ] Timeline and resource constraints were managed effectively
|
||||
- [ ] Quality standards were maintained throughout process
|
||||
|
|
@ -258,6 +271,7 @@ dependencies:
|
|||
- [ ] Lessons learned are documented for process improvement
|
||||
|
||||
### Knowledge Management
|
||||
|
||||
- [ ] Research artifacts are properly stored and indexed
|
||||
- [ ] Key insights are preserved for future reference
|
||||
- [ ] Research methodology insights can inform future efforts
|
||||
|
|
@ -267,6 +281,7 @@ dependencies:
|
|||
## Quality Escalation Triggers
|
||||
|
||||
### Immediate Review Required
|
||||
|
||||
- [ ] Major conflicts between research perspectives cannot be reconciled
|
||||
- [ ] Key sources are found to be unreliable or biased
|
||||
- [ ] Research scope significantly exceeds original boundaries
|
||||
|
|
@ -274,6 +289,7 @@ dependencies:
|
|||
- [ ] Timeline constraints threaten quality standards
|
||||
|
||||
### Process Improvement Needed
|
||||
|
||||
- [ ] Repeated issues with source credibility or access
|
||||
- [ ] Frequent scope creep or objective changes
|
||||
- [ ] Consistent challenges with perspective coordination
|
||||
|
|
@ -283,6 +299,7 @@ dependencies:
|
|||
## Continuous Improvement
|
||||
|
||||
### Research Process Enhancement
|
||||
|
||||
- [ ] Track research effectiveness and decision impact
|
||||
- [ ] Identify patterns in research requests and optimize approaches
|
||||
- [ ] Refine domain specialization profiles based on experience
|
||||
|
|
@ -290,6 +307,7 @@ dependencies:
|
|||
- [ ] Enhance coordination methods between research perspectives
|
||||
|
||||
### Knowledge Base Development
|
||||
|
||||
- [ ] Update research methodologies based on lessons learned
|
||||
- [ ] Expand credible source directories with new discoveries
|
||||
- [ ] Improve domain expertise profiles with refined specializations
|
||||
|
|
@ -307,6 +325,7 @@ dependencies:
|
|||
### Technical Research Methodologies
|
||||
|
||||
#### Technology Assessment Framework
|
||||
|
||||
- **Capability Analysis**: Feature sets, performance characteristics, scalability limits
|
||||
- **Implementation Evaluation**: Complexity, learning curve, integration requirements
|
||||
- **Ecosystem Assessment**: Community support, documentation quality, maintenance status
|
||||
|
|
@ -314,6 +333,7 @@ dependencies:
|
|||
- **Security Analysis**: Vulnerability assessment, security model evaluation
|
||||
|
||||
#### Technical Source Priorities
|
||||
|
||||
1. **Official Documentation**: Primary source for capabilities and limitations
|
||||
2. **GitHub Repositories**: Code quality, activity level, issue resolution patterns
|
||||
3. **Technical Blogs**: Implementation experiences, best practices, lessons learned
|
||||
|
|
@ -323,6 +343,7 @@ dependencies:
|
|||
### Market Research Methodologies
|
||||
|
||||
#### Market Analysis Framework
|
||||
|
||||
- **Market Sizing**: TAM/SAM/SOM analysis, growth rate assessment
|
||||
- **Competitive Landscape**: Player mapping, market share analysis, positioning
|
||||
- **Customer Segmentation**: Demographics, psychographics, behavioral patterns
|
||||
|
|
@ -330,6 +351,7 @@ dependencies:
|
|||
- **Opportunity Assessment**: Market gaps, underserved segments, entry barriers
|
||||
|
||||
#### Market Source Priorities
|
||||
|
||||
1. **Industry Reports**: Analyst research, market studies, trend analyses
|
||||
2. **Financial Data**: Public company reports, funding announcements, valuations
|
||||
3. **Survey Data**: Customer research, market studies, adoption surveys
|
||||
|
|
@ -339,6 +361,7 @@ dependencies:
|
|||
### User Research Methodologies
|
||||
|
||||
#### User-Centered Research Framework
|
||||
|
||||
- **Behavioral Analysis**: User journey mapping, interaction patterns, pain points
|
||||
- **Needs Assessment**: Jobs-to-be-done analysis, unmet needs identification
|
||||
- **Experience Evaluation**: Usability assessment, satisfaction measurement
|
||||
|
|
@ -346,6 +369,7 @@ dependencies:
|
|||
- **Context Analysis**: Use case scenarios, environmental factors, constraints
|
||||
|
||||
#### User Research Source Priorities
|
||||
|
||||
1. **User Studies**: Direct research, surveys, interviews, focus groups
|
||||
2. **Product Reviews**: Customer feedback, ratings, detailed experiences
|
||||
3. **Social Media**: User discussions, complaints, feature requests
|
||||
|
|
@ -355,6 +379,7 @@ dependencies:
|
|||
### Competitive Research Methodologies
|
||||
|
||||
#### Competitive Intelligence Framework
|
||||
|
||||
- **Feature Comparison**: Capability matrices, feature gap analysis
|
||||
- **Strategic Analysis**: Business model evaluation, positioning assessment
|
||||
- **Performance Benchmarking**: Speed, reliability, user experience comparisons
|
||||
|
|
@ -362,6 +387,7 @@ dependencies:
|
|||
- **Innovation Tracking**: Product roadmaps, patent filings, investment areas
|
||||
|
||||
#### Competitive Source Priorities
|
||||
|
||||
1. **Competitor Websites**: Product information, pricing, positioning messages
|
||||
2. **Product Demos**: Hands-on evaluation, feature testing, user experience
|
||||
3. **Press Releases**: Strategic announcements, product launches, partnerships
|
||||
|
|
@ -371,6 +397,7 @@ dependencies:
|
|||
### Scientific Research Methodologies
|
||||
|
||||
#### Scientific Analysis Framework
|
||||
|
||||
- **Literature Review**: Peer-reviewed research, citation analysis, consensus building
|
||||
- **Methodology Assessment**: Research design quality, statistical validity, reproducibility
|
||||
- **Evidence Evaluation**: Study quality, sample sizes, control factors
|
||||
|
|
@ -378,6 +405,7 @@ dependencies:
|
|||
- **Application Assessment**: Practical implications, implementation feasibility
|
||||
|
||||
#### Scientific Source Priorities
|
||||
|
||||
1. **Peer-Reviewed Journals**: Primary research, systematic reviews, meta-analyses
|
||||
2. **Academic Databases**: Research repositories, citation networks, preprints
|
||||
3. **Conference Proceedings**: Latest research, emerging trends, expert presentations
|
||||
|
|
@ -389,6 +417,7 @@ dependencies:
|
|||
### Source Credibility Assessment
|
||||
|
||||
#### Primary Source Evaluation
|
||||
|
||||
- **Authority**: Expertise of authors, institutional affiliation, credentials
|
||||
- **Accuracy**: Fact-checking, peer review process, error correction mechanisms
|
||||
- **Objectivity**: Bias assessment, funding sources, conflict of interest disclosure
|
||||
|
|
@ -396,6 +425,7 @@ dependencies:
|
|||
- **Coverage**: Scope comprehensiveness, detail level, methodology transparency
|
||||
|
||||
#### Secondary Source Validation
|
||||
|
||||
- **Citation Quality**: Primary source references, citation accuracy, source diversity
|
||||
- **Synthesis Quality**: Analysis depth, logical coherence, balanced perspective
|
||||
- **Author Expertise**: Subject matter knowledge, track record, reputation
|
||||
|
|
@ -405,6 +435,7 @@ dependencies:
|
|||
### Information Synthesis Approaches
|
||||
|
||||
#### Multi-Perspective Integration
|
||||
|
||||
- **Convergence Analysis**: Identify areas where sources agree consistently
|
||||
- **Divergence Documentation**: Note significant disagreements and analyze causes
|
||||
- **Confidence Weighting**: Assign confidence levels based on source quality and consensus
|
||||
|
|
@ -412,6 +443,7 @@ dependencies:
|
|||
- **Uncertainty Quantification**: Document limitations and areas of unclear evidence
|
||||
|
||||
#### Evidence Hierarchy
|
||||
|
||||
1. **High Confidence**: Multiple credible sources, recent information, expert consensus
|
||||
2. **Medium Confidence**: Some credible sources, mixed consensus, moderate currency
|
||||
3. **Low Confidence**: Limited sources, significant disagreement, dated information
|
||||
|
|
@ -421,6 +453,7 @@ dependencies:
|
|||
## Domain-Specific Analysis Frameworks
|
||||
|
||||
### Technical Analysis Framework
|
||||
|
||||
- **Feasibility Assessment**: Technical viability, implementation complexity, resource requirements
|
||||
- **Scalability Analysis**: Performance under load, growth accommodation, architectural limits
|
||||
- **Integration Evaluation**: Compatibility assessment, integration complexity, ecosystem fit
|
||||
|
|
@ -428,6 +461,7 @@ dependencies:
|
|||
- **Risk Assessment**: Technical risks, dependency risks, obsolescence potential
|
||||
|
||||
### Business Analysis Framework
|
||||
|
||||
- **Value Proposition**: Customer value delivery, competitive advantage, market differentiation
|
||||
- **Financial Impact**: Cost analysis, revenue potential, ROI assessment, budget implications
|
||||
- **Strategic Alignment**: Goal consistency, priority alignment, resource allocation fit
|
||||
|
|
@ -435,6 +469,7 @@ dependencies:
|
|||
- **Risk-Benefit Analysis**: Potential rewards vs implementation risks and costs
|
||||
|
||||
### User Impact Framework
|
||||
|
||||
- **User Experience**: Ease of use, learning curve, satisfaction factors, accessibility
|
||||
- **Adoption Factors**: Barriers to adoption, motivation drivers, change management needs
|
||||
- **Value Delivery**: User benefit realization, problem solving effectiveness, outcome achievement
|
||||
|
|
@ -444,6 +479,7 @@ dependencies:
|
|||
## Research Coordination Best Practices
|
||||
|
||||
### Multi-Researcher Coordination
|
||||
|
||||
- **Perspective Assignment**: Clear domain boundaries, minimal overlap, comprehensive coverage
|
||||
- **Communication Protocols**: Regular check-ins, conflict resolution processes, coordination methods
|
||||
- **Quality Standards**: Consistent source credibility requirements, analysis depth expectations
|
||||
|
|
@ -451,6 +487,7 @@ dependencies:
|
|||
- **Integration Planning**: Synthesis approach design, conflict resolution strategies, gap handling
|
||||
|
||||
### Research Efficiency Optimization
|
||||
|
||||
- **Source Sharing**: Avoid duplicate source evaluation across researchers
|
||||
- **Finding Coordination**: Share relevant discoveries between perspectives
|
||||
- **Quality Checks**: Cross-validation of key findings, source verification collaboration
|
||||
|
|
|
|||
|
|
@ -101,6 +101,7 @@ commands:
|
|||
- perform-market-research: use task create-doc with market-research-tmpl.yaml
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt.md
|
||||
- gemini-analyze {target}: Analyze large codebases or files using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
|
|
@ -113,6 +114,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- facilitate-brainstorming-session.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- brainstorming-output-tmpl.yaml
|
||||
|
|
@ -1703,6 +1705,262 @@ Generate structured document with these sections:
|
|||
- Respect their process and timing
|
||||
==================== END: .bmad-2d-phaser-game-dev/tasks/facilitate-brainstorming-session.md ====================
|
||||
|
||||
==================== START: .bmad-2d-phaser-game-dev/tasks/gemini-analysis.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Gemini Analysis Task
|
||||
|
||||
## Purpose
|
||||
|
||||
This task provides access to Google Gemini CLI's massive context window for analyzing large codebases, big files, or complex multi-file operations that exceed normal context limits. Gemini CLI can handle entire project contexts that would overflow standard AI context windows.
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- **Massive Context Window**: Analyze entire codebases without context limitations
|
||||
- **File & Directory Inclusion**: Use `@` syntax for precise file/directory targeting
|
||||
- **Multi-File Analysis**: Compare and analyze multiple large files simultaneously
|
||||
- **Codebase Flattening**: Alternative to local flattener for large projects
|
||||
- **Feature Verification**: Check if specific features are implemented across entire projects
|
||||
- **Pattern Discovery**: Find patterns, implementations, and architectural decisions project-wide
|
||||
|
||||
## When to Use Gemini Analysis
|
||||
|
||||
### Ideal Use Cases
|
||||
- **Large Codebase Architecture Analysis**: Understanding overall system design
|
||||
- **Multi-File Pattern Searching**: Finding implementations across multiple files
|
||||
- **Feature Implementation Verification**: Checking if features exist project-wide
|
||||
- **Brownfield Project Discovery**: Understanding existing large codebases
|
||||
- **Context-Heavy Debugging**: Analyzing complex interactions across many files
|
||||
- **Comprehensive Code Reviews**: Reviewing entire feature implementations
|
||||
|
||||
### Context Size Triggers
|
||||
- Files or directories totaling >100KB of content
|
||||
- Analysis requiring >20 files simultaneously
|
||||
- Project-wide architectural understanding needed
|
||||
- Current context window insufficient for task
|
||||
|
||||
## Analysis Modes
|
||||
|
||||
### 1. Single File Analysis
|
||||
**Use Case**: Deep analysis of large individual files
|
||||
**Command Pattern**: `gemini "@file/path Analyze this file's structure and purpose"`
|
||||
**Examples**:
|
||||
- `@src/main.py Explain this file's architecture and key patterns`
|
||||
- `@config/webpack.config.js Break down this configuration and its impact`
|
||||
|
||||
### 2. Directory Analysis
|
||||
**Use Case**: Understanding structure and patterns within specific directories
|
||||
**Command Pattern**: `gemini "@directory/ Analyze the architecture of this codebase section"`
|
||||
**Examples**:
|
||||
- `@src/components/ Summarize the component architecture and patterns`
|
||||
- `@api/routes/ Document all API endpoints and their purposes`
|
||||
|
||||
### 3. Multi-Path Analysis
|
||||
**Use Case**: Comparing and analyzing relationships between multiple areas
|
||||
**Command Pattern**: `gemini "@path1 @path2 Analyze relationships between these areas"`
|
||||
**Examples**:
|
||||
- `@src/ @tests/ Analyze test coverage for the source code`
|
||||
- `@frontend/ @backend/ How do these communicate and what are the integration points?`
|
||||
|
||||
### 4. Project Overview
|
||||
**Use Case**: Comprehensive understanding of entire project
|
||||
**Command Pattern**: `gemini --all-files "Provide comprehensive project analysis"`
|
||||
**Examples**:
|
||||
- `--all-files "Give me an architectural overview of this entire project"`
|
||||
- `--all-files "Summarize the technology stack and key architectural decisions"`
|
||||
|
||||
### 5. Feature Verification
|
||||
**Use Case**: Checking if specific features or patterns are implemented
|
||||
**Command Pattern**: `gemini "@codebase/ Has [feature] been implemented? Show relevant files"`
|
||||
**Examples**:
|
||||
- `@src/ @lib/ Has dark mode been implemented? Show relevant files and functions`
|
||||
- `@api/ @middleware/ Is rate limiting implemented? Show the implementation details`
|
||||
|
||||
### 6. Pattern Discovery
|
||||
**Use Case**: Finding specific coding patterns, security measures, or architectural decisions
|
||||
**Command Pattern**: `gemini "@codebase/ Find all instances of [pattern] and list with file paths"`
|
||||
**Examples**:
|
||||
- `@src/ Are there any React hooks that handle WebSocket connections?`
|
||||
- `@backend/ Is proper error handling implemented for all endpoints?`
|
||||
|
||||
## Task Process
|
||||
|
||||
### 1. Analysis Request Processing
|
||||
|
||||
#### Gather Requirements
|
||||
- **Analysis Type**: Which mode fits the user's need?
|
||||
- **Target Paths**: What files/directories should be included?
|
||||
- **Analysis Depth**: High-level overview vs detailed analysis?
|
||||
- **Specific Questions**: What particular aspects to focus on?
|
||||
- **Output Format**: How should results be presented?
|
||||
|
||||
#### Path Validation
|
||||
- **Existence Check**: Verify all specified paths exist
|
||||
- **Size Assessment**: Estimate total content size
|
||||
- **Permission Validation**: Ensure readable access
|
||||
- **Safety Check**: Confirm read-only analysis scope
|
||||
|
||||
### 2. Command Construction
|
||||
|
||||
#### Basic Command Structure
|
||||
```bash
|
||||
gemini [options] "@path1 @path2 [prompt]"
|
||||
```
|
||||
|
||||
#### Option Selection
|
||||
- **Standard Mode**: `gemini "@path prompt"`
|
||||
- **All Files Mode**: `gemini --all-files "prompt"`
|
||||
- **Safe Mode**: `gemini --approval-mode default "@path prompt"`
|
||||
- **Sandbox Mode**: `gemini --sandbox "@path prompt"` (if editing needed)
|
||||
|
||||
#### Path Formatting
|
||||
- **Single File**: `@src/main.py`
|
||||
- **Directory**: `@src/components/`
|
||||
- **Multiple Paths**: `@src/ @tests/ @docs/`
|
||||
- **Current Directory**: `@./`
|
||||
- **Specific Files**: `@package.json @README.md`
|
||||
|
||||
### 3. Safety and Validation
|
||||
|
||||
#### Pre-Execution Checks
|
||||
- **Read-Only Confirmation**: Ensure analysis-only intent
|
||||
- **Path Sanitization**: Validate and clean file paths
|
||||
- **Size Warnings**: Alert for extremely large contexts
|
||||
- **Approval Mode**: Set appropriate safety level
|
||||
|
||||
#### Command Safety Options
|
||||
```yaml
|
||||
safety_levels:
|
||||
read_only: "Default - analysis only, no modifications"
|
||||
default: "Prompt for any file modifications"
|
||||
auto_edit: "Auto-approve edit tools only"
|
||||
sandbox: "Run in safe sandbox environment"
|
||||
```
|
||||
|
||||
### 4. Execution and Results
|
||||
|
||||
#### Command Execution
|
||||
1. **Validate Paths**: Confirm all targets exist and are accessible
|
||||
2. **Construct Command**: Build proper Gemini CLI command
|
||||
3. **Execute Analysis**: Run Gemini CLI with specified parameters
|
||||
4. **Capture Output**: Collect and format analysis results
|
||||
5. **Error Handling**: Manage CLI failures or timeouts
|
||||
|
||||
#### Result Processing
|
||||
- **Output Formatting**: Structure results for readability
|
||||
- **Key Insights Extraction**: Highlight critical findings
|
||||
- **Follow-up Suggestions**: Recommend next steps
|
||||
- **Source Documentation**: Reference analyzed files/paths
|
||||
|
||||
### 5. Integration with BMAD Workflow
|
||||
|
||||
#### Result Documentation
|
||||
- **Store in Project**: Save significant analyses in `docs/analysis/`
|
||||
- **Reference in Stories**: Link analyses to relevant development stories
|
||||
- **Architecture Updates**: Update architecture docs with findings
|
||||
- **Knowledge Preservation**: Maintain analysis artifacts for team reference
|
||||
|
||||
#### Follow-Up Actions
|
||||
- **Story Creation**: Generate development stories from findings
|
||||
- **Architecture Review**: Update architectural documentation
|
||||
- **Technical Debt**: Identify and document technical debt items
|
||||
- **Research Coordination**: Trigger detailed research if needed
|
||||
|
||||
## Command Templates
|
||||
|
||||
### Architecture Analysis
|
||||
```bash
|
||||
# Overall project architecture
|
||||
gemini --all-files "Analyze the overall architecture of this project. Include technology stack, key patterns, and architectural decisions."
|
||||
|
||||
# Specific component architecture
|
||||
gemini "@src/components/ Analyze the component architecture. What patterns are used and how are components organized?"
|
||||
|
||||
# Backend architecture
|
||||
gemini "@api/ @services/ @middleware/ Analyze the backend architecture. How are routes organized and what patterns are used?"
|
||||
```
|
||||
|
||||
### Feature Verification
|
||||
```bash
|
||||
# Authentication implementation
|
||||
gemini "@src/ @api/ Is JWT authentication fully implemented? Show all auth-related files and middleware."
|
||||
|
||||
# Security measures
|
||||
gemini "@src/ @api/ What security measures are implemented? Look for input validation, CORS, rate limiting."
|
||||
|
||||
# Testing coverage
|
||||
gemini "@src/ @tests/ Analyze test coverage. Which areas are well-tested and which need more tests?"
|
||||
```
|
||||
|
||||
### Code Quality Analysis
|
||||
```bash
|
||||
# Error handling patterns
|
||||
gemini "@src/ @api/ How is error handling implemented throughout the codebase? Show examples."
|
||||
|
||||
# Performance considerations
|
||||
gemini "@src/ @lib/ What performance optimizations are in place? Identify potential bottlenecks."
|
||||
|
||||
# Code organization
|
||||
gemini "@src/ How is the code organized? What are the main modules and their responsibilities?"
|
||||
```
|
||||
|
||||
### Technology Assessment
|
||||
```bash
|
||||
# Dependency analysis
|
||||
gemini "@package.json @src/ What are the key dependencies and how are they used in the code?"
|
||||
|
||||
# Build system analysis
|
||||
gemini "@webpack.config.js @package.json @src/ How is the build system configured and what optimizations are in place?"
|
||||
|
||||
# Database integration
|
||||
gemini "@models/ @migrations/ @src/ How is the database integrated? What ORM patterns are used?"
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Issues
|
||||
- **Path Not Found**: Specified files/directories don't exist
|
||||
- **Context Too Large**: Even Gemini's context has limits
|
||||
- **CLI Unavailable**: Gemini CLI not installed or configured
|
||||
- **Permission Denied**: Cannot read specified files
|
||||
- **Command Timeout**: Analysis takes too long to complete
|
||||
|
||||
### Error Recovery
|
||||
- **Path Validation**: Pre-validate all paths before execution
|
||||
- **Graceful Degradation**: Suggest smaller scope if context too large
|
||||
- **Alternative Approaches**: Offer local flattener or partial analysis
|
||||
- **Clear Error Messages**: Provide actionable error information
|
||||
- **Fallback Options**: Suggest manual analysis approaches
|
||||
|
||||
### Safety Measures
|
||||
- **Read-Only Default**: Never modify files without explicit permission
|
||||
- **Approval Prompts**: Confirm any file modifications
|
||||
- **Sandbox Options**: Use sandbox mode for risky operations
|
||||
- **Timeout Protection**: Prevent hanging operations
|
||||
- **Resource Monitoring**: Track memory and processing usage
|
||||
|
||||
## Integration Notes
|
||||
|
||||
### With Existing BMAD Tools
|
||||
- **Flattener Integration**: Use existing flattener for preprocessing when needed
|
||||
- **Research Coordination**: Can trigger research system for follow-up analysis
|
||||
- **Story Generation**: Results can inform story creation
|
||||
- **Architecture Documentation**: Updates architectural understanding
|
||||
|
||||
### With Core Configuration
|
||||
- **Command Templates**: Stored in core-config.yaml for consistency
|
||||
- **Default Settings**: Safety and approval modes configured globally
|
||||
- **Path Patterns**: Common path combinations for different project types
|
||||
- **Integration Points**: How Gemini analysis feeds into BMAD workflow
|
||||
|
||||
### Agent Accessibility
|
||||
All agents with Gemini analysis capability will have access to:
|
||||
- **Standard Analysis**: `*gemini-analyze` command for common patterns
|
||||
- **Custom Queries**: Ability to specify custom analysis prompts
|
||||
- **Result Integration**: Automatic integration with agent workflows
|
||||
- **Safety Controls**: Appropriate safety measures for agent context
|
||||
==================== END: .bmad-2d-phaser-game-dev/tasks/gemini-analysis.md ====================
|
||||
|
||||
==================== START: .bmad-2d-phaser-game-dev/tasks/request-research.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
|
|
@ -1723,6 +1981,7 @@ This task provides a unified interface for any agent to request specialized rese
|
|||
## Usage Scenarios
|
||||
|
||||
### From Any Agent
|
||||
|
||||
Any agent can call this task to get specialized research assistance:
|
||||
|
||||
```yaml
|
||||
|
|
@ -1744,24 +2003,28 @@ Any agent can call this task to get specialized research assistance:
|
|||
The task will elicit a structured research request with these components:
|
||||
|
||||
#### Research Context
|
||||
|
||||
- **Requesting Agent**: Which agent is making the request
|
||||
- **Project Context**: Current project phase and relevant background
|
||||
- **Previous Research**: Check research log for related prior work
|
||||
- **Urgency Level**: Timeline constraints and priority
|
||||
|
||||
#### Research Objective
|
||||
|
||||
- **Primary Goal**: What specific question or problem needs researching
|
||||
- **Success Criteria**: How to measure if research achieved its objective
|
||||
- **Scope Boundaries**: What to include/exclude from research
|
||||
- **Decision Impact**: How results will be used
|
||||
|
||||
#### Domain Specialization Requirements
|
||||
|
||||
- **Primary Domain**: Main area of expertise needed (technical, market, user, etc.)
|
||||
- **Secondary Domains**: Additional perspectives required
|
||||
- **Specific Expertise**: Particular skills or knowledge areas
|
||||
- **Research Depth**: High-level overview vs deep technical analysis
|
||||
|
||||
#### Output Requirements
|
||||
|
||||
- **Format**: Executive summary, detailed report, comparison matrix, etc.
|
||||
- **Audience**: Who will consume the research results
|
||||
- **Integration**: How results feed into next steps
|
||||
|
|
@ -1790,12 +2053,14 @@ Each Researcher Agent will:
|
|||
### 4. Result Delivery
|
||||
|
||||
#### To Requesting Agent
|
||||
|
||||
- **Executive Summary**: Key findings and recommendations
|
||||
- **Detailed Analysis**: Comprehensive research results
|
||||
- **Source Documentation**: Links and citations for verification
|
||||
- **Next Steps**: Recommended actions or follow-up research
|
||||
|
||||
#### To Research Log
|
||||
|
||||
- **Research Entry**: Concise summary stored in `docs/research/YYYY-MM-DD-research-topic.md`
|
||||
- **Index Update**: Add entry to `docs/research/research-index.md`
|
||||
- **Tag Classification**: Add searchable tags for future reference
|
||||
|
|
@ -1814,40 +2079,40 @@ When executing this task, use this structure for research requests:
|
|||
```yaml
|
||||
research_request:
|
||||
metadata:
|
||||
requesting_agent: "[agent-id]"
|
||||
request_date: "[YYYY-MM-DD]"
|
||||
priority: "[high|medium|low]"
|
||||
timeline: "[timeframe needed]"
|
||||
requesting_agent: '[agent-id]'
|
||||
request_date: '[YYYY-MM-DD]'
|
||||
priority: '[high|medium|low]'
|
||||
timeline: '[timeframe needed]'
|
||||
|
||||
context:
|
||||
project_phase: "[planning|development|validation|etc]"
|
||||
background: "[relevant project context]"
|
||||
related_docs: "[PRD, architecture, stories, etc]"
|
||||
previous_research: "[check research log references]"
|
||||
project_phase: '[planning|development|validation|etc]'
|
||||
background: '[relevant project context]'
|
||||
related_docs: '[PRD, architecture, stories, etc]'
|
||||
previous_research: '[check research log references]'
|
||||
|
||||
objective:
|
||||
primary_goal: "[specific research question]"
|
||||
success_criteria: "[how to measure success]"
|
||||
scope: "[boundaries and limitations]"
|
||||
decision_impact: "[how results will be used]"
|
||||
primary_goal: '[specific research question]'
|
||||
success_criteria: '[how to measure success]'
|
||||
scope: '[boundaries and limitations]'
|
||||
decision_impact: '[how results will be used]'
|
||||
|
||||
specialization:
|
||||
primary_domain: "[technical|market|user|competitive|regulatory|etc]"
|
||||
secondary_domains: "[additional perspectives needed]"
|
||||
specific_expertise: "[particular skills required]"
|
||||
research_depth: "[overview|detailed|comprehensive]"
|
||||
primary_domain: '[technical|market|user|competitive|regulatory|etc]'
|
||||
secondary_domains: '[additional perspectives needed]'
|
||||
specific_expertise: '[particular skills required]'
|
||||
research_depth: '[overview|detailed|comprehensive]'
|
||||
|
||||
team_config:
|
||||
researcher_count: "[1-3, default 3]"
|
||||
perspective_1: "[domain and focus area]"
|
||||
perspective_2: "[domain and focus area]"
|
||||
perspective_3: "[domain and focus area]"
|
||||
researcher_count: '[1-3, default 3]'
|
||||
perspective_1: '[domain and focus area]'
|
||||
perspective_2: '[domain and focus area]'
|
||||
perspective_3: '[domain and focus area]'
|
||||
|
||||
output:
|
||||
format: "[executive_summary|detailed_report|comparison_matrix|etc]"
|
||||
audience: "[who will use results]"
|
||||
integration: "[how results feed into workflow]"
|
||||
citation_level: "[minimal|standard|comprehensive]"
|
||||
format: '[executive_summary|detailed_report|comparison_matrix|etc]'
|
||||
audience: '[who will use results]'
|
||||
integration: '[how results feed into workflow]'
|
||||
citation_level: '[minimal|standard|comprehensive]'
|
||||
```
|
||||
|
||||
## Integration with Existing Agents
|
||||
|
|
@ -1879,26 +2144,32 @@ commands:
|
|||
## Research Log Structure
|
||||
|
||||
### Research Index (`docs/research/research-index.md`)
|
||||
|
||||
```markdown
|
||||
# Research Index
|
||||
|
||||
## Recent Research
|
||||
|
||||
- [2024-01-15: AI Model Comparison](2024-01-15-ai-model-comparison.md) - Technical analysis of LLM options
|
||||
- [2024-01-12: Payment Gateway Analysis](2024-01-12-payment-gateway-analysis.md) - Market comparison of payment solutions
|
||||
|
||||
## Research by Category
|
||||
|
||||
### Technical Research
|
||||
|
||||
- AI/ML Models
|
||||
- Architecture Decisions
|
||||
- Technology Stacks
|
||||
|
||||
### Market Research
|
||||
|
||||
- Competitive Analysis
|
||||
- User Behavior
|
||||
- Industry Trends
|
||||
```
|
||||
|
||||
### Individual Research Files (`docs/research/YYYY-MM-DD-topic.md`)
|
||||
|
||||
```markdown
|
||||
# Research: [Topic]
|
||||
|
||||
|
|
@ -1907,31 +2178,41 @@ commands:
|
|||
**Research Team**: [perspectives used]
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[Key findings and recommendations]
|
||||
|
||||
## Research Objective
|
||||
|
||||
[What was being researched and why]
|
||||
|
||||
## Key Findings
|
||||
|
||||
[Main insights from all perspectives]
|
||||
|
||||
## Recommendations
|
||||
|
||||
[Actionable next steps]
|
||||
|
||||
## Research Team Perspectives
|
||||
|
||||
### Perspective 1: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 2: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 3: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
## Sources and References
|
||||
|
||||
[Credible sources cited by research team]
|
||||
|
||||
## Tags
|
||||
|
||||
[Searchable tags for future reference]
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -102,6 +102,7 @@ commands:
|
|||
- perform-market-research: use task create-doc with market-research-tmpl.yaml
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt.md
|
||||
- gemini-analyze {target}: Analyze large codebases or files using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
|
|
@ -114,6 +115,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- facilitate-brainstorming-session.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- brainstorming-output-tmpl.yaml
|
||||
|
|
@ -2286,6 +2288,262 @@ Generate structured document with these sections:
|
|||
- Respect their process and timing
|
||||
==================== END: .bmad-2d-unity-game-dev/tasks/facilitate-brainstorming-session.md ====================
|
||||
|
||||
==================== START: .bmad-2d-unity-game-dev/tasks/gemini-analysis.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Gemini Analysis Task
|
||||
|
||||
## Purpose
|
||||
|
||||
This task provides access to Google Gemini CLI's massive context window for analyzing large codebases, big files, or complex multi-file operations that exceed normal context limits. Gemini CLI can handle entire project contexts that would overflow standard AI context windows.
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- **Massive Context Window**: Analyze entire codebases without context limitations
|
||||
- **File & Directory Inclusion**: Use `@` syntax for precise file/directory targeting
|
||||
- **Multi-File Analysis**: Compare and analyze multiple large files simultaneously
|
||||
- **Codebase Flattening**: Alternative to local flattener for large projects
|
||||
- **Feature Verification**: Check if specific features are implemented across entire projects
|
||||
- **Pattern Discovery**: Find patterns, implementations, and architectural decisions project-wide
|
||||
|
||||
## When to Use Gemini Analysis
|
||||
|
||||
### Ideal Use Cases
|
||||
- **Large Codebase Architecture Analysis**: Understanding overall system design
|
||||
- **Multi-File Pattern Searching**: Finding implementations across multiple files
|
||||
- **Feature Implementation Verification**: Checking if features exist project-wide
|
||||
- **Brownfield Project Discovery**: Understanding existing large codebases
|
||||
- **Context-Heavy Debugging**: Analyzing complex interactions across many files
|
||||
- **Comprehensive Code Reviews**: Reviewing entire feature implementations
|
||||
|
||||
### Context Size Triggers
|
||||
- Files or directories totaling >100KB of content
|
||||
- Analysis requiring >20 files simultaneously
|
||||
- Project-wide architectural understanding needed
|
||||
- Current context window insufficient for task
|
||||
|
||||
## Analysis Modes
|
||||
|
||||
### 1. Single File Analysis
|
||||
**Use Case**: Deep analysis of large individual files
|
||||
**Command Pattern**: `gemini "@file/path Analyze this file's structure and purpose"`
|
||||
**Examples**:
|
||||
- `@src/main.py Explain this file's architecture and key patterns`
|
||||
- `@config/webpack.config.js Break down this configuration and its impact`
|
||||
|
||||
### 2. Directory Analysis
|
||||
**Use Case**: Understanding structure and patterns within specific directories
|
||||
**Command Pattern**: `gemini "@directory/ Analyze the architecture of this codebase section"`
|
||||
**Examples**:
|
||||
- `@src/components/ Summarize the component architecture and patterns`
|
||||
- `@api/routes/ Document all API endpoints and their purposes`
|
||||
|
||||
### 3. Multi-Path Analysis
|
||||
**Use Case**: Comparing and analyzing relationships between multiple areas
|
||||
**Command Pattern**: `gemini "@path1 @path2 Analyze relationships between these areas"`
|
||||
**Examples**:
|
||||
- `@src/ @tests/ Analyze test coverage for the source code`
|
||||
- `@frontend/ @backend/ How do these communicate and what are the integration points?`
|
||||
|
||||
### 4. Project Overview
|
||||
**Use Case**: Comprehensive understanding of entire project
|
||||
**Command Pattern**: `gemini --all-files "Provide comprehensive project analysis"`
|
||||
**Examples**:
|
||||
- `--all-files "Give me an architectural overview of this entire project"`
|
||||
- `--all-files "Summarize the technology stack and key architectural decisions"`
|
||||
|
||||
### 5. Feature Verification
|
||||
**Use Case**: Checking if specific features or patterns are implemented
|
||||
**Command Pattern**: `gemini "@codebase/ Has [feature] been implemented? Show relevant files"`
|
||||
**Examples**:
|
||||
- `@src/ @lib/ Has dark mode been implemented? Show relevant files and functions`
|
||||
- `@api/ @middleware/ Is rate limiting implemented? Show the implementation details`
|
||||
|
||||
### 6. Pattern Discovery
|
||||
**Use Case**: Finding specific coding patterns, security measures, or architectural decisions
|
||||
**Command Pattern**: `gemini "@codebase/ Find all instances of [pattern] and list with file paths"`
|
||||
**Examples**:
|
||||
- `@src/ Are there any React hooks that handle WebSocket connections?`
|
||||
- `@backend/ Is proper error handling implemented for all endpoints?`
|
||||
|
||||
## Task Process
|
||||
|
||||
### 1. Analysis Request Processing
|
||||
|
||||
#### Gather Requirements
|
||||
- **Analysis Type**: Which mode fits the user's need?
|
||||
- **Target Paths**: What files/directories should be included?
|
||||
- **Analysis Depth**: High-level overview vs detailed analysis?
|
||||
- **Specific Questions**: What particular aspects to focus on?
|
||||
- **Output Format**: How should results be presented?
|
||||
|
||||
#### Path Validation
|
||||
- **Existence Check**: Verify all specified paths exist
|
||||
- **Size Assessment**: Estimate total content size
|
||||
- **Permission Validation**: Ensure readable access
|
||||
- **Safety Check**: Confirm read-only analysis scope
|
||||
|
||||
### 2. Command Construction
|
||||
|
||||
#### Basic Command Structure
|
||||
```bash
|
||||
gemini [options] "@path1 @path2 [prompt]"
|
||||
```
|
||||
|
||||
#### Option Selection
|
||||
- **Standard Mode**: `gemini "@path prompt"`
|
||||
- **All Files Mode**: `gemini --all-files "prompt"`
|
||||
- **Safe Mode**: `gemini --approval-mode default "@path prompt"`
|
||||
- **Sandbox Mode**: `gemini --sandbox "@path prompt"` (if editing needed)
|
||||
|
||||
#### Path Formatting
|
||||
- **Single File**: `@src/main.py`
|
||||
- **Directory**: `@src/components/`
|
||||
- **Multiple Paths**: `@src/ @tests/ @docs/`
|
||||
- **Current Directory**: `@./`
|
||||
- **Specific Files**: `@package.json @README.md`
|
||||
|
||||
### 3. Safety and Validation
|
||||
|
||||
#### Pre-Execution Checks
|
||||
- **Read-Only Confirmation**: Ensure analysis-only intent
|
||||
- **Path Sanitization**: Validate and clean file paths
|
||||
- **Size Warnings**: Alert for extremely large contexts
|
||||
- **Approval Mode**: Set appropriate safety level
|
||||
|
||||
#### Command Safety Options
|
||||
```yaml
|
||||
safety_levels:
|
||||
read_only: "Default - analysis only, no modifications"
|
||||
default: "Prompt for any file modifications"
|
||||
auto_edit: "Auto-approve edit tools only"
|
||||
sandbox: "Run in safe sandbox environment"
|
||||
```
|
||||
|
||||
### 4. Execution and Results
|
||||
|
||||
#### Command Execution
|
||||
1. **Validate Paths**: Confirm all targets exist and are accessible
|
||||
2. **Construct Command**: Build proper Gemini CLI command
|
||||
3. **Execute Analysis**: Run Gemini CLI with specified parameters
|
||||
4. **Capture Output**: Collect and format analysis results
|
||||
5. **Error Handling**: Manage CLI failures or timeouts
|
||||
|
||||
#### Result Processing
|
||||
- **Output Formatting**: Structure results for readability
|
||||
- **Key Insights Extraction**: Highlight critical findings
|
||||
- **Follow-up Suggestions**: Recommend next steps
|
||||
- **Source Documentation**: Reference analyzed files/paths
|
||||
|
||||
### 5. Integration with BMAD Workflow
|
||||
|
||||
#### Result Documentation
|
||||
- **Store in Project**: Save significant analyses in `docs/analysis/`
|
||||
- **Reference in Stories**: Link analyses to relevant development stories
|
||||
- **Architecture Updates**: Update architecture docs with findings
|
||||
- **Knowledge Preservation**: Maintain analysis artifacts for team reference
|
||||
|
||||
#### Follow-Up Actions
|
||||
- **Story Creation**: Generate development stories from findings
|
||||
- **Architecture Review**: Update architectural documentation
|
||||
- **Technical Debt**: Identify and document technical debt items
|
||||
- **Research Coordination**: Trigger detailed research if needed
|
||||
|
||||
## Command Templates
|
||||
|
||||
### Architecture Analysis
|
||||
```bash
|
||||
# Overall project architecture
|
||||
gemini --all-files "Analyze the overall architecture of this project. Include technology stack, key patterns, and architectural decisions."
|
||||
|
||||
# Specific component architecture
|
||||
gemini "@src/components/ Analyze the component architecture. What patterns are used and how are components organized?"
|
||||
|
||||
# Backend architecture
|
||||
gemini "@api/ @services/ @middleware/ Analyze the backend architecture. How are routes organized and what patterns are used?"
|
||||
```
|
||||
|
||||
### Feature Verification
|
||||
```bash
|
||||
# Authentication implementation
|
||||
gemini "@src/ @api/ Is JWT authentication fully implemented? Show all auth-related files and middleware."
|
||||
|
||||
# Security measures
|
||||
gemini "@src/ @api/ What security measures are implemented? Look for input validation, CORS, rate limiting."
|
||||
|
||||
# Testing coverage
|
||||
gemini "@src/ @tests/ Analyze test coverage. Which areas are well-tested and which need more tests?"
|
||||
```
|
||||
|
||||
### Code Quality Analysis
|
||||
```bash
|
||||
# Error handling patterns
|
||||
gemini "@src/ @api/ How is error handling implemented throughout the codebase? Show examples."
|
||||
|
||||
# Performance considerations
|
||||
gemini "@src/ @lib/ What performance optimizations are in place? Identify potential bottlenecks."
|
||||
|
||||
# Code organization
|
||||
gemini "@src/ How is the code organized? What are the main modules and their responsibilities?"
|
||||
```
|
||||
|
||||
### Technology Assessment
|
||||
```bash
|
||||
# Dependency analysis
|
||||
gemini "@package.json @src/ What are the key dependencies and how are they used in the code?"
|
||||
|
||||
# Build system analysis
|
||||
gemini "@webpack.config.js @package.json @src/ How is the build system configured and what optimizations are in place?"
|
||||
|
||||
# Database integration
|
||||
gemini "@models/ @migrations/ @src/ How is the database integrated? What ORM patterns are used?"
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Issues
|
||||
- **Path Not Found**: Specified files/directories don't exist
|
||||
- **Context Too Large**: Even Gemini's context has limits
|
||||
- **CLI Unavailable**: Gemini CLI not installed or configured
|
||||
- **Permission Denied**: Cannot read specified files
|
||||
- **Command Timeout**: Analysis takes too long to complete
|
||||
|
||||
### Error Recovery
|
||||
- **Path Validation**: Pre-validate all paths before execution
|
||||
- **Graceful Degradation**: Suggest smaller scope if context too large
|
||||
- **Alternative Approaches**: Offer local flattener or partial analysis
|
||||
- **Clear Error Messages**: Provide actionable error information
|
||||
- **Fallback Options**: Suggest manual analysis approaches
|
||||
|
||||
### Safety Measures
|
||||
- **Read-Only Default**: Never modify files without explicit permission
|
||||
- **Approval Prompts**: Confirm any file modifications
|
||||
- **Sandbox Options**: Use sandbox mode for risky operations
|
||||
- **Timeout Protection**: Prevent hanging operations
|
||||
- **Resource Monitoring**: Track memory and processing usage
|
||||
|
||||
## Integration Notes
|
||||
|
||||
### With Existing BMAD Tools
|
||||
- **Flattener Integration**: Use existing flattener for preprocessing when needed
|
||||
- **Research Coordination**: Can trigger research system for follow-up analysis
|
||||
- **Story Generation**: Results can inform story creation
|
||||
- **Architecture Documentation**: Updates architectural understanding
|
||||
|
||||
### With Core Configuration
|
||||
- **Command Templates**: Stored in core-config.yaml for consistency
|
||||
- **Default Settings**: Safety and approval modes configured globally
|
||||
- **Path Patterns**: Common path combinations for different project types
|
||||
- **Integration Points**: How Gemini analysis feeds into BMAD workflow
|
||||
|
||||
### Agent Accessibility
|
||||
All agents with Gemini analysis capability will have access to:
|
||||
- **Standard Analysis**: `*gemini-analyze` command for common patterns
|
||||
- **Custom Queries**: Ability to specify custom analysis prompts
|
||||
- **Result Integration**: Automatic integration with agent workflows
|
||||
- **Safety Controls**: Appropriate safety measures for agent context
|
||||
==================== END: .bmad-2d-unity-game-dev/tasks/gemini-analysis.md ====================
|
||||
|
||||
==================== START: .bmad-2d-unity-game-dev/tasks/request-research.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
|
|
@ -2306,6 +2564,7 @@ This task provides a unified interface for any agent to request specialized rese
|
|||
## Usage Scenarios
|
||||
|
||||
### From Any Agent
|
||||
|
||||
Any agent can call this task to get specialized research assistance:
|
||||
|
||||
```yaml
|
||||
|
|
@ -2327,24 +2586,28 @@ Any agent can call this task to get specialized research assistance:
|
|||
The task will elicit a structured research request with these components:
|
||||
|
||||
#### Research Context
|
||||
|
||||
- **Requesting Agent**: Which agent is making the request
|
||||
- **Project Context**: Current project phase and relevant background
|
||||
- **Previous Research**: Check research log for related prior work
|
||||
- **Urgency Level**: Timeline constraints and priority
|
||||
|
||||
#### Research Objective
|
||||
|
||||
- **Primary Goal**: What specific question or problem needs researching
|
||||
- **Success Criteria**: How to measure if research achieved its objective
|
||||
- **Scope Boundaries**: What to include/exclude from research
|
||||
- **Decision Impact**: How results will be used
|
||||
|
||||
#### Domain Specialization Requirements
|
||||
|
||||
- **Primary Domain**: Main area of expertise needed (technical, market, user, etc.)
|
||||
- **Secondary Domains**: Additional perspectives required
|
||||
- **Specific Expertise**: Particular skills or knowledge areas
|
||||
- **Research Depth**: High-level overview vs deep technical analysis
|
||||
|
||||
#### Output Requirements
|
||||
|
||||
- **Format**: Executive summary, detailed report, comparison matrix, etc.
|
||||
- **Audience**: Who will consume the research results
|
||||
- **Integration**: How results feed into next steps
|
||||
|
|
@ -2373,12 +2636,14 @@ Each Researcher Agent will:
|
|||
### 4. Result Delivery
|
||||
|
||||
#### To Requesting Agent
|
||||
|
||||
- **Executive Summary**: Key findings and recommendations
|
||||
- **Detailed Analysis**: Comprehensive research results
|
||||
- **Source Documentation**: Links and citations for verification
|
||||
- **Next Steps**: Recommended actions or follow-up research
|
||||
|
||||
#### To Research Log
|
||||
|
||||
- **Research Entry**: Concise summary stored in `docs/research/YYYY-MM-DD-research-topic.md`
|
||||
- **Index Update**: Add entry to `docs/research/research-index.md`
|
||||
- **Tag Classification**: Add searchable tags for future reference
|
||||
|
|
@ -2397,40 +2662,40 @@ When executing this task, use this structure for research requests:
|
|||
```yaml
|
||||
research_request:
|
||||
metadata:
|
||||
requesting_agent: "[agent-id]"
|
||||
request_date: "[YYYY-MM-DD]"
|
||||
priority: "[high|medium|low]"
|
||||
timeline: "[timeframe needed]"
|
||||
requesting_agent: '[agent-id]'
|
||||
request_date: '[YYYY-MM-DD]'
|
||||
priority: '[high|medium|low]'
|
||||
timeline: '[timeframe needed]'
|
||||
|
||||
context:
|
||||
project_phase: "[planning|development|validation|etc]"
|
||||
background: "[relevant project context]"
|
||||
related_docs: "[PRD, architecture, stories, etc]"
|
||||
previous_research: "[check research log references]"
|
||||
project_phase: '[planning|development|validation|etc]'
|
||||
background: '[relevant project context]'
|
||||
related_docs: '[PRD, architecture, stories, etc]'
|
||||
previous_research: '[check research log references]'
|
||||
|
||||
objective:
|
||||
primary_goal: "[specific research question]"
|
||||
success_criteria: "[how to measure success]"
|
||||
scope: "[boundaries and limitations]"
|
||||
decision_impact: "[how results will be used]"
|
||||
primary_goal: '[specific research question]'
|
||||
success_criteria: '[how to measure success]'
|
||||
scope: '[boundaries and limitations]'
|
||||
decision_impact: '[how results will be used]'
|
||||
|
||||
specialization:
|
||||
primary_domain: "[technical|market|user|competitive|regulatory|etc]"
|
||||
secondary_domains: "[additional perspectives needed]"
|
||||
specific_expertise: "[particular skills required]"
|
||||
research_depth: "[overview|detailed|comprehensive]"
|
||||
primary_domain: '[technical|market|user|competitive|regulatory|etc]'
|
||||
secondary_domains: '[additional perspectives needed]'
|
||||
specific_expertise: '[particular skills required]'
|
||||
research_depth: '[overview|detailed|comprehensive]'
|
||||
|
||||
team_config:
|
||||
researcher_count: "[1-3, default 3]"
|
||||
perspective_1: "[domain and focus area]"
|
||||
perspective_2: "[domain and focus area]"
|
||||
perspective_3: "[domain and focus area]"
|
||||
researcher_count: '[1-3, default 3]'
|
||||
perspective_1: '[domain and focus area]'
|
||||
perspective_2: '[domain and focus area]'
|
||||
perspective_3: '[domain and focus area]'
|
||||
|
||||
output:
|
||||
format: "[executive_summary|detailed_report|comparison_matrix|etc]"
|
||||
audience: "[who will use results]"
|
||||
integration: "[how results feed into workflow]"
|
||||
citation_level: "[minimal|standard|comprehensive]"
|
||||
format: '[executive_summary|detailed_report|comparison_matrix|etc]'
|
||||
audience: '[who will use results]'
|
||||
integration: '[how results feed into workflow]'
|
||||
citation_level: '[minimal|standard|comprehensive]'
|
||||
```
|
||||
|
||||
## Integration with Existing Agents
|
||||
|
|
@ -2462,26 +2727,32 @@ commands:
|
|||
## Research Log Structure
|
||||
|
||||
### Research Index (`docs/research/research-index.md`)
|
||||
|
||||
```markdown
|
||||
# Research Index
|
||||
|
||||
## Recent Research
|
||||
|
||||
- [2024-01-15: AI Model Comparison](2024-01-15-ai-model-comparison.md) - Technical analysis of LLM options
|
||||
- [2024-01-12: Payment Gateway Analysis](2024-01-12-payment-gateway-analysis.md) - Market comparison of payment solutions
|
||||
|
||||
## Research by Category
|
||||
|
||||
### Technical Research
|
||||
|
||||
- AI/ML Models
|
||||
- Architecture Decisions
|
||||
- Technology Stacks
|
||||
|
||||
### Market Research
|
||||
|
||||
- Competitive Analysis
|
||||
- User Behavior
|
||||
- Industry Trends
|
||||
```
|
||||
|
||||
### Individual Research Files (`docs/research/YYYY-MM-DD-topic.md`)
|
||||
|
||||
```markdown
|
||||
# Research: [Topic]
|
||||
|
||||
|
|
@ -2490,31 +2761,41 @@ commands:
|
|||
**Research Team**: [perspectives used]
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[Key findings and recommendations]
|
||||
|
||||
## Research Objective
|
||||
|
||||
[What was being researched and why]
|
||||
|
||||
## Key Findings
|
||||
|
||||
[Main insights from all perspectives]
|
||||
|
||||
## Recommendations
|
||||
|
||||
[Actionable next steps]
|
||||
|
||||
## Research Team Perspectives
|
||||
|
||||
### Perspective 1: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 2: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 3: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
## Sources and References
|
||||
|
||||
[Credible sources cited by research team]
|
||||
|
||||
## Tags
|
||||
|
||||
[Searchable tags for future reference]
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -229,6 +229,7 @@ commands:
|
|||
- perform-market-research: use task create-doc with market-research-tmpl.yaml
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt.md
|
||||
- gemini-analyze {target}: Analyze large codebases or files using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
|
|
@ -241,6 +242,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- facilitate-brainstorming-session.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- brainstorming-output-tmpl.yaml
|
||||
|
|
@ -295,6 +297,7 @@ commands:
|
|||
- execute-checklist {checklist}: Run task execute-checklist (default->architect-checklist)
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt
|
||||
- gemini-analyze {target}: Analyze large codebases or architectural patterns using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- shard-prd: run the task shard-doc.md for the provided architecture.md (ask if not found)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Architect, and then abandon inhabiting this persona
|
||||
|
|
@ -308,6 +311,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- execute-checklist.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- architecture-tmpl.yaml
|
||||
|
|
@ -360,6 +364,7 @@ commands:
|
|||
- explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
|
||||
- review-qa: run task `apply-qa-fixes.md'
|
||||
- run-tests: Execute linting and tests
|
||||
- gemini-analyze {target}: Analyze large files or debug complex multi-file issues using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
checklists:
|
||||
|
|
@ -367,6 +372,7 @@ dependencies:
|
|||
tasks:
|
||||
- apply-qa-fixes.md
|
||||
- execute-checklist.md
|
||||
- gemini-analysis.md
|
||||
- validate-next-story.md
|
||||
```
|
||||
==================== END: .bmad-core/agents/dev.md ====================
|
||||
|
|
@ -2960,6 +2966,262 @@ Generate structured document with these sections:
|
|||
- Respect their process and timing
|
||||
==================== END: .bmad-core/tasks/facilitate-brainstorming-session.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Gemini Analysis Task
|
||||
|
||||
## Purpose
|
||||
|
||||
This task provides access to Google Gemini CLI's massive context window for analyzing large codebases, big files, or complex multi-file operations that exceed normal context limits. Gemini CLI can handle entire project contexts that would overflow standard AI context windows.
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- **Massive Context Window**: Analyze entire codebases without context limitations
|
||||
- **File & Directory Inclusion**: Use `@` syntax for precise file/directory targeting
|
||||
- **Multi-File Analysis**: Compare and analyze multiple large files simultaneously
|
||||
- **Codebase Flattening**: Alternative to local flattener for large projects
|
||||
- **Feature Verification**: Check if specific features are implemented across entire projects
|
||||
- **Pattern Discovery**: Find patterns, implementations, and architectural decisions project-wide
|
||||
|
||||
## When to Use Gemini Analysis
|
||||
|
||||
### Ideal Use Cases
|
||||
- **Large Codebase Architecture Analysis**: Understanding overall system design
|
||||
- **Multi-File Pattern Searching**: Finding implementations across multiple files
|
||||
- **Feature Implementation Verification**: Checking if features exist project-wide
|
||||
- **Brownfield Project Discovery**: Understanding existing large codebases
|
||||
- **Context-Heavy Debugging**: Analyzing complex interactions across many files
|
||||
- **Comprehensive Code Reviews**: Reviewing entire feature implementations
|
||||
|
||||
### Context Size Triggers
|
||||
- Files or directories totaling >100KB of content
|
||||
- Analysis requiring >20 files simultaneously
|
||||
- Project-wide architectural understanding needed
|
||||
- Current context window insufficient for task
|
||||
|
||||
## Analysis Modes
|
||||
|
||||
### 1. Single File Analysis
|
||||
**Use Case**: Deep analysis of large individual files
|
||||
**Command Pattern**: `gemini "@file/path Analyze this file's structure and purpose"`
|
||||
**Examples**:
|
||||
- `@src/main.py Explain this file's architecture and key patterns`
|
||||
- `@config/webpack.config.js Break down this configuration and its impact`
|
||||
|
||||
### 2. Directory Analysis
|
||||
**Use Case**: Understanding structure and patterns within specific directories
|
||||
**Command Pattern**: `gemini "@directory/ Analyze the architecture of this codebase section"`
|
||||
**Examples**:
|
||||
- `@src/components/ Summarize the component architecture and patterns`
|
||||
- `@api/routes/ Document all API endpoints and their purposes`
|
||||
|
||||
### 3. Multi-Path Analysis
|
||||
**Use Case**: Comparing and analyzing relationships between multiple areas
|
||||
**Command Pattern**: `gemini "@path1 @path2 Analyze relationships between these areas"`
|
||||
**Examples**:
|
||||
- `@src/ @tests/ Analyze test coverage for the source code`
|
||||
- `@frontend/ @backend/ How do these communicate and what are the integration points?`
|
||||
|
||||
### 4. Project Overview
|
||||
**Use Case**: Comprehensive understanding of entire project
|
||||
**Command Pattern**: `gemini --all-files "Provide comprehensive project analysis"`
|
||||
**Examples**:
|
||||
- `--all-files "Give me an architectural overview of this entire project"`
|
||||
- `--all-files "Summarize the technology stack and key architectural decisions"`
|
||||
|
||||
### 5. Feature Verification
|
||||
**Use Case**: Checking if specific features or patterns are implemented
|
||||
**Command Pattern**: `gemini "@codebase/ Has [feature] been implemented? Show relevant files"`
|
||||
**Examples**:
|
||||
- `@src/ @lib/ Has dark mode been implemented? Show relevant files and functions`
|
||||
- `@api/ @middleware/ Is rate limiting implemented? Show the implementation details`
|
||||
|
||||
### 6. Pattern Discovery
|
||||
**Use Case**: Finding specific coding patterns, security measures, or architectural decisions
|
||||
**Command Pattern**: `gemini "@codebase/ Find all instances of [pattern] and list with file paths"`
|
||||
**Examples**:
|
||||
- `@src/ Are there any React hooks that handle WebSocket connections?`
|
||||
- `@backend/ Is proper error handling implemented for all endpoints?`
|
||||
|
||||
## Task Process
|
||||
|
||||
### 1. Analysis Request Processing
|
||||
|
||||
#### Gather Requirements
|
||||
- **Analysis Type**: Which mode fits the user's need?
|
||||
- **Target Paths**: What files/directories should be included?
|
||||
- **Analysis Depth**: High-level overview vs detailed analysis?
|
||||
- **Specific Questions**: What particular aspects to focus on?
|
||||
- **Output Format**: How should results be presented?
|
||||
|
||||
#### Path Validation
|
||||
- **Existence Check**: Verify all specified paths exist
|
||||
- **Size Assessment**: Estimate total content size
|
||||
- **Permission Validation**: Ensure readable access
|
||||
- **Safety Check**: Confirm read-only analysis scope
|
||||
|
||||
### 2. Command Construction
|
||||
|
||||
#### Basic Command Structure
|
||||
```bash
|
||||
gemini [options] "@path1 @path2 [prompt]"
|
||||
```
|
||||
|
||||
#### Option Selection
|
||||
- **Standard Mode**: `gemini "@path prompt"`
|
||||
- **All Files Mode**: `gemini --all-files "prompt"`
|
||||
- **Safe Mode**: `gemini --approval-mode default "@path prompt"`
|
||||
- **Sandbox Mode**: `gemini --sandbox "@path prompt"` (if editing needed)
|
||||
|
||||
#### Path Formatting
|
||||
- **Single File**: `@src/main.py`
|
||||
- **Directory**: `@src/components/`
|
||||
- **Multiple Paths**: `@src/ @tests/ @docs/`
|
||||
- **Current Directory**: `@./`
|
||||
- **Specific Files**: `@package.json @README.md`
|
||||
|
||||
### 3. Safety and Validation
|
||||
|
||||
#### Pre-Execution Checks
|
||||
- **Read-Only Confirmation**: Ensure analysis-only intent
|
||||
- **Path Sanitization**: Validate and clean file paths
|
||||
- **Size Warnings**: Alert for extremely large contexts
|
||||
- **Approval Mode**: Set appropriate safety level
|
||||
|
||||
#### Command Safety Options
|
||||
```yaml
|
||||
safety_levels:
|
||||
read_only: "Default - analysis only, no modifications"
|
||||
default: "Prompt for any file modifications"
|
||||
auto_edit: "Auto-approve edit tools only"
|
||||
sandbox: "Run in safe sandbox environment"
|
||||
```
|
||||
|
||||
### 4. Execution and Results
|
||||
|
||||
#### Command Execution
|
||||
1. **Validate Paths**: Confirm all targets exist and are accessible
|
||||
2. **Construct Command**: Build proper Gemini CLI command
|
||||
3. **Execute Analysis**: Run Gemini CLI with specified parameters
|
||||
4. **Capture Output**: Collect and format analysis results
|
||||
5. **Error Handling**: Manage CLI failures or timeouts
|
||||
|
||||
#### Result Processing
|
||||
- **Output Formatting**: Structure results for readability
|
||||
- **Key Insights Extraction**: Highlight critical findings
|
||||
- **Follow-up Suggestions**: Recommend next steps
|
||||
- **Source Documentation**: Reference analyzed files/paths
|
||||
|
||||
### 5. Integration with BMAD Workflow
|
||||
|
||||
#### Result Documentation
|
||||
- **Store in Project**: Save significant analyses in `docs/analysis/`
|
||||
- **Reference in Stories**: Link analyses to relevant development stories
|
||||
- **Architecture Updates**: Update architecture docs with findings
|
||||
- **Knowledge Preservation**: Maintain analysis artifacts for team reference
|
||||
|
||||
#### Follow-Up Actions
|
||||
- **Story Creation**: Generate development stories from findings
|
||||
- **Architecture Review**: Update architectural documentation
|
||||
- **Technical Debt**: Identify and document technical debt items
|
||||
- **Research Coordination**: Trigger detailed research if needed
|
||||
|
||||
## Command Templates
|
||||
|
||||
### Architecture Analysis
|
||||
```bash
|
||||
# Overall project architecture
|
||||
gemini --all-files "Analyze the overall architecture of this project. Include technology stack, key patterns, and architectural decisions."
|
||||
|
||||
# Specific component architecture
|
||||
gemini "@src/components/ Analyze the component architecture. What patterns are used and how are components organized?"
|
||||
|
||||
# Backend architecture
|
||||
gemini "@api/ @services/ @middleware/ Analyze the backend architecture. How are routes organized and what patterns are used?"
|
||||
```
|
||||
|
||||
### Feature Verification
|
||||
```bash
|
||||
# Authentication implementation
|
||||
gemini "@src/ @api/ Is JWT authentication fully implemented? Show all auth-related files and middleware."
|
||||
|
||||
# Security measures
|
||||
gemini "@src/ @api/ What security measures are implemented? Look for input validation, CORS, rate limiting."
|
||||
|
||||
# Testing coverage
|
||||
gemini "@src/ @tests/ Analyze test coverage. Which areas are well-tested and which need more tests?"
|
||||
```
|
||||
|
||||
### Code Quality Analysis
|
||||
```bash
|
||||
# Error handling patterns
|
||||
gemini "@src/ @api/ How is error handling implemented throughout the codebase? Show examples."
|
||||
|
||||
# Performance considerations
|
||||
gemini "@src/ @lib/ What performance optimizations are in place? Identify potential bottlenecks."
|
||||
|
||||
# Code organization
|
||||
gemini "@src/ How is the code organized? What are the main modules and their responsibilities?"
|
||||
```
|
||||
|
||||
### Technology Assessment
|
||||
```bash
|
||||
# Dependency analysis
|
||||
gemini "@package.json @src/ What are the key dependencies and how are they used in the code?"
|
||||
|
||||
# Build system analysis
|
||||
gemini "@webpack.config.js @package.json @src/ How is the build system configured and what optimizations are in place?"
|
||||
|
||||
# Database integration
|
||||
gemini "@models/ @migrations/ @src/ How is the database integrated? What ORM patterns are used?"
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Issues
|
||||
- **Path Not Found**: Specified files/directories don't exist
|
||||
- **Context Too Large**: Even Gemini's context has limits
|
||||
- **CLI Unavailable**: Gemini CLI not installed or configured
|
||||
- **Permission Denied**: Cannot read specified files
|
||||
- **Command Timeout**: Analysis takes too long to complete
|
||||
|
||||
### Error Recovery
|
||||
- **Path Validation**: Pre-validate all paths before execution
|
||||
- **Graceful Degradation**: Suggest smaller scope if context too large
|
||||
- **Alternative Approaches**: Offer local flattener or partial analysis
|
||||
- **Clear Error Messages**: Provide actionable error information
|
||||
- **Fallback Options**: Suggest manual analysis approaches
|
||||
|
||||
### Safety Measures
|
||||
- **Read-Only Default**: Never modify files without explicit permission
|
||||
- **Approval Prompts**: Confirm any file modifications
|
||||
- **Sandbox Options**: Use sandbox mode for risky operations
|
||||
- **Timeout Protection**: Prevent hanging operations
|
||||
- **Resource Monitoring**: Track memory and processing usage
|
||||
|
||||
## Integration Notes
|
||||
|
||||
### With Existing BMAD Tools
|
||||
- **Flattener Integration**: Use existing flattener for preprocessing when needed
|
||||
- **Research Coordination**: Can trigger research system for follow-up analysis
|
||||
- **Story Generation**: Results can inform story creation
|
||||
- **Architecture Documentation**: Updates architectural understanding
|
||||
|
||||
### With Core Configuration
|
||||
- **Command Templates**: Stored in core-config.yaml for consistency
|
||||
- **Default Settings**: Safety and approval modes configured globally
|
||||
- **Path Patterns**: Common path combinations for different project types
|
||||
- **Integration Points**: How Gemini analysis feeds into BMAD workflow
|
||||
|
||||
### Agent Accessibility
|
||||
All agents with Gemini analysis capability will have access to:
|
||||
- **Standard Analysis**: `*gemini-analyze` command for common patterns
|
||||
- **Custom Queries**: Ability to specify custom analysis prompts
|
||||
- **Result Integration**: Automatic integration with agent workflows
|
||||
- **Safety Controls**: Appropriate safety measures for agent context
|
||||
==================== END: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/request-research.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
|
|
@ -2980,6 +3242,7 @@ This task provides a unified interface for any agent to request specialized rese
|
|||
## Usage Scenarios
|
||||
|
||||
### From Any Agent
|
||||
|
||||
Any agent can call this task to get specialized research assistance:
|
||||
|
||||
```yaml
|
||||
|
|
@ -3001,24 +3264,28 @@ Any agent can call this task to get specialized research assistance:
|
|||
The task will elicit a structured research request with these components:
|
||||
|
||||
#### Research Context
|
||||
|
||||
- **Requesting Agent**: Which agent is making the request
|
||||
- **Project Context**: Current project phase and relevant background
|
||||
- **Previous Research**: Check research log for related prior work
|
||||
- **Urgency Level**: Timeline constraints and priority
|
||||
|
||||
#### Research Objective
|
||||
|
||||
- **Primary Goal**: What specific question or problem needs researching
|
||||
- **Success Criteria**: How to measure if research achieved its objective
|
||||
- **Scope Boundaries**: What to include/exclude from research
|
||||
- **Decision Impact**: How results will be used
|
||||
|
||||
#### Domain Specialization Requirements
|
||||
|
||||
- **Primary Domain**: Main area of expertise needed (technical, market, user, etc.)
|
||||
- **Secondary Domains**: Additional perspectives required
|
||||
- **Specific Expertise**: Particular skills or knowledge areas
|
||||
- **Research Depth**: High-level overview vs deep technical analysis
|
||||
|
||||
#### Output Requirements
|
||||
|
||||
- **Format**: Executive summary, detailed report, comparison matrix, etc.
|
||||
- **Audience**: Who will consume the research results
|
||||
- **Integration**: How results feed into next steps
|
||||
|
|
@ -3047,12 +3314,14 @@ Each Researcher Agent will:
|
|||
### 4. Result Delivery
|
||||
|
||||
#### To Requesting Agent
|
||||
|
||||
- **Executive Summary**: Key findings and recommendations
|
||||
- **Detailed Analysis**: Comprehensive research results
|
||||
- **Source Documentation**: Links and citations for verification
|
||||
- **Next Steps**: Recommended actions or follow-up research
|
||||
|
||||
#### To Research Log
|
||||
|
||||
- **Research Entry**: Concise summary stored in `docs/research/YYYY-MM-DD-research-topic.md`
|
||||
- **Index Update**: Add entry to `docs/research/research-index.md`
|
||||
- **Tag Classification**: Add searchable tags for future reference
|
||||
|
|
@ -3071,40 +3340,40 @@ When executing this task, use this structure for research requests:
|
|||
```yaml
|
||||
research_request:
|
||||
metadata:
|
||||
requesting_agent: "[agent-id]"
|
||||
request_date: "[YYYY-MM-DD]"
|
||||
priority: "[high|medium|low]"
|
||||
timeline: "[timeframe needed]"
|
||||
requesting_agent: '[agent-id]'
|
||||
request_date: '[YYYY-MM-DD]'
|
||||
priority: '[high|medium|low]'
|
||||
timeline: '[timeframe needed]'
|
||||
|
||||
context:
|
||||
project_phase: "[planning|development|validation|etc]"
|
||||
background: "[relevant project context]"
|
||||
related_docs: "[PRD, architecture, stories, etc]"
|
||||
previous_research: "[check research log references]"
|
||||
project_phase: '[planning|development|validation|etc]'
|
||||
background: '[relevant project context]'
|
||||
related_docs: '[PRD, architecture, stories, etc]'
|
||||
previous_research: '[check research log references]'
|
||||
|
||||
objective:
|
||||
primary_goal: "[specific research question]"
|
||||
success_criteria: "[how to measure success]"
|
||||
scope: "[boundaries and limitations]"
|
||||
decision_impact: "[how results will be used]"
|
||||
primary_goal: '[specific research question]'
|
||||
success_criteria: '[how to measure success]'
|
||||
scope: '[boundaries and limitations]'
|
||||
decision_impact: '[how results will be used]'
|
||||
|
||||
specialization:
|
||||
primary_domain: "[technical|market|user|competitive|regulatory|etc]"
|
||||
secondary_domains: "[additional perspectives needed]"
|
||||
specific_expertise: "[particular skills required]"
|
||||
research_depth: "[overview|detailed|comprehensive]"
|
||||
primary_domain: '[technical|market|user|competitive|regulatory|etc]'
|
||||
secondary_domains: '[additional perspectives needed]'
|
||||
specific_expertise: '[particular skills required]'
|
||||
research_depth: '[overview|detailed|comprehensive]'
|
||||
|
||||
team_config:
|
||||
researcher_count: "[1-3, default 3]"
|
||||
perspective_1: "[domain and focus area]"
|
||||
perspective_2: "[domain and focus area]"
|
||||
perspective_3: "[domain and focus area]"
|
||||
researcher_count: '[1-3, default 3]'
|
||||
perspective_1: '[domain and focus area]'
|
||||
perspective_2: '[domain and focus area]'
|
||||
perspective_3: '[domain and focus area]'
|
||||
|
||||
output:
|
||||
format: "[executive_summary|detailed_report|comparison_matrix|etc]"
|
||||
audience: "[who will use results]"
|
||||
integration: "[how results feed into workflow]"
|
||||
citation_level: "[minimal|standard|comprehensive]"
|
||||
format: '[executive_summary|detailed_report|comparison_matrix|etc]'
|
||||
audience: '[who will use results]'
|
||||
integration: '[how results feed into workflow]'
|
||||
citation_level: '[minimal|standard|comprehensive]'
|
||||
```
|
||||
|
||||
## Integration with Existing Agents
|
||||
|
|
@ -3136,26 +3405,32 @@ commands:
|
|||
## Research Log Structure
|
||||
|
||||
### Research Index (`docs/research/research-index.md`)
|
||||
|
||||
```markdown
|
||||
# Research Index
|
||||
|
||||
## Recent Research
|
||||
|
||||
- [2024-01-15: AI Model Comparison](2024-01-15-ai-model-comparison.md) - Technical analysis of LLM options
|
||||
- [2024-01-12: Payment Gateway Analysis](2024-01-12-payment-gateway-analysis.md) - Market comparison of payment solutions
|
||||
|
||||
## Research by Category
|
||||
|
||||
### Technical Research
|
||||
|
||||
- AI/ML Models
|
||||
- Architecture Decisions
|
||||
- Technology Stacks
|
||||
|
||||
### Market Research
|
||||
|
||||
- Competitive Analysis
|
||||
- User Behavior
|
||||
- Industry Trends
|
||||
```
|
||||
|
||||
### Individual Research Files (`docs/research/YYYY-MM-DD-topic.md`)
|
||||
|
||||
```markdown
|
||||
# Research: [Topic]
|
||||
|
||||
|
|
@ -3164,31 +3439,41 @@ commands:
|
|||
**Research Team**: [perspectives used]
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[Key findings and recommendations]
|
||||
|
||||
## Research Objective
|
||||
|
||||
[What was being researched and why]
|
||||
|
||||
## Key Findings
|
||||
|
||||
[Main insights from all perspectives]
|
||||
|
||||
## Recommendations
|
||||
|
||||
[Actionable next steps]
|
||||
|
||||
## Research Team Perspectives
|
||||
|
||||
### Perspective 1: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 2: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 3: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
## Sources and References
|
||||
|
||||
[Credible sources cited by research team]
|
||||
|
||||
## Tags
|
||||
|
||||
[Searchable tags for future reference]
|
||||
```
|
||||
|
||||
|
|
@ -11296,19 +11581,23 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 1. Research Request Intake
|
||||
|
||||
#### Process Incoming Request
|
||||
|
||||
**If called via unified request-research task:**
|
||||
|
||||
- Extract research request YAML structure
|
||||
- Validate all required fields are present
|
||||
- Understand requesting agent context and needs
|
||||
- Assess urgency and timeline constraints
|
||||
|
||||
**If called directly by user/agent:**
|
||||
|
||||
- Elicit research requirements using structured approach
|
||||
- Guide user through research request specification
|
||||
- Ensure clarity on objectives and expected outcomes
|
||||
- Document request in standard format
|
||||
|
||||
#### Critical Elements to Capture
|
||||
|
||||
- **Requesting Agent**: Which agent needs the research
|
||||
- **Research Objective**: Specific question or problem
|
||||
- **Context**: Project phase, background, constraints
|
||||
|
|
@ -11320,6 +11609,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 2. Research Log Analysis
|
||||
|
||||
#### Check for Existing Research
|
||||
|
||||
1. **Search Research Index**: Look for related prior research
|
||||
- Search by topic keywords
|
||||
- Check domain tags and categories
|
||||
|
|
@ -11341,6 +11631,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 3. Research Strategy Design
|
||||
|
||||
#### Multi-Perspective Planning
|
||||
|
||||
1. **Determine Research Team Size**
|
||||
- Default: 3 researchers for comprehensive coverage
|
||||
- Configurable based on complexity and timeline
|
||||
|
|
@ -11353,6 +11644,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
- **Maximize Coverage**: Balance breadth vs depth
|
||||
|
||||
#### Common Research Team Configurations
|
||||
|
||||
- **Technology Assessment**: Technical + Scalability + Security
|
||||
- **Market Analysis**: Market + Competitive + User
|
||||
- **Product Decision**: Technical + Business + User
|
||||
|
|
@ -11362,6 +11654,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 4. Researcher Deployment
|
||||
|
||||
#### Configure Research Teams
|
||||
|
||||
For each researcher agent:
|
||||
|
||||
1. **Specialization Configuration**
|
||||
|
|
@ -11383,28 +11676,31 @@ For each researcher agent:
|
|||
- Quality standards and source requirements
|
||||
|
||||
#### Research Assignment Template
|
||||
|
||||
```yaml
|
||||
researcher_briefing:
|
||||
research_context: "[Context from original request]"
|
||||
assigned_domain: "[Primary specialization]"
|
||||
perspective_focus: "[Specific angle to investigate]"
|
||||
research_questions: "[Domain-specific questions to address]"
|
||||
source_priorities: "[Types of sources to prioritize]"
|
||||
analysis_framework: "[How to analyze information]"
|
||||
coordination_role: "[How this fits with other researchers]"
|
||||
deliverable_format: "[Expected output structure]"
|
||||
timeline: "[Deadlines and checkpoints]"
|
||||
research_context: '[Context from original request]'
|
||||
assigned_domain: '[Primary specialization]'
|
||||
perspective_focus: '[Specific angle to investigate]'
|
||||
research_questions: '[Domain-specific questions to address]'
|
||||
source_priorities: '[Types of sources to prioritize]'
|
||||
analysis_framework: '[How to analyze information]'
|
||||
coordination_role: '[How this fits with other researchers]'
|
||||
deliverable_format: '[Expected output structure]'
|
||||
timeline: '[Deadlines and checkpoints]'
|
||||
```
|
||||
|
||||
### 5. Research Coordination
|
||||
|
||||
#### Monitor Research Progress
|
||||
|
||||
- **Progress Checkpoints**: Regular status updates from researchers
|
||||
- **Quality Review**: Interim assessment of findings quality
|
||||
- **Coordination Adjustments**: Modify approach based on early findings
|
||||
- **Conflict Resolution**: Address disagreements between researchers
|
||||
|
||||
#### Handle Research Challenges
|
||||
|
||||
- **Information Gaps**: Redirect research focus if sources unavailable
|
||||
- **Conflicting Findings**: Document disagreements for synthesis
|
||||
- **Scope Creep**: Keep research focused on original objectives
|
||||
|
|
@ -11413,6 +11709,7 @@ researcher_briefing:
|
|||
### 6. Findings Synthesis
|
||||
|
||||
#### Synthesis Process
|
||||
|
||||
1. **Gather Individual Reports**
|
||||
- Collect findings from each researcher
|
||||
- Review quality and completeness
|
||||
|
|
@ -11432,6 +11729,7 @@ researcher_briefing:
|
|||
- Identify areas needing additional research
|
||||
|
||||
#### Synthesis Output Structure
|
||||
|
||||
Using research-synthesis-tmpl.yaml:
|
||||
|
||||
1. **Executive Summary**: Key insights and recommendations
|
||||
|
|
@ -11445,12 +11743,14 @@ Using research-synthesis-tmpl.yaml:
|
|||
### 7. Delivery and Documentation
|
||||
|
||||
#### Deliver to Requesting Agent
|
||||
|
||||
1. **Primary Deliverable**: Synthesized research report
|
||||
2. **Executive Summary**: Key findings and recommendations
|
||||
3. **Supporting Detail**: Access to full analysis as needed
|
||||
4. **Next Steps**: Recommended actions and follow-up research
|
||||
|
||||
#### Update Research Index
|
||||
|
||||
Using research-log-entry-tmpl.yaml:
|
||||
|
||||
1. **Add Index Entry**: New research to chronological list
|
||||
|
|
@ -11459,6 +11759,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
4. **Cross-References**: Link to related prior research
|
||||
|
||||
#### Store Research Artifacts
|
||||
|
||||
- **Primary Report**: Store in docs/research/ with date-topic filename
|
||||
- **Research Index**: Update research-index.md with new entry
|
||||
- **Source Documentation**: Preserve links and references
|
||||
|
|
@ -11467,6 +11768,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 8. Quality Assurance
|
||||
|
||||
#### Research Quality Checklist
|
||||
|
||||
- **Objective Completion**: All research questions addressed
|
||||
- **Source Credibility**: Reliable, recent, and relevant sources
|
||||
- **Perspective Diversity**: Genuinely different analytical angles
|
||||
|
|
@ -11476,6 +11778,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
- **Uncertainty Documentation**: Limitations and gaps clearly stated
|
||||
|
||||
#### Validation Steps
|
||||
|
||||
1. **Internal Review**: Coordinator validates synthesis quality
|
||||
2. **Source Verification**: Spot-check key sources and evidence
|
||||
3. **Logic Check**: Ensure recommendations follow from findings
|
||||
|
|
@ -11484,12 +11787,14 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 9. Error Handling and Edge Cases
|
||||
|
||||
#### Common Challenges
|
||||
|
||||
- **Researcher Unavailability**: Adjust team size or perspective assignments
|
||||
- **Source Access Issues**: Graceful degradation to available information
|
||||
- **Conflicting Deadlines**: Prioritize critical research elements
|
||||
- **Quality Problems**: Reassign research or adjust scope
|
||||
|
||||
#### Escalation Triggers
|
||||
|
||||
- **Irreconcilable Conflicts**: Major disagreements between researchers
|
||||
- **Missing Critical Information**: Gaps that prevent objective completion
|
||||
- **Quality Failures**: Repeated issues with source credibility or analysis
|
||||
|
|
@ -11498,12 +11803,14 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 10. Continuous Improvement
|
||||
|
||||
#### Research Process Optimization
|
||||
|
||||
- **Track Research Effectiveness**: Monitor how research informs decisions
|
||||
- **Identify Common Patterns**: Frequently requested research types
|
||||
- **Optimize Team Configurations**: Most effective perspective combinations
|
||||
- **Improve Synthesis Quality**: Better integration techniques
|
||||
|
||||
#### Knowledge Base Enhancement
|
||||
|
||||
- **Update Domain Profiles**: Refine specialization descriptions
|
||||
- **Expand Source Directories**: Add new credible source types
|
||||
- **Improve Methodologies**: Better research and analysis frameworks
|
||||
|
|
@ -11532,6 +11839,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
### 1. Search Strategy
|
||||
|
||||
#### Check Research Index
|
||||
|
||||
1. **Load Research Index**: Read `docs/research/research-index.md`
|
||||
2. **Keyword Search**: Search for related terms in:
|
||||
- Research titles and descriptions
|
||||
|
|
@ -11540,6 +11848,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
- Requesting agent information
|
||||
|
||||
#### Search Parameters
|
||||
|
||||
- **Topic Keywords**: Core subject terms from research request
|
||||
- **Domain Tags**: Technical, market, user, competitive, etc.
|
||||
- **Date Range**: Recent research vs historical
|
||||
|
|
@ -11548,6 +11857,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
### 2. Analysis Process
|
||||
|
||||
#### Evaluate Matches
|
||||
|
||||
For each potential match:
|
||||
|
||||
1. **Relevance Assessment**
|
||||
|
|
@ -11568,21 +11878,25 @@ For each potential match:
|
|||
### 3. Output Options
|
||||
|
||||
#### Full Coverage Exists
|
||||
|
||||
- **Recommendation**: Refer to existing research
|
||||
- **Action**: Provide link and summary of relevant findings
|
||||
- **Update Strategy**: Consider if refresh needed due to age
|
||||
|
||||
#### Partial Coverage Available
|
||||
|
||||
- **Recommendation**: Build on existing research
|
||||
- **Action**: Identify specific gaps to focus new research
|
||||
- **Integration Strategy**: How to combine old and new findings
|
||||
|
||||
#### No Relevant Coverage
|
||||
|
||||
- **Recommendation**: Proceed with full research effort
|
||||
- **Action**: Document search results to avoid future confusion
|
||||
- **Baseline**: Use existing research as context background
|
||||
|
||||
#### Outdated Coverage
|
||||
|
||||
- **Recommendation**: Update/refresh existing research
|
||||
- **Action**: Compare current request to prior research scope
|
||||
- **Strategy**: Full refresh vs targeted updates
|
||||
|
|
@ -11590,6 +11904,7 @@ For each potential match:
|
|||
### 4. Documentation
|
||||
|
||||
#### Search Results Summary
|
||||
|
||||
```markdown
|
||||
## Research Log Search Results
|
||||
|
||||
|
|
@ -11598,6 +11913,7 @@ For each potential match:
|
|||
**Matches Found**: [number of potential matches]
|
||||
|
||||
### Relevant Prior Research
|
||||
|
||||
1. **[Research Title]** (Date: YYYY-MM-DD)
|
||||
- **Relevance**: [how closely it matches]
|
||||
- **Coverage**: [what aspects are covered]
|
||||
|
|
@ -11606,6 +11922,7 @@ For each potential match:
|
|||
- **Recommendation**: [use as-is/build-on/refresh/ignore]
|
||||
|
||||
### Search Conclusion
|
||||
|
||||
- **Overall Assessment**: [full/partial/no/outdated coverage]
|
||||
- **Recommended Action**: [refer/build-on/proceed/refresh]
|
||||
- **Integration Strategy**: [how to use prior work]
|
||||
|
|
@ -11614,12 +11931,14 @@ For each potential match:
|
|||
### 5. Integration Recommendations
|
||||
|
||||
#### Building on Prior Research
|
||||
|
||||
- **Reference Strategy**: How to cite and build upon existing work
|
||||
- **Gap Focus**: Specific areas to concentrate new research efforts
|
||||
- **Perspective Additions**: New angles not covered in prior research
|
||||
- **Update Requirements**: Refresh outdated information
|
||||
|
||||
#### Avoiding Duplication
|
||||
|
||||
- **Scope Differentiation**: How current request differs from prior work
|
||||
- **Methodology Variation**: Different research approaches to try
|
||||
- **Source Expansion**: New information sources to explore
|
||||
|
|
@ -11922,6 +12241,7 @@ sections:
|
|||
## Pre-Research Planning
|
||||
|
||||
### Research Objective Clarity
|
||||
|
||||
- [ ] Research objective is specific and measurable
|
||||
- [ ] Success criteria are clearly defined
|
||||
- [ ] Scope boundaries are explicitly stated
|
||||
|
|
@ -11929,6 +12249,7 @@ sections:
|
|||
- [ ] Timeline and priority constraints are documented
|
||||
|
||||
### Research Strategy Design
|
||||
|
||||
- [ ] Multi-perspective approach is appropriate for complexity
|
||||
- [ ] Domain specializations are properly assigned
|
||||
- [ ] Research team size matches scope and timeline
|
||||
|
|
@ -11936,6 +12257,7 @@ sections:
|
|||
- [ ] Research methodologies are appropriate for objectives
|
||||
|
||||
### Prior Research Review
|
||||
|
||||
- [ ] Research log has been searched for related work
|
||||
- [ ] Prior research relevance has been assessed
|
||||
- [ ] Strategy for building on existing work is defined
|
||||
|
|
@ -11944,6 +12266,7 @@ sections:
|
|||
## During Research Execution
|
||||
|
||||
### Source Quality and Credibility
|
||||
|
||||
- [ ] Sources are credible and authoritative
|
||||
- [ ] Information recency is appropriate for topic
|
||||
- [ ] Source diversity provides multiple viewpoints
|
||||
|
|
@ -11951,6 +12274,7 @@ sections:
|
|||
- [ ] Primary sources are prioritized over secondary when available
|
||||
|
||||
### Research Methodology
|
||||
|
||||
- [ ] Research approach is systematic and thorough
|
||||
- [ ] Domain expertise lens is consistently applied
|
||||
- [ ] Web search capabilities are effectively utilized
|
||||
|
|
@ -11958,6 +12282,7 @@ sections:
|
|||
- [ ] Analysis frameworks are appropriate for domain
|
||||
|
||||
### Quality Assurance
|
||||
|
||||
- [ ] Key findings are supported by multiple sources
|
||||
- [ ] Conflicting information is properly documented
|
||||
- [ ] Uncertainty levels are clearly identified
|
||||
|
|
@ -11967,6 +12292,7 @@ sections:
|
|||
## Synthesis and Integration
|
||||
|
||||
### Multi-Perspective Synthesis
|
||||
|
||||
- [ ] Findings from all researchers are properly integrated
|
||||
- [ ] Convergent insights are clearly identified
|
||||
- [ ] Divergent viewpoints are fairly represented
|
||||
|
|
@ -11974,6 +12300,7 @@ sections:
|
|||
- [ ] Gaps requiring additional research are documented
|
||||
|
||||
### Analysis Quality
|
||||
|
||||
- [ ] Key findings directly address research objectives
|
||||
- [ ] Evidence supports conclusions and recommendations
|
||||
- [ ] Limitations and uncertainties are transparently documented
|
||||
|
|
@ -11981,6 +12308,7 @@ sections:
|
|||
- [ ] Recommendations are actionable and specific
|
||||
|
||||
### Documentation Standards
|
||||
|
||||
- [ ] Executive summary captures key insights effectively
|
||||
- [ ] Detailed analysis is well-organized and comprehensive
|
||||
- [ ] Source documentation enables verification
|
||||
|
|
@ -11990,6 +12318,7 @@ sections:
|
|||
## Final Deliverable Review
|
||||
|
||||
### Completeness
|
||||
|
||||
- [ ] All research questions have been addressed
|
||||
- [ ] Success criteria have been met
|
||||
- [ ] Output format matches requestor requirements
|
||||
|
|
@ -11997,6 +12326,7 @@ sections:
|
|||
- [ ] Next steps and follow-up needs are identified
|
||||
|
||||
### Decision Support Quality
|
||||
|
||||
- [ ] Findings directly inform decision-making needs
|
||||
- [ ] Confidence levels help assess decision risk
|
||||
- [ ] Recommendations are prioritized and actionable
|
||||
|
|
@ -12004,6 +12334,7 @@ sections:
|
|||
- [ ] Risk factors and mitigation strategies are provided
|
||||
|
||||
### Integration and Handoff
|
||||
|
||||
- [ ] Results are properly formatted for requesting agent
|
||||
- [ ] Research log has been updated with new entry
|
||||
- [ ] Index categorization is accurate and searchable
|
||||
|
|
@ -12013,6 +12344,7 @@ sections:
|
|||
## Post-Research Evaluation
|
||||
|
||||
### Research Effectiveness
|
||||
|
||||
- [ ] Research objectives were successfully achieved
|
||||
- [ ] Timeline and resource constraints were managed effectively
|
||||
- [ ] Quality standards were maintained throughout process
|
||||
|
|
@ -12020,6 +12352,7 @@ sections:
|
|||
- [ ] Lessons learned are documented for process improvement
|
||||
|
||||
### Knowledge Management
|
||||
|
||||
- [ ] Research artifacts are properly stored and indexed
|
||||
- [ ] Key insights are preserved for future reference
|
||||
- [ ] Research methodology insights can inform future efforts
|
||||
|
|
@ -12029,6 +12362,7 @@ sections:
|
|||
## Quality Escalation Triggers
|
||||
|
||||
### Immediate Review Required
|
||||
|
||||
- [ ] Major conflicts between research perspectives cannot be reconciled
|
||||
- [ ] Key sources are found to be unreliable or biased
|
||||
- [ ] Research scope significantly exceeds original boundaries
|
||||
|
|
@ -12036,6 +12370,7 @@ sections:
|
|||
- [ ] Timeline constraints threaten quality standards
|
||||
|
||||
### Process Improvement Needed
|
||||
|
||||
- [ ] Repeated issues with source credibility or access
|
||||
- [ ] Frequent scope creep or objective changes
|
||||
- [ ] Consistent challenges with perspective coordination
|
||||
|
|
@ -12045,6 +12380,7 @@ sections:
|
|||
## Continuous Improvement
|
||||
|
||||
### Research Process Enhancement
|
||||
|
||||
- [ ] Track research effectiveness and decision impact
|
||||
- [ ] Identify patterns in research requests and optimize approaches
|
||||
- [ ] Refine domain specialization profiles based on experience
|
||||
|
|
@ -12052,6 +12388,7 @@ sections:
|
|||
- [ ] Enhance coordination methods between research perspectives
|
||||
|
||||
### Knowledge Base Development
|
||||
|
||||
- [ ] Update research methodologies based on lessons learned
|
||||
- [ ] Expand credible source directories with new discoveries
|
||||
- [ ] Improve domain expertise profiles with refined specializations
|
||||
|
|
@ -12069,6 +12406,7 @@ sections:
|
|||
### Technical Research Methodologies
|
||||
|
||||
#### Technology Assessment Framework
|
||||
|
||||
- **Capability Analysis**: Feature sets, performance characteristics, scalability limits
|
||||
- **Implementation Evaluation**: Complexity, learning curve, integration requirements
|
||||
- **Ecosystem Assessment**: Community support, documentation quality, maintenance status
|
||||
|
|
@ -12076,6 +12414,7 @@ sections:
|
|||
- **Security Analysis**: Vulnerability assessment, security model evaluation
|
||||
|
||||
#### Technical Source Priorities
|
||||
|
||||
1. **Official Documentation**: Primary source for capabilities and limitations
|
||||
2. **GitHub Repositories**: Code quality, activity level, issue resolution patterns
|
||||
3. **Technical Blogs**: Implementation experiences, best practices, lessons learned
|
||||
|
|
@ -12085,6 +12424,7 @@ sections:
|
|||
### Market Research Methodologies
|
||||
|
||||
#### Market Analysis Framework
|
||||
|
||||
- **Market Sizing**: TAM/SAM/SOM analysis, growth rate assessment
|
||||
- **Competitive Landscape**: Player mapping, market share analysis, positioning
|
||||
- **Customer Segmentation**: Demographics, psychographics, behavioral patterns
|
||||
|
|
@ -12092,6 +12432,7 @@ sections:
|
|||
- **Opportunity Assessment**: Market gaps, underserved segments, entry barriers
|
||||
|
||||
#### Market Source Priorities
|
||||
|
||||
1. **Industry Reports**: Analyst research, market studies, trend analyses
|
||||
2. **Financial Data**: Public company reports, funding announcements, valuations
|
||||
3. **Survey Data**: Customer research, market studies, adoption surveys
|
||||
|
|
@ -12101,6 +12442,7 @@ sections:
|
|||
### User Research Methodologies
|
||||
|
||||
#### User-Centered Research Framework
|
||||
|
||||
- **Behavioral Analysis**: User journey mapping, interaction patterns, pain points
|
||||
- **Needs Assessment**: Jobs-to-be-done analysis, unmet needs identification
|
||||
- **Experience Evaluation**: Usability assessment, satisfaction measurement
|
||||
|
|
@ -12108,6 +12450,7 @@ sections:
|
|||
- **Context Analysis**: Use case scenarios, environmental factors, constraints
|
||||
|
||||
#### User Research Source Priorities
|
||||
|
||||
1. **User Studies**: Direct research, surveys, interviews, focus groups
|
||||
2. **Product Reviews**: Customer feedback, ratings, detailed experiences
|
||||
3. **Social Media**: User discussions, complaints, feature requests
|
||||
|
|
@ -12117,6 +12460,7 @@ sections:
|
|||
### Competitive Research Methodologies
|
||||
|
||||
#### Competitive Intelligence Framework
|
||||
|
||||
- **Feature Comparison**: Capability matrices, feature gap analysis
|
||||
- **Strategic Analysis**: Business model evaluation, positioning assessment
|
||||
- **Performance Benchmarking**: Speed, reliability, user experience comparisons
|
||||
|
|
@ -12124,6 +12468,7 @@ sections:
|
|||
- **Innovation Tracking**: Product roadmaps, patent filings, investment areas
|
||||
|
||||
#### Competitive Source Priorities
|
||||
|
||||
1. **Competitor Websites**: Product information, pricing, positioning messages
|
||||
2. **Product Demos**: Hands-on evaluation, feature testing, user experience
|
||||
3. **Press Releases**: Strategic announcements, product launches, partnerships
|
||||
|
|
@ -12133,6 +12478,7 @@ sections:
|
|||
### Scientific Research Methodologies
|
||||
|
||||
#### Scientific Analysis Framework
|
||||
|
||||
- **Literature Review**: Peer-reviewed research, citation analysis, consensus building
|
||||
- **Methodology Assessment**: Research design quality, statistical validity, reproducibility
|
||||
- **Evidence Evaluation**: Study quality, sample sizes, control factors
|
||||
|
|
@ -12140,6 +12486,7 @@ sections:
|
|||
- **Application Assessment**: Practical implications, implementation feasibility
|
||||
|
||||
#### Scientific Source Priorities
|
||||
|
||||
1. **Peer-Reviewed Journals**: Primary research, systematic reviews, meta-analyses
|
||||
2. **Academic Databases**: Research repositories, citation networks, preprints
|
||||
3. **Conference Proceedings**: Latest research, emerging trends, expert presentations
|
||||
|
|
@ -12151,6 +12498,7 @@ sections:
|
|||
### Source Credibility Assessment
|
||||
|
||||
#### Primary Source Evaluation
|
||||
|
||||
- **Authority**: Expertise of authors, institutional affiliation, credentials
|
||||
- **Accuracy**: Fact-checking, peer review process, error correction mechanisms
|
||||
- **Objectivity**: Bias assessment, funding sources, conflict of interest disclosure
|
||||
|
|
@ -12158,6 +12506,7 @@ sections:
|
|||
- **Coverage**: Scope comprehensiveness, detail level, methodology transparency
|
||||
|
||||
#### Secondary Source Validation
|
||||
|
||||
- **Citation Quality**: Primary source references, citation accuracy, source diversity
|
||||
- **Synthesis Quality**: Analysis depth, logical coherence, balanced perspective
|
||||
- **Author Expertise**: Subject matter knowledge, track record, reputation
|
||||
|
|
@ -12167,6 +12516,7 @@ sections:
|
|||
### Information Synthesis Approaches
|
||||
|
||||
#### Multi-Perspective Integration
|
||||
|
||||
- **Convergence Analysis**: Identify areas where sources agree consistently
|
||||
- **Divergence Documentation**: Note significant disagreements and analyze causes
|
||||
- **Confidence Weighting**: Assign confidence levels based on source quality and consensus
|
||||
|
|
@ -12174,6 +12524,7 @@ sections:
|
|||
- **Uncertainty Quantification**: Document limitations and areas of unclear evidence
|
||||
|
||||
#### Evidence Hierarchy
|
||||
|
||||
1. **High Confidence**: Multiple credible sources, recent information, expert consensus
|
||||
2. **Medium Confidence**: Some credible sources, mixed consensus, moderate currency
|
||||
3. **Low Confidence**: Limited sources, significant disagreement, dated information
|
||||
|
|
@ -12183,6 +12534,7 @@ sections:
|
|||
## Domain-Specific Analysis Frameworks
|
||||
|
||||
### Technical Analysis Framework
|
||||
|
||||
- **Feasibility Assessment**: Technical viability, implementation complexity, resource requirements
|
||||
- **Scalability Analysis**: Performance under load, growth accommodation, architectural limits
|
||||
- **Integration Evaluation**: Compatibility assessment, integration complexity, ecosystem fit
|
||||
|
|
@ -12190,6 +12542,7 @@ sections:
|
|||
- **Risk Assessment**: Technical risks, dependency risks, obsolescence potential
|
||||
|
||||
### Business Analysis Framework
|
||||
|
||||
- **Value Proposition**: Customer value delivery, competitive advantage, market differentiation
|
||||
- **Financial Impact**: Cost analysis, revenue potential, ROI assessment, budget implications
|
||||
- **Strategic Alignment**: Goal consistency, priority alignment, resource allocation fit
|
||||
|
|
@ -12197,6 +12550,7 @@ sections:
|
|||
- **Risk-Benefit Analysis**: Potential rewards vs implementation risks and costs
|
||||
|
||||
### User Impact Framework
|
||||
|
||||
- **User Experience**: Ease of use, learning curve, satisfaction factors, accessibility
|
||||
- **Adoption Factors**: Barriers to adoption, motivation drivers, change management needs
|
||||
- **Value Delivery**: User benefit realization, problem solving effectiveness, outcome achievement
|
||||
|
|
@ -12206,6 +12560,7 @@ sections:
|
|||
## Research Coordination Best Practices
|
||||
|
||||
### Multi-Researcher Coordination
|
||||
|
||||
- **Perspective Assignment**: Clear domain boundaries, minimal overlap, comprehensive coverage
|
||||
- **Communication Protocols**: Regular check-ins, conflict resolution processes, coordination methods
|
||||
- **Quality Standards**: Consistent source credibility requirements, analysis depth expectations
|
||||
|
|
@ -12213,6 +12568,7 @@ sections:
|
|||
- **Integration Planning**: Synthesis approach design, conflict resolution strategies, gap handling
|
||||
|
||||
### Research Efficiency Optimization
|
||||
|
||||
- **Source Sharing**: Avoid duplicate source evaluation across researchers
|
||||
- **Finding Coordination**: Share relevant discoveries between perspectives
|
||||
- **Quality Checks**: Cross-validation of key findings, source verification collaboration
|
||||
|
|
|
|||
|
|
@ -234,6 +234,7 @@ commands:
|
|||
- perform-market-research: use task create-doc with market-research-tmpl.yaml
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt.md
|
||||
- gemini-analyze {target}: Analyze large codebases or files using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
|
|
@ -246,6 +247,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- facilitate-brainstorming-session.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- brainstorming-output-tmpl.yaml
|
||||
|
|
@ -415,6 +417,7 @@ commands:
|
|||
- execute-checklist {checklist}: Run task execute-checklist (default->architect-checklist)
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt
|
||||
- gemini-analyze {target}: Analyze large codebases or architectural patterns using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- shard-prd: run the task shard-doc.md for the provided architecture.md (ask if not found)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Architect, and then abandon inhabiting this persona
|
||||
|
|
@ -428,6 +431,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- execute-checklist.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- architecture-tmpl.yaml
|
||||
|
|
@ -2686,6 +2690,262 @@ Generate structured document with these sections:
|
|||
- Respect their process and timing
|
||||
==================== END: .bmad-core/tasks/facilitate-brainstorming-session.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Gemini Analysis Task
|
||||
|
||||
## Purpose
|
||||
|
||||
This task provides access to Google Gemini CLI's massive context window for analyzing large codebases, big files, or complex multi-file operations that exceed normal context limits. Gemini CLI can handle entire project contexts that would overflow standard AI context windows.
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- **Massive Context Window**: Analyze entire codebases without context limitations
|
||||
- **File & Directory Inclusion**: Use `@` syntax for precise file/directory targeting
|
||||
- **Multi-File Analysis**: Compare and analyze multiple large files simultaneously
|
||||
- **Codebase Flattening**: Alternative to local flattener for large projects
|
||||
- **Feature Verification**: Check if specific features are implemented across entire projects
|
||||
- **Pattern Discovery**: Find patterns, implementations, and architectural decisions project-wide
|
||||
|
||||
## When to Use Gemini Analysis
|
||||
|
||||
### Ideal Use Cases
|
||||
- **Large Codebase Architecture Analysis**: Understanding overall system design
|
||||
- **Multi-File Pattern Searching**: Finding implementations across multiple files
|
||||
- **Feature Implementation Verification**: Checking if features exist project-wide
|
||||
- **Brownfield Project Discovery**: Understanding existing large codebases
|
||||
- **Context-Heavy Debugging**: Analyzing complex interactions across many files
|
||||
- **Comprehensive Code Reviews**: Reviewing entire feature implementations
|
||||
|
||||
### Context Size Triggers
|
||||
- Files or directories totaling >100KB of content
|
||||
- Analysis requiring >20 files simultaneously
|
||||
- Project-wide architectural understanding needed
|
||||
- Current context window insufficient for task
|
||||
|
||||
## Analysis Modes
|
||||
|
||||
### 1. Single File Analysis
|
||||
**Use Case**: Deep analysis of large individual files
|
||||
**Command Pattern**: `gemini "@file/path Analyze this file's structure and purpose"`
|
||||
**Examples**:
|
||||
- `@src/main.py Explain this file's architecture and key patterns`
|
||||
- `@config/webpack.config.js Break down this configuration and its impact`
|
||||
|
||||
### 2. Directory Analysis
|
||||
**Use Case**: Understanding structure and patterns within specific directories
|
||||
**Command Pattern**: `gemini "@directory/ Analyze the architecture of this codebase section"`
|
||||
**Examples**:
|
||||
- `@src/components/ Summarize the component architecture and patterns`
|
||||
- `@api/routes/ Document all API endpoints and their purposes`
|
||||
|
||||
### 3. Multi-Path Analysis
|
||||
**Use Case**: Comparing and analyzing relationships between multiple areas
|
||||
**Command Pattern**: `gemini "@path1 @path2 Analyze relationships between these areas"`
|
||||
**Examples**:
|
||||
- `@src/ @tests/ Analyze test coverage for the source code`
|
||||
- `@frontend/ @backend/ How do these communicate and what are the integration points?`
|
||||
|
||||
### 4. Project Overview
|
||||
**Use Case**: Comprehensive understanding of entire project
|
||||
**Command Pattern**: `gemini --all-files "Provide comprehensive project analysis"`
|
||||
**Examples**:
|
||||
- `--all-files "Give me an architectural overview of this entire project"`
|
||||
- `--all-files "Summarize the technology stack and key architectural decisions"`
|
||||
|
||||
### 5. Feature Verification
|
||||
**Use Case**: Checking if specific features or patterns are implemented
|
||||
**Command Pattern**: `gemini "@codebase/ Has [feature] been implemented? Show relevant files"`
|
||||
**Examples**:
|
||||
- `@src/ @lib/ Has dark mode been implemented? Show relevant files and functions`
|
||||
- `@api/ @middleware/ Is rate limiting implemented? Show the implementation details`
|
||||
|
||||
### 6. Pattern Discovery
|
||||
**Use Case**: Finding specific coding patterns, security measures, or architectural decisions
|
||||
**Command Pattern**: `gemini "@codebase/ Find all instances of [pattern] and list with file paths"`
|
||||
**Examples**:
|
||||
- `@src/ Are there any React hooks that handle WebSocket connections?`
|
||||
- `@backend/ Is proper error handling implemented for all endpoints?`
|
||||
|
||||
## Task Process
|
||||
|
||||
### 1. Analysis Request Processing
|
||||
|
||||
#### Gather Requirements
|
||||
- **Analysis Type**: Which mode fits the user's need?
|
||||
- **Target Paths**: What files/directories should be included?
|
||||
- **Analysis Depth**: High-level overview vs detailed analysis?
|
||||
- **Specific Questions**: What particular aspects to focus on?
|
||||
- **Output Format**: How should results be presented?
|
||||
|
||||
#### Path Validation
|
||||
- **Existence Check**: Verify all specified paths exist
|
||||
- **Size Assessment**: Estimate total content size
|
||||
- **Permission Validation**: Ensure readable access
|
||||
- **Safety Check**: Confirm read-only analysis scope
|
||||
|
||||
### 2. Command Construction
|
||||
|
||||
#### Basic Command Structure
|
||||
```bash
|
||||
gemini [options] "@path1 @path2 [prompt]"
|
||||
```
|
||||
|
||||
#### Option Selection
|
||||
- **Standard Mode**: `gemini "@path prompt"`
|
||||
- **All Files Mode**: `gemini --all-files "prompt"`
|
||||
- **Safe Mode**: `gemini --approval-mode default "@path prompt"`
|
||||
- **Sandbox Mode**: `gemini --sandbox "@path prompt"` (if editing needed)
|
||||
|
||||
#### Path Formatting
|
||||
- **Single File**: `@src/main.py`
|
||||
- **Directory**: `@src/components/`
|
||||
- **Multiple Paths**: `@src/ @tests/ @docs/`
|
||||
- **Current Directory**: `@./`
|
||||
- **Specific Files**: `@package.json @README.md`
|
||||
|
||||
### 3. Safety and Validation
|
||||
|
||||
#### Pre-Execution Checks
|
||||
- **Read-Only Confirmation**: Ensure analysis-only intent
|
||||
- **Path Sanitization**: Validate and clean file paths
|
||||
- **Size Warnings**: Alert for extremely large contexts
|
||||
- **Approval Mode**: Set appropriate safety level
|
||||
|
||||
#### Command Safety Options
|
||||
```yaml
|
||||
safety_levels:
|
||||
read_only: "Default - analysis only, no modifications"
|
||||
default: "Prompt for any file modifications"
|
||||
auto_edit: "Auto-approve edit tools only"
|
||||
sandbox: "Run in safe sandbox environment"
|
||||
```
|
||||
|
||||
### 4. Execution and Results
|
||||
|
||||
#### Command Execution
|
||||
1. **Validate Paths**: Confirm all targets exist and are accessible
|
||||
2. **Construct Command**: Build proper Gemini CLI command
|
||||
3. **Execute Analysis**: Run Gemini CLI with specified parameters
|
||||
4. **Capture Output**: Collect and format analysis results
|
||||
5. **Error Handling**: Manage CLI failures or timeouts
|
||||
|
||||
#### Result Processing
|
||||
- **Output Formatting**: Structure results for readability
|
||||
- **Key Insights Extraction**: Highlight critical findings
|
||||
- **Follow-up Suggestions**: Recommend next steps
|
||||
- **Source Documentation**: Reference analyzed files/paths
|
||||
|
||||
### 5. Integration with BMAD Workflow
|
||||
|
||||
#### Result Documentation
|
||||
- **Store in Project**: Save significant analyses in `docs/analysis/`
|
||||
- **Reference in Stories**: Link analyses to relevant development stories
|
||||
- **Architecture Updates**: Update architecture docs with findings
|
||||
- **Knowledge Preservation**: Maintain analysis artifacts for team reference
|
||||
|
||||
#### Follow-Up Actions
|
||||
- **Story Creation**: Generate development stories from findings
|
||||
- **Architecture Review**: Update architectural documentation
|
||||
- **Technical Debt**: Identify and document technical debt items
|
||||
- **Research Coordination**: Trigger detailed research if needed
|
||||
|
||||
## Command Templates
|
||||
|
||||
### Architecture Analysis
|
||||
```bash
|
||||
# Overall project architecture
|
||||
gemini --all-files "Analyze the overall architecture of this project. Include technology stack, key patterns, and architectural decisions."
|
||||
|
||||
# Specific component architecture
|
||||
gemini "@src/components/ Analyze the component architecture. What patterns are used and how are components organized?"
|
||||
|
||||
# Backend architecture
|
||||
gemini "@api/ @services/ @middleware/ Analyze the backend architecture. How are routes organized and what patterns are used?"
|
||||
```
|
||||
|
||||
### Feature Verification
|
||||
```bash
|
||||
# Authentication implementation
|
||||
gemini "@src/ @api/ Is JWT authentication fully implemented? Show all auth-related files and middleware."
|
||||
|
||||
# Security measures
|
||||
gemini "@src/ @api/ What security measures are implemented? Look for input validation, CORS, rate limiting."
|
||||
|
||||
# Testing coverage
|
||||
gemini "@src/ @tests/ Analyze test coverage. Which areas are well-tested and which need more tests?"
|
||||
```
|
||||
|
||||
### Code Quality Analysis
|
||||
```bash
|
||||
# Error handling patterns
|
||||
gemini "@src/ @api/ How is error handling implemented throughout the codebase? Show examples."
|
||||
|
||||
# Performance considerations
|
||||
gemini "@src/ @lib/ What performance optimizations are in place? Identify potential bottlenecks."
|
||||
|
||||
# Code organization
|
||||
gemini "@src/ How is the code organized? What are the main modules and their responsibilities?"
|
||||
```
|
||||
|
||||
### Technology Assessment
|
||||
```bash
|
||||
# Dependency analysis
|
||||
gemini "@package.json @src/ What are the key dependencies and how are they used in the code?"
|
||||
|
||||
# Build system analysis
|
||||
gemini "@webpack.config.js @package.json @src/ How is the build system configured and what optimizations are in place?"
|
||||
|
||||
# Database integration
|
||||
gemini "@models/ @migrations/ @src/ How is the database integrated? What ORM patterns are used?"
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Issues
|
||||
- **Path Not Found**: Specified files/directories don't exist
|
||||
- **Context Too Large**: Even Gemini's context has limits
|
||||
- **CLI Unavailable**: Gemini CLI not installed or configured
|
||||
- **Permission Denied**: Cannot read specified files
|
||||
- **Command Timeout**: Analysis takes too long to complete
|
||||
|
||||
### Error Recovery
|
||||
- **Path Validation**: Pre-validate all paths before execution
|
||||
- **Graceful Degradation**: Suggest smaller scope if context too large
|
||||
- **Alternative Approaches**: Offer local flattener or partial analysis
|
||||
- **Clear Error Messages**: Provide actionable error information
|
||||
- **Fallback Options**: Suggest manual analysis approaches
|
||||
|
||||
### Safety Measures
|
||||
- **Read-Only Default**: Never modify files without explicit permission
|
||||
- **Approval Prompts**: Confirm any file modifications
|
||||
- **Sandbox Options**: Use sandbox mode for risky operations
|
||||
- **Timeout Protection**: Prevent hanging operations
|
||||
- **Resource Monitoring**: Track memory and processing usage
|
||||
|
||||
## Integration Notes
|
||||
|
||||
### With Existing BMAD Tools
|
||||
- **Flattener Integration**: Use existing flattener for preprocessing when needed
|
||||
- **Research Coordination**: Can trigger research system for follow-up analysis
|
||||
- **Story Generation**: Results can inform story creation
|
||||
- **Architecture Documentation**: Updates architectural understanding
|
||||
|
||||
### With Core Configuration
|
||||
- **Command Templates**: Stored in core-config.yaml for consistency
|
||||
- **Default Settings**: Safety and approval modes configured globally
|
||||
- **Path Patterns**: Common path combinations for different project types
|
||||
- **Integration Points**: How Gemini analysis feeds into BMAD workflow
|
||||
|
||||
### Agent Accessibility
|
||||
All agents with Gemini analysis capability will have access to:
|
||||
- **Standard Analysis**: `*gemini-analyze` command for common patterns
|
||||
- **Custom Queries**: Ability to specify custom analysis prompts
|
||||
- **Result Integration**: Automatic integration with agent workflows
|
||||
- **Safety Controls**: Appropriate safety measures for agent context
|
||||
==================== END: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/request-research.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
|
|
@ -2706,6 +2966,7 @@ This task provides a unified interface for any agent to request specialized rese
|
|||
## Usage Scenarios
|
||||
|
||||
### From Any Agent
|
||||
|
||||
Any agent can call this task to get specialized research assistance:
|
||||
|
||||
```yaml
|
||||
|
|
@ -2727,24 +2988,28 @@ Any agent can call this task to get specialized research assistance:
|
|||
The task will elicit a structured research request with these components:
|
||||
|
||||
#### Research Context
|
||||
|
||||
- **Requesting Agent**: Which agent is making the request
|
||||
- **Project Context**: Current project phase and relevant background
|
||||
- **Previous Research**: Check research log for related prior work
|
||||
- **Urgency Level**: Timeline constraints and priority
|
||||
|
||||
#### Research Objective
|
||||
|
||||
- **Primary Goal**: What specific question or problem needs researching
|
||||
- **Success Criteria**: How to measure if research achieved its objective
|
||||
- **Scope Boundaries**: What to include/exclude from research
|
||||
- **Decision Impact**: How results will be used
|
||||
|
||||
#### Domain Specialization Requirements
|
||||
|
||||
- **Primary Domain**: Main area of expertise needed (technical, market, user, etc.)
|
||||
- **Secondary Domains**: Additional perspectives required
|
||||
- **Specific Expertise**: Particular skills or knowledge areas
|
||||
- **Research Depth**: High-level overview vs deep technical analysis
|
||||
|
||||
#### Output Requirements
|
||||
|
||||
- **Format**: Executive summary, detailed report, comparison matrix, etc.
|
||||
- **Audience**: Who will consume the research results
|
||||
- **Integration**: How results feed into next steps
|
||||
|
|
@ -2773,12 +3038,14 @@ Each Researcher Agent will:
|
|||
### 4. Result Delivery
|
||||
|
||||
#### To Requesting Agent
|
||||
|
||||
- **Executive Summary**: Key findings and recommendations
|
||||
- **Detailed Analysis**: Comprehensive research results
|
||||
- **Source Documentation**: Links and citations for verification
|
||||
- **Next Steps**: Recommended actions or follow-up research
|
||||
|
||||
#### To Research Log
|
||||
|
||||
- **Research Entry**: Concise summary stored in `docs/research/YYYY-MM-DD-research-topic.md`
|
||||
- **Index Update**: Add entry to `docs/research/research-index.md`
|
||||
- **Tag Classification**: Add searchable tags for future reference
|
||||
|
|
@ -2797,40 +3064,40 @@ When executing this task, use this structure for research requests:
|
|||
```yaml
|
||||
research_request:
|
||||
metadata:
|
||||
requesting_agent: "[agent-id]"
|
||||
request_date: "[YYYY-MM-DD]"
|
||||
priority: "[high|medium|low]"
|
||||
timeline: "[timeframe needed]"
|
||||
requesting_agent: '[agent-id]'
|
||||
request_date: '[YYYY-MM-DD]'
|
||||
priority: '[high|medium|low]'
|
||||
timeline: '[timeframe needed]'
|
||||
|
||||
context:
|
||||
project_phase: "[planning|development|validation|etc]"
|
||||
background: "[relevant project context]"
|
||||
related_docs: "[PRD, architecture, stories, etc]"
|
||||
previous_research: "[check research log references]"
|
||||
project_phase: '[planning|development|validation|etc]'
|
||||
background: '[relevant project context]'
|
||||
related_docs: '[PRD, architecture, stories, etc]'
|
||||
previous_research: '[check research log references]'
|
||||
|
||||
objective:
|
||||
primary_goal: "[specific research question]"
|
||||
success_criteria: "[how to measure success]"
|
||||
scope: "[boundaries and limitations]"
|
||||
decision_impact: "[how results will be used]"
|
||||
primary_goal: '[specific research question]'
|
||||
success_criteria: '[how to measure success]'
|
||||
scope: '[boundaries and limitations]'
|
||||
decision_impact: '[how results will be used]'
|
||||
|
||||
specialization:
|
||||
primary_domain: "[technical|market|user|competitive|regulatory|etc]"
|
||||
secondary_domains: "[additional perspectives needed]"
|
||||
specific_expertise: "[particular skills required]"
|
||||
research_depth: "[overview|detailed|comprehensive]"
|
||||
primary_domain: '[technical|market|user|competitive|regulatory|etc]'
|
||||
secondary_domains: '[additional perspectives needed]'
|
||||
specific_expertise: '[particular skills required]'
|
||||
research_depth: '[overview|detailed|comprehensive]'
|
||||
|
||||
team_config:
|
||||
researcher_count: "[1-3, default 3]"
|
||||
perspective_1: "[domain and focus area]"
|
||||
perspective_2: "[domain and focus area]"
|
||||
perspective_3: "[domain and focus area]"
|
||||
researcher_count: '[1-3, default 3]'
|
||||
perspective_1: '[domain and focus area]'
|
||||
perspective_2: '[domain and focus area]'
|
||||
perspective_3: '[domain and focus area]'
|
||||
|
||||
output:
|
||||
format: "[executive_summary|detailed_report|comparison_matrix|etc]"
|
||||
audience: "[who will use results]"
|
||||
integration: "[how results feed into workflow]"
|
||||
citation_level: "[minimal|standard|comprehensive]"
|
||||
format: '[executive_summary|detailed_report|comparison_matrix|etc]'
|
||||
audience: '[who will use results]'
|
||||
integration: '[how results feed into workflow]'
|
||||
citation_level: '[minimal|standard|comprehensive]'
|
||||
```
|
||||
|
||||
## Integration with Existing Agents
|
||||
|
|
@ -2862,26 +3129,32 @@ commands:
|
|||
## Research Log Structure
|
||||
|
||||
### Research Index (`docs/research/research-index.md`)
|
||||
|
||||
```markdown
|
||||
# Research Index
|
||||
|
||||
## Recent Research
|
||||
|
||||
- [2024-01-15: AI Model Comparison](2024-01-15-ai-model-comparison.md) - Technical analysis of LLM options
|
||||
- [2024-01-12: Payment Gateway Analysis](2024-01-12-payment-gateway-analysis.md) - Market comparison of payment solutions
|
||||
|
||||
## Research by Category
|
||||
|
||||
### Technical Research
|
||||
|
||||
- AI/ML Models
|
||||
- Architecture Decisions
|
||||
- Technology Stacks
|
||||
|
||||
### Market Research
|
||||
|
||||
- Competitive Analysis
|
||||
- User Behavior
|
||||
- Industry Trends
|
||||
```
|
||||
|
||||
### Individual Research Files (`docs/research/YYYY-MM-DD-topic.md`)
|
||||
|
||||
```markdown
|
||||
# Research: [Topic]
|
||||
|
||||
|
|
@ -2890,31 +3163,41 @@ commands:
|
|||
**Research Team**: [perspectives used]
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[Key findings and recommendations]
|
||||
|
||||
## Research Objective
|
||||
|
||||
[What was being researched and why]
|
||||
|
||||
## Key Findings
|
||||
|
||||
[Main insights from all perspectives]
|
||||
|
||||
## Recommendations
|
||||
|
||||
[Actionable next steps]
|
||||
|
||||
## Research Team Perspectives
|
||||
|
||||
### Perspective 1: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 2: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 3: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
## Sources and References
|
||||
|
||||
[Credible sources cited by research team]
|
||||
|
||||
## Tags
|
||||
|
||||
[Searchable tags for future reference]
|
||||
```
|
||||
|
||||
|
|
@ -9434,19 +9717,23 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 1. Research Request Intake
|
||||
|
||||
#### Process Incoming Request
|
||||
|
||||
**If called via unified request-research task:**
|
||||
|
||||
- Extract research request YAML structure
|
||||
- Validate all required fields are present
|
||||
- Understand requesting agent context and needs
|
||||
- Assess urgency and timeline constraints
|
||||
|
||||
**If called directly by user/agent:**
|
||||
|
||||
- Elicit research requirements using structured approach
|
||||
- Guide user through research request specification
|
||||
- Ensure clarity on objectives and expected outcomes
|
||||
- Document request in standard format
|
||||
|
||||
#### Critical Elements to Capture
|
||||
|
||||
- **Requesting Agent**: Which agent needs the research
|
||||
- **Research Objective**: Specific question or problem
|
||||
- **Context**: Project phase, background, constraints
|
||||
|
|
@ -9458,6 +9745,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 2. Research Log Analysis
|
||||
|
||||
#### Check for Existing Research
|
||||
|
||||
1. **Search Research Index**: Look for related prior research
|
||||
- Search by topic keywords
|
||||
- Check domain tags and categories
|
||||
|
|
@ -9479,6 +9767,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 3. Research Strategy Design
|
||||
|
||||
#### Multi-Perspective Planning
|
||||
|
||||
1. **Determine Research Team Size**
|
||||
- Default: 3 researchers for comprehensive coverage
|
||||
- Configurable based on complexity and timeline
|
||||
|
|
@ -9491,6 +9780,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
- **Maximize Coverage**: Balance breadth vs depth
|
||||
|
||||
#### Common Research Team Configurations
|
||||
|
||||
- **Technology Assessment**: Technical + Scalability + Security
|
||||
- **Market Analysis**: Market + Competitive + User
|
||||
- **Product Decision**: Technical + Business + User
|
||||
|
|
@ -9500,6 +9790,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 4. Researcher Deployment
|
||||
|
||||
#### Configure Research Teams
|
||||
|
||||
For each researcher agent:
|
||||
|
||||
1. **Specialization Configuration**
|
||||
|
|
@ -9521,28 +9812,31 @@ For each researcher agent:
|
|||
- Quality standards and source requirements
|
||||
|
||||
#### Research Assignment Template
|
||||
|
||||
```yaml
|
||||
researcher_briefing:
|
||||
research_context: "[Context from original request]"
|
||||
assigned_domain: "[Primary specialization]"
|
||||
perspective_focus: "[Specific angle to investigate]"
|
||||
research_questions: "[Domain-specific questions to address]"
|
||||
source_priorities: "[Types of sources to prioritize]"
|
||||
analysis_framework: "[How to analyze information]"
|
||||
coordination_role: "[How this fits with other researchers]"
|
||||
deliverable_format: "[Expected output structure]"
|
||||
timeline: "[Deadlines and checkpoints]"
|
||||
research_context: '[Context from original request]'
|
||||
assigned_domain: '[Primary specialization]'
|
||||
perspective_focus: '[Specific angle to investigate]'
|
||||
research_questions: '[Domain-specific questions to address]'
|
||||
source_priorities: '[Types of sources to prioritize]'
|
||||
analysis_framework: '[How to analyze information]'
|
||||
coordination_role: '[How this fits with other researchers]'
|
||||
deliverable_format: '[Expected output structure]'
|
||||
timeline: '[Deadlines and checkpoints]'
|
||||
```
|
||||
|
||||
### 5. Research Coordination
|
||||
|
||||
#### Monitor Research Progress
|
||||
|
||||
- **Progress Checkpoints**: Regular status updates from researchers
|
||||
- **Quality Review**: Interim assessment of findings quality
|
||||
- **Coordination Adjustments**: Modify approach based on early findings
|
||||
- **Conflict Resolution**: Address disagreements between researchers
|
||||
|
||||
#### Handle Research Challenges
|
||||
|
||||
- **Information Gaps**: Redirect research focus if sources unavailable
|
||||
- **Conflicting Findings**: Document disagreements for synthesis
|
||||
- **Scope Creep**: Keep research focused on original objectives
|
||||
|
|
@ -9551,6 +9845,7 @@ researcher_briefing:
|
|||
### 6. Findings Synthesis
|
||||
|
||||
#### Synthesis Process
|
||||
|
||||
1. **Gather Individual Reports**
|
||||
- Collect findings from each researcher
|
||||
- Review quality and completeness
|
||||
|
|
@ -9570,6 +9865,7 @@ researcher_briefing:
|
|||
- Identify areas needing additional research
|
||||
|
||||
#### Synthesis Output Structure
|
||||
|
||||
Using research-synthesis-tmpl.yaml:
|
||||
|
||||
1. **Executive Summary**: Key insights and recommendations
|
||||
|
|
@ -9583,12 +9879,14 @@ Using research-synthesis-tmpl.yaml:
|
|||
### 7. Delivery and Documentation
|
||||
|
||||
#### Deliver to Requesting Agent
|
||||
|
||||
1. **Primary Deliverable**: Synthesized research report
|
||||
2. **Executive Summary**: Key findings and recommendations
|
||||
3. **Supporting Detail**: Access to full analysis as needed
|
||||
4. **Next Steps**: Recommended actions and follow-up research
|
||||
|
||||
#### Update Research Index
|
||||
|
||||
Using research-log-entry-tmpl.yaml:
|
||||
|
||||
1. **Add Index Entry**: New research to chronological list
|
||||
|
|
@ -9597,6 +9895,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
4. **Cross-References**: Link to related prior research
|
||||
|
||||
#### Store Research Artifacts
|
||||
|
||||
- **Primary Report**: Store in docs/research/ with date-topic filename
|
||||
- **Research Index**: Update research-index.md with new entry
|
||||
- **Source Documentation**: Preserve links and references
|
||||
|
|
@ -9605,6 +9904,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 8. Quality Assurance
|
||||
|
||||
#### Research Quality Checklist
|
||||
|
||||
- **Objective Completion**: All research questions addressed
|
||||
- **Source Credibility**: Reliable, recent, and relevant sources
|
||||
- **Perspective Diversity**: Genuinely different analytical angles
|
||||
|
|
@ -9614,6 +9914,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
- **Uncertainty Documentation**: Limitations and gaps clearly stated
|
||||
|
||||
#### Validation Steps
|
||||
|
||||
1. **Internal Review**: Coordinator validates synthesis quality
|
||||
2. **Source Verification**: Spot-check key sources and evidence
|
||||
3. **Logic Check**: Ensure recommendations follow from findings
|
||||
|
|
@ -9622,12 +9923,14 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 9. Error Handling and Edge Cases
|
||||
|
||||
#### Common Challenges
|
||||
|
||||
- **Researcher Unavailability**: Adjust team size or perspective assignments
|
||||
- **Source Access Issues**: Graceful degradation to available information
|
||||
- **Conflicting Deadlines**: Prioritize critical research elements
|
||||
- **Quality Problems**: Reassign research or adjust scope
|
||||
|
||||
#### Escalation Triggers
|
||||
|
||||
- **Irreconcilable Conflicts**: Major disagreements between researchers
|
||||
- **Missing Critical Information**: Gaps that prevent objective completion
|
||||
- **Quality Failures**: Repeated issues with source credibility or analysis
|
||||
|
|
@ -9636,12 +9939,14 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 10. Continuous Improvement
|
||||
|
||||
#### Research Process Optimization
|
||||
|
||||
- **Track Research Effectiveness**: Monitor how research informs decisions
|
||||
- **Identify Common Patterns**: Frequently requested research types
|
||||
- **Optimize Team Configurations**: Most effective perspective combinations
|
||||
- **Improve Synthesis Quality**: Better integration techniques
|
||||
|
||||
#### Knowledge Base Enhancement
|
||||
|
||||
- **Update Domain Profiles**: Refine specialization descriptions
|
||||
- **Expand Source Directories**: Add new credible source types
|
||||
- **Improve Methodologies**: Better research and analysis frameworks
|
||||
|
|
@ -9670,6 +9975,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
### 1. Search Strategy
|
||||
|
||||
#### Check Research Index
|
||||
|
||||
1. **Load Research Index**: Read `docs/research/research-index.md`
|
||||
2. **Keyword Search**: Search for related terms in:
|
||||
- Research titles and descriptions
|
||||
|
|
@ -9678,6 +9984,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
- Requesting agent information
|
||||
|
||||
#### Search Parameters
|
||||
|
||||
- **Topic Keywords**: Core subject terms from research request
|
||||
- **Domain Tags**: Technical, market, user, competitive, etc.
|
||||
- **Date Range**: Recent research vs historical
|
||||
|
|
@ -9686,6 +9993,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
### 2. Analysis Process
|
||||
|
||||
#### Evaluate Matches
|
||||
|
||||
For each potential match:
|
||||
|
||||
1. **Relevance Assessment**
|
||||
|
|
@ -9706,21 +10014,25 @@ For each potential match:
|
|||
### 3. Output Options
|
||||
|
||||
#### Full Coverage Exists
|
||||
|
||||
- **Recommendation**: Refer to existing research
|
||||
- **Action**: Provide link and summary of relevant findings
|
||||
- **Update Strategy**: Consider if refresh needed due to age
|
||||
|
||||
#### Partial Coverage Available
|
||||
|
||||
- **Recommendation**: Build on existing research
|
||||
- **Action**: Identify specific gaps to focus new research
|
||||
- **Integration Strategy**: How to combine old and new findings
|
||||
|
||||
#### No Relevant Coverage
|
||||
|
||||
- **Recommendation**: Proceed with full research effort
|
||||
- **Action**: Document search results to avoid future confusion
|
||||
- **Baseline**: Use existing research as context background
|
||||
|
||||
#### Outdated Coverage
|
||||
|
||||
- **Recommendation**: Update/refresh existing research
|
||||
- **Action**: Compare current request to prior research scope
|
||||
- **Strategy**: Full refresh vs targeted updates
|
||||
|
|
@ -9728,6 +10040,7 @@ For each potential match:
|
|||
### 4. Documentation
|
||||
|
||||
#### Search Results Summary
|
||||
|
||||
```markdown
|
||||
## Research Log Search Results
|
||||
|
||||
|
|
@ -9736,6 +10049,7 @@ For each potential match:
|
|||
**Matches Found**: [number of potential matches]
|
||||
|
||||
### Relevant Prior Research
|
||||
|
||||
1. **[Research Title]** (Date: YYYY-MM-DD)
|
||||
- **Relevance**: [how closely it matches]
|
||||
- **Coverage**: [what aspects are covered]
|
||||
|
|
@ -9744,6 +10058,7 @@ For each potential match:
|
|||
- **Recommendation**: [use as-is/build-on/refresh/ignore]
|
||||
|
||||
### Search Conclusion
|
||||
|
||||
- **Overall Assessment**: [full/partial/no/outdated coverage]
|
||||
- **Recommended Action**: [refer/build-on/proceed/refresh]
|
||||
- **Integration Strategy**: [how to use prior work]
|
||||
|
|
@ -9752,12 +10067,14 @@ For each potential match:
|
|||
### 5. Integration Recommendations
|
||||
|
||||
#### Building on Prior Research
|
||||
|
||||
- **Reference Strategy**: How to cite and build upon existing work
|
||||
- **Gap Focus**: Specific areas to concentrate new research efforts
|
||||
- **Perspective Additions**: New angles not covered in prior research
|
||||
- **Update Requirements**: Refresh outdated information
|
||||
|
||||
#### Avoiding Duplication
|
||||
|
||||
- **Scope Differentiation**: How current request differs from prior work
|
||||
- **Methodology Variation**: Different research approaches to try
|
||||
- **Source Expansion**: New information sources to explore
|
||||
|
|
@ -10060,6 +10377,7 @@ sections:
|
|||
## Pre-Research Planning
|
||||
|
||||
### Research Objective Clarity
|
||||
|
||||
- [ ] Research objective is specific and measurable
|
||||
- [ ] Success criteria are clearly defined
|
||||
- [ ] Scope boundaries are explicitly stated
|
||||
|
|
@ -10067,6 +10385,7 @@ sections:
|
|||
- [ ] Timeline and priority constraints are documented
|
||||
|
||||
### Research Strategy Design
|
||||
|
||||
- [ ] Multi-perspective approach is appropriate for complexity
|
||||
- [ ] Domain specializations are properly assigned
|
||||
- [ ] Research team size matches scope and timeline
|
||||
|
|
@ -10074,6 +10393,7 @@ sections:
|
|||
- [ ] Research methodologies are appropriate for objectives
|
||||
|
||||
### Prior Research Review
|
||||
|
||||
- [ ] Research log has been searched for related work
|
||||
- [ ] Prior research relevance has been assessed
|
||||
- [ ] Strategy for building on existing work is defined
|
||||
|
|
@ -10082,6 +10402,7 @@ sections:
|
|||
## During Research Execution
|
||||
|
||||
### Source Quality and Credibility
|
||||
|
||||
- [ ] Sources are credible and authoritative
|
||||
- [ ] Information recency is appropriate for topic
|
||||
- [ ] Source diversity provides multiple viewpoints
|
||||
|
|
@ -10089,6 +10410,7 @@ sections:
|
|||
- [ ] Primary sources are prioritized over secondary when available
|
||||
|
||||
### Research Methodology
|
||||
|
||||
- [ ] Research approach is systematic and thorough
|
||||
- [ ] Domain expertise lens is consistently applied
|
||||
- [ ] Web search capabilities are effectively utilized
|
||||
|
|
@ -10096,6 +10418,7 @@ sections:
|
|||
- [ ] Analysis frameworks are appropriate for domain
|
||||
|
||||
### Quality Assurance
|
||||
|
||||
- [ ] Key findings are supported by multiple sources
|
||||
- [ ] Conflicting information is properly documented
|
||||
- [ ] Uncertainty levels are clearly identified
|
||||
|
|
@ -10105,6 +10428,7 @@ sections:
|
|||
## Synthesis and Integration
|
||||
|
||||
### Multi-Perspective Synthesis
|
||||
|
||||
- [ ] Findings from all researchers are properly integrated
|
||||
- [ ] Convergent insights are clearly identified
|
||||
- [ ] Divergent viewpoints are fairly represented
|
||||
|
|
@ -10112,6 +10436,7 @@ sections:
|
|||
- [ ] Gaps requiring additional research are documented
|
||||
|
||||
### Analysis Quality
|
||||
|
||||
- [ ] Key findings directly address research objectives
|
||||
- [ ] Evidence supports conclusions and recommendations
|
||||
- [ ] Limitations and uncertainties are transparently documented
|
||||
|
|
@ -10119,6 +10444,7 @@ sections:
|
|||
- [ ] Recommendations are actionable and specific
|
||||
|
||||
### Documentation Standards
|
||||
|
||||
- [ ] Executive summary captures key insights effectively
|
||||
- [ ] Detailed analysis is well-organized and comprehensive
|
||||
- [ ] Source documentation enables verification
|
||||
|
|
@ -10128,6 +10454,7 @@ sections:
|
|||
## Final Deliverable Review
|
||||
|
||||
### Completeness
|
||||
|
||||
- [ ] All research questions have been addressed
|
||||
- [ ] Success criteria have been met
|
||||
- [ ] Output format matches requestor requirements
|
||||
|
|
@ -10135,6 +10462,7 @@ sections:
|
|||
- [ ] Next steps and follow-up needs are identified
|
||||
|
||||
### Decision Support Quality
|
||||
|
||||
- [ ] Findings directly inform decision-making needs
|
||||
- [ ] Confidence levels help assess decision risk
|
||||
- [ ] Recommendations are prioritized and actionable
|
||||
|
|
@ -10142,6 +10470,7 @@ sections:
|
|||
- [ ] Risk factors and mitigation strategies are provided
|
||||
|
||||
### Integration and Handoff
|
||||
|
||||
- [ ] Results are properly formatted for requesting agent
|
||||
- [ ] Research log has been updated with new entry
|
||||
- [ ] Index categorization is accurate and searchable
|
||||
|
|
@ -10151,6 +10480,7 @@ sections:
|
|||
## Post-Research Evaluation
|
||||
|
||||
### Research Effectiveness
|
||||
|
||||
- [ ] Research objectives were successfully achieved
|
||||
- [ ] Timeline and resource constraints were managed effectively
|
||||
- [ ] Quality standards were maintained throughout process
|
||||
|
|
@ -10158,6 +10488,7 @@ sections:
|
|||
- [ ] Lessons learned are documented for process improvement
|
||||
|
||||
### Knowledge Management
|
||||
|
||||
- [ ] Research artifacts are properly stored and indexed
|
||||
- [ ] Key insights are preserved for future reference
|
||||
- [ ] Research methodology insights can inform future efforts
|
||||
|
|
@ -10167,6 +10498,7 @@ sections:
|
|||
## Quality Escalation Triggers
|
||||
|
||||
### Immediate Review Required
|
||||
|
||||
- [ ] Major conflicts between research perspectives cannot be reconciled
|
||||
- [ ] Key sources are found to be unreliable or biased
|
||||
- [ ] Research scope significantly exceeds original boundaries
|
||||
|
|
@ -10174,6 +10506,7 @@ sections:
|
|||
- [ ] Timeline constraints threaten quality standards
|
||||
|
||||
### Process Improvement Needed
|
||||
|
||||
- [ ] Repeated issues with source credibility or access
|
||||
- [ ] Frequent scope creep or objective changes
|
||||
- [ ] Consistent challenges with perspective coordination
|
||||
|
|
@ -10183,6 +10516,7 @@ sections:
|
|||
## Continuous Improvement
|
||||
|
||||
### Research Process Enhancement
|
||||
|
||||
- [ ] Track research effectiveness and decision impact
|
||||
- [ ] Identify patterns in research requests and optimize approaches
|
||||
- [ ] Refine domain specialization profiles based on experience
|
||||
|
|
@ -10190,6 +10524,7 @@ sections:
|
|||
- [ ] Enhance coordination methods between research perspectives
|
||||
|
||||
### Knowledge Base Development
|
||||
|
||||
- [ ] Update research methodologies based on lessons learned
|
||||
- [ ] Expand credible source directories with new discoveries
|
||||
- [ ] Improve domain expertise profiles with refined specializations
|
||||
|
|
@ -10207,6 +10542,7 @@ sections:
|
|||
### Technical Research Methodologies
|
||||
|
||||
#### Technology Assessment Framework
|
||||
|
||||
- **Capability Analysis**: Feature sets, performance characteristics, scalability limits
|
||||
- **Implementation Evaluation**: Complexity, learning curve, integration requirements
|
||||
- **Ecosystem Assessment**: Community support, documentation quality, maintenance status
|
||||
|
|
@ -10214,6 +10550,7 @@ sections:
|
|||
- **Security Analysis**: Vulnerability assessment, security model evaluation
|
||||
|
||||
#### Technical Source Priorities
|
||||
|
||||
1. **Official Documentation**: Primary source for capabilities and limitations
|
||||
2. **GitHub Repositories**: Code quality, activity level, issue resolution patterns
|
||||
3. **Technical Blogs**: Implementation experiences, best practices, lessons learned
|
||||
|
|
@ -10223,6 +10560,7 @@ sections:
|
|||
### Market Research Methodologies
|
||||
|
||||
#### Market Analysis Framework
|
||||
|
||||
- **Market Sizing**: TAM/SAM/SOM analysis, growth rate assessment
|
||||
- **Competitive Landscape**: Player mapping, market share analysis, positioning
|
||||
- **Customer Segmentation**: Demographics, psychographics, behavioral patterns
|
||||
|
|
@ -10230,6 +10568,7 @@ sections:
|
|||
- **Opportunity Assessment**: Market gaps, underserved segments, entry barriers
|
||||
|
||||
#### Market Source Priorities
|
||||
|
||||
1. **Industry Reports**: Analyst research, market studies, trend analyses
|
||||
2. **Financial Data**: Public company reports, funding announcements, valuations
|
||||
3. **Survey Data**: Customer research, market studies, adoption surveys
|
||||
|
|
@ -10239,6 +10578,7 @@ sections:
|
|||
### User Research Methodologies
|
||||
|
||||
#### User-Centered Research Framework
|
||||
|
||||
- **Behavioral Analysis**: User journey mapping, interaction patterns, pain points
|
||||
- **Needs Assessment**: Jobs-to-be-done analysis, unmet needs identification
|
||||
- **Experience Evaluation**: Usability assessment, satisfaction measurement
|
||||
|
|
@ -10246,6 +10586,7 @@ sections:
|
|||
- **Context Analysis**: Use case scenarios, environmental factors, constraints
|
||||
|
||||
#### User Research Source Priorities
|
||||
|
||||
1. **User Studies**: Direct research, surveys, interviews, focus groups
|
||||
2. **Product Reviews**: Customer feedback, ratings, detailed experiences
|
||||
3. **Social Media**: User discussions, complaints, feature requests
|
||||
|
|
@ -10255,6 +10596,7 @@ sections:
|
|||
### Competitive Research Methodologies
|
||||
|
||||
#### Competitive Intelligence Framework
|
||||
|
||||
- **Feature Comparison**: Capability matrices, feature gap analysis
|
||||
- **Strategic Analysis**: Business model evaluation, positioning assessment
|
||||
- **Performance Benchmarking**: Speed, reliability, user experience comparisons
|
||||
|
|
@ -10262,6 +10604,7 @@ sections:
|
|||
- **Innovation Tracking**: Product roadmaps, patent filings, investment areas
|
||||
|
||||
#### Competitive Source Priorities
|
||||
|
||||
1. **Competitor Websites**: Product information, pricing, positioning messages
|
||||
2. **Product Demos**: Hands-on evaluation, feature testing, user experience
|
||||
3. **Press Releases**: Strategic announcements, product launches, partnerships
|
||||
|
|
@ -10271,6 +10614,7 @@ sections:
|
|||
### Scientific Research Methodologies
|
||||
|
||||
#### Scientific Analysis Framework
|
||||
|
||||
- **Literature Review**: Peer-reviewed research, citation analysis, consensus building
|
||||
- **Methodology Assessment**: Research design quality, statistical validity, reproducibility
|
||||
- **Evidence Evaluation**: Study quality, sample sizes, control factors
|
||||
|
|
@ -10278,6 +10622,7 @@ sections:
|
|||
- **Application Assessment**: Practical implications, implementation feasibility
|
||||
|
||||
#### Scientific Source Priorities
|
||||
|
||||
1. **Peer-Reviewed Journals**: Primary research, systematic reviews, meta-analyses
|
||||
2. **Academic Databases**: Research repositories, citation networks, preprints
|
||||
3. **Conference Proceedings**: Latest research, emerging trends, expert presentations
|
||||
|
|
@ -10289,6 +10634,7 @@ sections:
|
|||
### Source Credibility Assessment
|
||||
|
||||
#### Primary Source Evaluation
|
||||
|
||||
- **Authority**: Expertise of authors, institutional affiliation, credentials
|
||||
- **Accuracy**: Fact-checking, peer review process, error correction mechanisms
|
||||
- **Objectivity**: Bias assessment, funding sources, conflict of interest disclosure
|
||||
|
|
@ -10296,6 +10642,7 @@ sections:
|
|||
- **Coverage**: Scope comprehensiveness, detail level, methodology transparency
|
||||
|
||||
#### Secondary Source Validation
|
||||
|
||||
- **Citation Quality**: Primary source references, citation accuracy, source diversity
|
||||
- **Synthesis Quality**: Analysis depth, logical coherence, balanced perspective
|
||||
- **Author Expertise**: Subject matter knowledge, track record, reputation
|
||||
|
|
@ -10305,6 +10652,7 @@ sections:
|
|||
### Information Synthesis Approaches
|
||||
|
||||
#### Multi-Perspective Integration
|
||||
|
||||
- **Convergence Analysis**: Identify areas where sources agree consistently
|
||||
- **Divergence Documentation**: Note significant disagreements and analyze causes
|
||||
- **Confidence Weighting**: Assign confidence levels based on source quality and consensus
|
||||
|
|
@ -10312,6 +10660,7 @@ sections:
|
|||
- **Uncertainty Quantification**: Document limitations and areas of unclear evidence
|
||||
|
||||
#### Evidence Hierarchy
|
||||
|
||||
1. **High Confidence**: Multiple credible sources, recent information, expert consensus
|
||||
2. **Medium Confidence**: Some credible sources, mixed consensus, moderate currency
|
||||
3. **Low Confidence**: Limited sources, significant disagreement, dated information
|
||||
|
|
@ -10321,6 +10670,7 @@ sections:
|
|||
## Domain-Specific Analysis Frameworks
|
||||
|
||||
### Technical Analysis Framework
|
||||
|
||||
- **Feasibility Assessment**: Technical viability, implementation complexity, resource requirements
|
||||
- **Scalability Analysis**: Performance under load, growth accommodation, architectural limits
|
||||
- **Integration Evaluation**: Compatibility assessment, integration complexity, ecosystem fit
|
||||
|
|
@ -10328,6 +10678,7 @@ sections:
|
|||
- **Risk Assessment**: Technical risks, dependency risks, obsolescence potential
|
||||
|
||||
### Business Analysis Framework
|
||||
|
||||
- **Value Proposition**: Customer value delivery, competitive advantage, market differentiation
|
||||
- **Financial Impact**: Cost analysis, revenue potential, ROI assessment, budget implications
|
||||
- **Strategic Alignment**: Goal consistency, priority alignment, resource allocation fit
|
||||
|
|
@ -10335,6 +10686,7 @@ sections:
|
|||
- **Risk-Benefit Analysis**: Potential rewards vs implementation risks and costs
|
||||
|
||||
### User Impact Framework
|
||||
|
||||
- **User Experience**: Ease of use, learning curve, satisfaction factors, accessibility
|
||||
- **Adoption Factors**: Barriers to adoption, motivation drivers, change management needs
|
||||
- **Value Delivery**: User benefit realization, problem solving effectiveness, outcome achievement
|
||||
|
|
@ -10344,6 +10696,7 @@ sections:
|
|||
## Research Coordination Best Practices
|
||||
|
||||
### Multi-Researcher Coordination
|
||||
|
||||
- **Perspective Assignment**: Clear domain boundaries, minimal overlap, comprehensive coverage
|
||||
- **Communication Protocols**: Regular check-ins, conflict resolution processes, coordination methods
|
||||
- **Quality Standards**: Consistent source credibility requirements, analysis depth expectations
|
||||
|
|
@ -10351,6 +10704,7 @@ sections:
|
|||
- **Integration Planning**: Synthesis approach design, conflict resolution strategies, gap handling
|
||||
|
||||
### Research Efficiency Optimization
|
||||
|
||||
- **Source Sharing**: Avoid duplicate source evaluation across researchers
|
||||
- **Finding Coordination**: Share relevant discoveries between perspectives
|
||||
- **Quality Checks**: Cross-validation of key findings, source verification collaboration
|
||||
|
|
|
|||
File diff suppressed because it is too large
Load Diff
|
|
@ -327,6 +327,7 @@ commands:
|
|||
- explain: teach me what and why you did whatever you just did in detail so I can learn. Explain to me as if you were training a junior engineer.
|
||||
- review-qa: run task `apply-qa-fixes.md'
|
||||
- run-tests: Execute linting and tests
|
||||
- gemini-analyze {target}: Analyze large files or debug complex multi-file issues using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- exit: Say goodbye as the Developer, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
checklists:
|
||||
|
|
@ -334,6 +335,7 @@ dependencies:
|
|||
tasks:
|
||||
- apply-qa-fixes.md
|
||||
- execute-checklist.md
|
||||
- gemini-analysis.md
|
||||
- validate-next-story.md
|
||||
```
|
||||
==================== END: .bmad-core/agents/dev.md ====================
|
||||
|
|
@ -3446,6 +3448,262 @@ Fix plan:
|
|||
- Gate ownership remains with QA; Dev signals readiness via Status
|
||||
==================== END: .bmad-core/tasks/apply-qa-fixes.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Gemini Analysis Task
|
||||
|
||||
## Purpose
|
||||
|
||||
This task provides access to Google Gemini CLI's massive context window for analyzing large codebases, big files, or complex multi-file operations that exceed normal context limits. Gemini CLI can handle entire project contexts that would overflow standard AI context windows.
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- **Massive Context Window**: Analyze entire codebases without context limitations
|
||||
- **File & Directory Inclusion**: Use `@` syntax for precise file/directory targeting
|
||||
- **Multi-File Analysis**: Compare and analyze multiple large files simultaneously
|
||||
- **Codebase Flattening**: Alternative to local flattener for large projects
|
||||
- **Feature Verification**: Check if specific features are implemented across entire projects
|
||||
- **Pattern Discovery**: Find patterns, implementations, and architectural decisions project-wide
|
||||
|
||||
## When to Use Gemini Analysis
|
||||
|
||||
### Ideal Use Cases
|
||||
- **Large Codebase Architecture Analysis**: Understanding overall system design
|
||||
- **Multi-File Pattern Searching**: Finding implementations across multiple files
|
||||
- **Feature Implementation Verification**: Checking if features exist project-wide
|
||||
- **Brownfield Project Discovery**: Understanding existing large codebases
|
||||
- **Context-Heavy Debugging**: Analyzing complex interactions across many files
|
||||
- **Comprehensive Code Reviews**: Reviewing entire feature implementations
|
||||
|
||||
### Context Size Triggers
|
||||
- Files or directories totaling >100KB of content
|
||||
- Analysis requiring >20 files simultaneously
|
||||
- Project-wide architectural understanding needed
|
||||
- Current context window insufficient for task
|
||||
|
||||
## Analysis Modes
|
||||
|
||||
### 1. Single File Analysis
|
||||
**Use Case**: Deep analysis of large individual files
|
||||
**Command Pattern**: `gemini "@file/path Analyze this file's structure and purpose"`
|
||||
**Examples**:
|
||||
- `@src/main.py Explain this file's architecture and key patterns`
|
||||
- `@config/webpack.config.js Break down this configuration and its impact`
|
||||
|
||||
### 2. Directory Analysis
|
||||
**Use Case**: Understanding structure and patterns within specific directories
|
||||
**Command Pattern**: `gemini "@directory/ Analyze the architecture of this codebase section"`
|
||||
**Examples**:
|
||||
- `@src/components/ Summarize the component architecture and patterns`
|
||||
- `@api/routes/ Document all API endpoints and their purposes`
|
||||
|
||||
### 3. Multi-Path Analysis
|
||||
**Use Case**: Comparing and analyzing relationships between multiple areas
|
||||
**Command Pattern**: `gemini "@path1 @path2 Analyze relationships between these areas"`
|
||||
**Examples**:
|
||||
- `@src/ @tests/ Analyze test coverage for the source code`
|
||||
- `@frontend/ @backend/ How do these communicate and what are the integration points?`
|
||||
|
||||
### 4. Project Overview
|
||||
**Use Case**: Comprehensive understanding of entire project
|
||||
**Command Pattern**: `gemini --all-files "Provide comprehensive project analysis"`
|
||||
**Examples**:
|
||||
- `--all-files "Give me an architectural overview of this entire project"`
|
||||
- `--all-files "Summarize the technology stack and key architectural decisions"`
|
||||
|
||||
### 5. Feature Verification
|
||||
**Use Case**: Checking if specific features or patterns are implemented
|
||||
**Command Pattern**: `gemini "@codebase/ Has [feature] been implemented? Show relevant files"`
|
||||
**Examples**:
|
||||
- `@src/ @lib/ Has dark mode been implemented? Show relevant files and functions`
|
||||
- `@api/ @middleware/ Is rate limiting implemented? Show the implementation details`
|
||||
|
||||
### 6. Pattern Discovery
|
||||
**Use Case**: Finding specific coding patterns, security measures, or architectural decisions
|
||||
**Command Pattern**: `gemini "@codebase/ Find all instances of [pattern] and list with file paths"`
|
||||
**Examples**:
|
||||
- `@src/ Are there any React hooks that handle WebSocket connections?`
|
||||
- `@backend/ Is proper error handling implemented for all endpoints?`
|
||||
|
||||
## Task Process
|
||||
|
||||
### 1. Analysis Request Processing
|
||||
|
||||
#### Gather Requirements
|
||||
- **Analysis Type**: Which mode fits the user's need?
|
||||
- **Target Paths**: What files/directories should be included?
|
||||
- **Analysis Depth**: High-level overview vs detailed analysis?
|
||||
- **Specific Questions**: What particular aspects to focus on?
|
||||
- **Output Format**: How should results be presented?
|
||||
|
||||
#### Path Validation
|
||||
- **Existence Check**: Verify all specified paths exist
|
||||
- **Size Assessment**: Estimate total content size
|
||||
- **Permission Validation**: Ensure readable access
|
||||
- **Safety Check**: Confirm read-only analysis scope
|
||||
|
||||
### 2. Command Construction
|
||||
|
||||
#### Basic Command Structure
|
||||
```bash
|
||||
gemini [options] "@path1 @path2 [prompt]"
|
||||
```
|
||||
|
||||
#### Option Selection
|
||||
- **Standard Mode**: `gemini "@path prompt"`
|
||||
- **All Files Mode**: `gemini --all-files "prompt"`
|
||||
- **Safe Mode**: `gemini --approval-mode default "@path prompt"`
|
||||
- **Sandbox Mode**: `gemini --sandbox "@path prompt"` (if editing needed)
|
||||
|
||||
#### Path Formatting
|
||||
- **Single File**: `@src/main.py`
|
||||
- **Directory**: `@src/components/`
|
||||
- **Multiple Paths**: `@src/ @tests/ @docs/`
|
||||
- **Current Directory**: `@./`
|
||||
- **Specific Files**: `@package.json @README.md`
|
||||
|
||||
### 3. Safety and Validation
|
||||
|
||||
#### Pre-Execution Checks
|
||||
- **Read-Only Confirmation**: Ensure analysis-only intent
|
||||
- **Path Sanitization**: Validate and clean file paths
|
||||
- **Size Warnings**: Alert for extremely large contexts
|
||||
- **Approval Mode**: Set appropriate safety level
|
||||
|
||||
#### Command Safety Options
|
||||
```yaml
|
||||
safety_levels:
|
||||
read_only: "Default - analysis only, no modifications"
|
||||
default: "Prompt for any file modifications"
|
||||
auto_edit: "Auto-approve edit tools only"
|
||||
sandbox: "Run in safe sandbox environment"
|
||||
```
|
||||
|
||||
### 4. Execution and Results
|
||||
|
||||
#### Command Execution
|
||||
1. **Validate Paths**: Confirm all targets exist and are accessible
|
||||
2. **Construct Command**: Build proper Gemini CLI command
|
||||
3. **Execute Analysis**: Run Gemini CLI with specified parameters
|
||||
4. **Capture Output**: Collect and format analysis results
|
||||
5. **Error Handling**: Manage CLI failures or timeouts
|
||||
|
||||
#### Result Processing
|
||||
- **Output Formatting**: Structure results for readability
|
||||
- **Key Insights Extraction**: Highlight critical findings
|
||||
- **Follow-up Suggestions**: Recommend next steps
|
||||
- **Source Documentation**: Reference analyzed files/paths
|
||||
|
||||
### 5. Integration with BMAD Workflow
|
||||
|
||||
#### Result Documentation
|
||||
- **Store in Project**: Save significant analyses in `docs/analysis/`
|
||||
- **Reference in Stories**: Link analyses to relevant development stories
|
||||
- **Architecture Updates**: Update architecture docs with findings
|
||||
- **Knowledge Preservation**: Maintain analysis artifacts for team reference
|
||||
|
||||
#### Follow-Up Actions
|
||||
- **Story Creation**: Generate development stories from findings
|
||||
- **Architecture Review**: Update architectural documentation
|
||||
- **Technical Debt**: Identify and document technical debt items
|
||||
- **Research Coordination**: Trigger detailed research if needed
|
||||
|
||||
## Command Templates
|
||||
|
||||
### Architecture Analysis
|
||||
```bash
|
||||
# Overall project architecture
|
||||
gemini --all-files "Analyze the overall architecture of this project. Include technology stack, key patterns, and architectural decisions."
|
||||
|
||||
# Specific component architecture
|
||||
gemini "@src/components/ Analyze the component architecture. What patterns are used and how are components organized?"
|
||||
|
||||
# Backend architecture
|
||||
gemini "@api/ @services/ @middleware/ Analyze the backend architecture. How are routes organized and what patterns are used?"
|
||||
```
|
||||
|
||||
### Feature Verification
|
||||
```bash
|
||||
# Authentication implementation
|
||||
gemini "@src/ @api/ Is JWT authentication fully implemented? Show all auth-related files and middleware."
|
||||
|
||||
# Security measures
|
||||
gemini "@src/ @api/ What security measures are implemented? Look for input validation, CORS, rate limiting."
|
||||
|
||||
# Testing coverage
|
||||
gemini "@src/ @tests/ Analyze test coverage. Which areas are well-tested and which need more tests?"
|
||||
```
|
||||
|
||||
### Code Quality Analysis
|
||||
```bash
|
||||
# Error handling patterns
|
||||
gemini "@src/ @api/ How is error handling implemented throughout the codebase? Show examples."
|
||||
|
||||
# Performance considerations
|
||||
gemini "@src/ @lib/ What performance optimizations are in place? Identify potential bottlenecks."
|
||||
|
||||
# Code organization
|
||||
gemini "@src/ How is the code organized? What are the main modules and their responsibilities?"
|
||||
```
|
||||
|
||||
### Technology Assessment
|
||||
```bash
|
||||
# Dependency analysis
|
||||
gemini "@package.json @src/ What are the key dependencies and how are they used in the code?"
|
||||
|
||||
# Build system analysis
|
||||
gemini "@webpack.config.js @package.json @src/ How is the build system configured and what optimizations are in place?"
|
||||
|
||||
# Database integration
|
||||
gemini "@models/ @migrations/ @src/ How is the database integrated? What ORM patterns are used?"
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Issues
|
||||
- **Path Not Found**: Specified files/directories don't exist
|
||||
- **Context Too Large**: Even Gemini's context has limits
|
||||
- **CLI Unavailable**: Gemini CLI not installed or configured
|
||||
- **Permission Denied**: Cannot read specified files
|
||||
- **Command Timeout**: Analysis takes too long to complete
|
||||
|
||||
### Error Recovery
|
||||
- **Path Validation**: Pre-validate all paths before execution
|
||||
- **Graceful Degradation**: Suggest smaller scope if context too large
|
||||
- **Alternative Approaches**: Offer local flattener or partial analysis
|
||||
- **Clear Error Messages**: Provide actionable error information
|
||||
- **Fallback Options**: Suggest manual analysis approaches
|
||||
|
||||
### Safety Measures
|
||||
- **Read-Only Default**: Never modify files without explicit permission
|
||||
- **Approval Prompts**: Confirm any file modifications
|
||||
- **Sandbox Options**: Use sandbox mode for risky operations
|
||||
- **Timeout Protection**: Prevent hanging operations
|
||||
- **Resource Monitoring**: Track memory and processing usage
|
||||
|
||||
## Integration Notes
|
||||
|
||||
### With Existing BMAD Tools
|
||||
- **Flattener Integration**: Use existing flattener for preprocessing when needed
|
||||
- **Research Coordination**: Can trigger research system for follow-up analysis
|
||||
- **Story Generation**: Results can inform story creation
|
||||
- **Architecture Documentation**: Updates architectural understanding
|
||||
|
||||
### With Core Configuration
|
||||
- **Command Templates**: Stored in core-config.yaml for consistency
|
||||
- **Default Settings**: Safety and approval modes configured globally
|
||||
- **Path Patterns**: Common path combinations for different project types
|
||||
- **Integration Points**: How Gemini analysis feeds into BMAD workflow
|
||||
|
||||
### Agent Accessibility
|
||||
All agents with Gemini analysis capability will have access to:
|
||||
- **Standard Analysis**: `*gemini-analyze` command for common patterns
|
||||
- **Custom Queries**: Ability to specify custom analysis prompts
|
||||
- **Result Integration**: Automatic integration with agent workflows
|
||||
- **Safety Controls**: Appropriate safety measures for agent context
|
||||
==================== END: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
|
||||
==================== START: .bmad-core/checklists/story-dod-checklist.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
|
|
|
|||
|
|
@ -228,6 +228,7 @@ commands:
|
|||
- perform-market-research: use task create-doc with market-research-tmpl.yaml
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt.md
|
||||
- gemini-analyze {target}: Analyze large codebases or files using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Business Analyst, and then abandon inhabiting this persona
|
||||
dependencies:
|
||||
|
|
@ -240,6 +241,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- facilitate-brainstorming-session.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- brainstorming-output-tmpl.yaml
|
||||
|
|
@ -360,6 +362,7 @@ commands:
|
|||
- execute-checklist {checklist}: Run task execute-checklist (default->architect-checklist)
|
||||
- research {topic}: Request specialized research analysis using task request-research
|
||||
- research-prompt {topic}: execute task create-deep-research-prompt
|
||||
- gemini-analyze {target}: Analyze large codebases or architectural patterns using Gemini CLI massive context (task gemini-analysis.md)
|
||||
- shard-prd: run the task shard-doc.md for the provided architecture.md (ask if not found)
|
||||
- yolo: Toggle Yolo Mode
|
||||
- exit: Say goodbye as the Architect, and then abandon inhabiting this persona
|
||||
|
|
@ -373,6 +376,7 @@ dependencies:
|
|||
- create-doc.md
|
||||
- document-project.md
|
||||
- execute-checklist.md
|
||||
- gemini-analysis.md
|
||||
- request-research.md
|
||||
templates:
|
||||
- architecture-tmpl.yaml
|
||||
|
|
@ -2566,6 +2570,262 @@ Generate structured document with these sections:
|
|||
- Respect their process and timing
|
||||
==================== END: .bmad-core/tasks/facilitate-brainstorming-session.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Gemini Analysis Task
|
||||
|
||||
## Purpose
|
||||
|
||||
This task provides access to Google Gemini CLI's massive context window for analyzing large codebases, big files, or complex multi-file operations that exceed normal context limits. Gemini CLI can handle entire project contexts that would overflow standard AI context windows.
|
||||
|
||||
## Key Capabilities
|
||||
|
||||
- **Massive Context Window**: Analyze entire codebases without context limitations
|
||||
- **File & Directory Inclusion**: Use `@` syntax for precise file/directory targeting
|
||||
- **Multi-File Analysis**: Compare and analyze multiple large files simultaneously
|
||||
- **Codebase Flattening**: Alternative to local flattener for large projects
|
||||
- **Feature Verification**: Check if specific features are implemented across entire projects
|
||||
- **Pattern Discovery**: Find patterns, implementations, and architectural decisions project-wide
|
||||
|
||||
## When to Use Gemini Analysis
|
||||
|
||||
### Ideal Use Cases
|
||||
- **Large Codebase Architecture Analysis**: Understanding overall system design
|
||||
- **Multi-File Pattern Searching**: Finding implementations across multiple files
|
||||
- **Feature Implementation Verification**: Checking if features exist project-wide
|
||||
- **Brownfield Project Discovery**: Understanding existing large codebases
|
||||
- **Context-Heavy Debugging**: Analyzing complex interactions across many files
|
||||
- **Comprehensive Code Reviews**: Reviewing entire feature implementations
|
||||
|
||||
### Context Size Triggers
|
||||
- Files or directories totaling >100KB of content
|
||||
- Analysis requiring >20 files simultaneously
|
||||
- Project-wide architectural understanding needed
|
||||
- Current context window insufficient for task
|
||||
|
||||
## Analysis Modes
|
||||
|
||||
### 1. Single File Analysis
|
||||
**Use Case**: Deep analysis of large individual files
|
||||
**Command Pattern**: `gemini "@file/path Analyze this file's structure and purpose"`
|
||||
**Examples**:
|
||||
- `@src/main.py Explain this file's architecture and key patterns`
|
||||
- `@config/webpack.config.js Break down this configuration and its impact`
|
||||
|
||||
### 2. Directory Analysis
|
||||
**Use Case**: Understanding structure and patterns within specific directories
|
||||
**Command Pattern**: `gemini "@directory/ Analyze the architecture of this codebase section"`
|
||||
**Examples**:
|
||||
- `@src/components/ Summarize the component architecture and patterns`
|
||||
- `@api/routes/ Document all API endpoints and their purposes`
|
||||
|
||||
### 3. Multi-Path Analysis
|
||||
**Use Case**: Comparing and analyzing relationships between multiple areas
|
||||
**Command Pattern**: `gemini "@path1 @path2 Analyze relationships between these areas"`
|
||||
**Examples**:
|
||||
- `@src/ @tests/ Analyze test coverage for the source code`
|
||||
- `@frontend/ @backend/ How do these communicate and what are the integration points?`
|
||||
|
||||
### 4. Project Overview
|
||||
**Use Case**: Comprehensive understanding of entire project
|
||||
**Command Pattern**: `gemini --all-files "Provide comprehensive project analysis"`
|
||||
**Examples**:
|
||||
- `--all-files "Give me an architectural overview of this entire project"`
|
||||
- `--all-files "Summarize the technology stack and key architectural decisions"`
|
||||
|
||||
### 5. Feature Verification
|
||||
**Use Case**: Checking if specific features or patterns are implemented
|
||||
**Command Pattern**: `gemini "@codebase/ Has [feature] been implemented? Show relevant files"`
|
||||
**Examples**:
|
||||
- `@src/ @lib/ Has dark mode been implemented? Show relevant files and functions`
|
||||
- `@api/ @middleware/ Is rate limiting implemented? Show the implementation details`
|
||||
|
||||
### 6. Pattern Discovery
|
||||
**Use Case**: Finding specific coding patterns, security measures, or architectural decisions
|
||||
**Command Pattern**: `gemini "@codebase/ Find all instances of [pattern] and list with file paths"`
|
||||
**Examples**:
|
||||
- `@src/ Are there any React hooks that handle WebSocket connections?`
|
||||
- `@backend/ Is proper error handling implemented for all endpoints?`
|
||||
|
||||
## Task Process
|
||||
|
||||
### 1. Analysis Request Processing
|
||||
|
||||
#### Gather Requirements
|
||||
- **Analysis Type**: Which mode fits the user's need?
|
||||
- **Target Paths**: What files/directories should be included?
|
||||
- **Analysis Depth**: High-level overview vs detailed analysis?
|
||||
- **Specific Questions**: What particular aspects to focus on?
|
||||
- **Output Format**: How should results be presented?
|
||||
|
||||
#### Path Validation
|
||||
- **Existence Check**: Verify all specified paths exist
|
||||
- **Size Assessment**: Estimate total content size
|
||||
- **Permission Validation**: Ensure readable access
|
||||
- **Safety Check**: Confirm read-only analysis scope
|
||||
|
||||
### 2. Command Construction
|
||||
|
||||
#### Basic Command Structure
|
||||
```bash
|
||||
gemini [options] "@path1 @path2 [prompt]"
|
||||
```
|
||||
|
||||
#### Option Selection
|
||||
- **Standard Mode**: `gemini "@path prompt"`
|
||||
- **All Files Mode**: `gemini --all-files "prompt"`
|
||||
- **Safe Mode**: `gemini --approval-mode default "@path prompt"`
|
||||
- **Sandbox Mode**: `gemini --sandbox "@path prompt"` (if editing needed)
|
||||
|
||||
#### Path Formatting
|
||||
- **Single File**: `@src/main.py`
|
||||
- **Directory**: `@src/components/`
|
||||
- **Multiple Paths**: `@src/ @tests/ @docs/`
|
||||
- **Current Directory**: `@./`
|
||||
- **Specific Files**: `@package.json @README.md`
|
||||
|
||||
### 3. Safety and Validation
|
||||
|
||||
#### Pre-Execution Checks
|
||||
- **Read-Only Confirmation**: Ensure analysis-only intent
|
||||
- **Path Sanitization**: Validate and clean file paths
|
||||
- **Size Warnings**: Alert for extremely large contexts
|
||||
- **Approval Mode**: Set appropriate safety level
|
||||
|
||||
#### Command Safety Options
|
||||
```yaml
|
||||
safety_levels:
|
||||
read_only: "Default - analysis only, no modifications"
|
||||
default: "Prompt for any file modifications"
|
||||
auto_edit: "Auto-approve edit tools only"
|
||||
sandbox: "Run in safe sandbox environment"
|
||||
```
|
||||
|
||||
### 4. Execution and Results
|
||||
|
||||
#### Command Execution
|
||||
1. **Validate Paths**: Confirm all targets exist and are accessible
|
||||
2. **Construct Command**: Build proper Gemini CLI command
|
||||
3. **Execute Analysis**: Run Gemini CLI with specified parameters
|
||||
4. **Capture Output**: Collect and format analysis results
|
||||
5. **Error Handling**: Manage CLI failures or timeouts
|
||||
|
||||
#### Result Processing
|
||||
- **Output Formatting**: Structure results for readability
|
||||
- **Key Insights Extraction**: Highlight critical findings
|
||||
- **Follow-up Suggestions**: Recommend next steps
|
||||
- **Source Documentation**: Reference analyzed files/paths
|
||||
|
||||
### 5. Integration with BMAD Workflow
|
||||
|
||||
#### Result Documentation
|
||||
- **Store in Project**: Save significant analyses in `docs/analysis/`
|
||||
- **Reference in Stories**: Link analyses to relevant development stories
|
||||
- **Architecture Updates**: Update architecture docs with findings
|
||||
- **Knowledge Preservation**: Maintain analysis artifacts for team reference
|
||||
|
||||
#### Follow-Up Actions
|
||||
- **Story Creation**: Generate development stories from findings
|
||||
- **Architecture Review**: Update architectural documentation
|
||||
- **Technical Debt**: Identify and document technical debt items
|
||||
- **Research Coordination**: Trigger detailed research if needed
|
||||
|
||||
## Command Templates
|
||||
|
||||
### Architecture Analysis
|
||||
```bash
|
||||
# Overall project architecture
|
||||
gemini --all-files "Analyze the overall architecture of this project. Include technology stack, key patterns, and architectural decisions."
|
||||
|
||||
# Specific component architecture
|
||||
gemini "@src/components/ Analyze the component architecture. What patterns are used and how are components organized?"
|
||||
|
||||
# Backend architecture
|
||||
gemini "@api/ @services/ @middleware/ Analyze the backend architecture. How are routes organized and what patterns are used?"
|
||||
```
|
||||
|
||||
### Feature Verification
|
||||
```bash
|
||||
# Authentication implementation
|
||||
gemini "@src/ @api/ Is JWT authentication fully implemented? Show all auth-related files and middleware."
|
||||
|
||||
# Security measures
|
||||
gemini "@src/ @api/ What security measures are implemented? Look for input validation, CORS, rate limiting."
|
||||
|
||||
# Testing coverage
|
||||
gemini "@src/ @tests/ Analyze test coverage. Which areas are well-tested and which need more tests?"
|
||||
```
|
||||
|
||||
### Code Quality Analysis
|
||||
```bash
|
||||
# Error handling patterns
|
||||
gemini "@src/ @api/ How is error handling implemented throughout the codebase? Show examples."
|
||||
|
||||
# Performance considerations
|
||||
gemini "@src/ @lib/ What performance optimizations are in place? Identify potential bottlenecks."
|
||||
|
||||
# Code organization
|
||||
gemini "@src/ How is the code organized? What are the main modules and their responsibilities?"
|
||||
```
|
||||
|
||||
### Technology Assessment
|
||||
```bash
|
||||
# Dependency analysis
|
||||
gemini "@package.json @src/ What are the key dependencies and how are they used in the code?"
|
||||
|
||||
# Build system analysis
|
||||
gemini "@webpack.config.js @package.json @src/ How is the build system configured and what optimizations are in place?"
|
||||
|
||||
# Database integration
|
||||
gemini "@models/ @migrations/ @src/ How is the database integrated? What ORM patterns are used?"
|
||||
```
|
||||
|
||||
## Error Handling
|
||||
|
||||
### Common Issues
|
||||
- **Path Not Found**: Specified files/directories don't exist
|
||||
- **Context Too Large**: Even Gemini's context has limits
|
||||
- **CLI Unavailable**: Gemini CLI not installed or configured
|
||||
- **Permission Denied**: Cannot read specified files
|
||||
- **Command Timeout**: Analysis takes too long to complete
|
||||
|
||||
### Error Recovery
|
||||
- **Path Validation**: Pre-validate all paths before execution
|
||||
- **Graceful Degradation**: Suggest smaller scope if context too large
|
||||
- **Alternative Approaches**: Offer local flattener or partial analysis
|
||||
- **Clear Error Messages**: Provide actionable error information
|
||||
- **Fallback Options**: Suggest manual analysis approaches
|
||||
|
||||
### Safety Measures
|
||||
- **Read-Only Default**: Never modify files without explicit permission
|
||||
- **Approval Prompts**: Confirm any file modifications
|
||||
- **Sandbox Options**: Use sandbox mode for risky operations
|
||||
- **Timeout Protection**: Prevent hanging operations
|
||||
- **Resource Monitoring**: Track memory and processing usage
|
||||
|
||||
## Integration Notes
|
||||
|
||||
### With Existing BMAD Tools
|
||||
- **Flattener Integration**: Use existing flattener for preprocessing when needed
|
||||
- **Research Coordination**: Can trigger research system for follow-up analysis
|
||||
- **Story Generation**: Results can inform story creation
|
||||
- **Architecture Documentation**: Updates architectural understanding
|
||||
|
||||
### With Core Configuration
|
||||
- **Command Templates**: Stored in core-config.yaml for consistency
|
||||
- **Default Settings**: Safety and approval modes configured globally
|
||||
- **Path Patterns**: Common path combinations for different project types
|
||||
- **Integration Points**: How Gemini analysis feeds into BMAD workflow
|
||||
|
||||
### Agent Accessibility
|
||||
All agents with Gemini analysis capability will have access to:
|
||||
- **Standard Analysis**: `*gemini-analyze` command for common patterns
|
||||
- **Custom Queries**: Ability to specify custom analysis prompts
|
||||
- **Result Integration**: Automatic integration with agent workflows
|
||||
- **Safety Controls**: Appropriate safety measures for agent context
|
||||
==================== END: .bmad-core/tasks/gemini-analysis.md ====================
|
||||
|
||||
==================== START: .bmad-core/tasks/request-research.md ====================
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
|
|
@ -2586,6 +2846,7 @@ This task provides a unified interface for any agent to request specialized rese
|
|||
## Usage Scenarios
|
||||
|
||||
### From Any Agent
|
||||
|
||||
Any agent can call this task to get specialized research assistance:
|
||||
|
||||
```yaml
|
||||
|
|
@ -2607,24 +2868,28 @@ Any agent can call this task to get specialized research assistance:
|
|||
The task will elicit a structured research request with these components:
|
||||
|
||||
#### Research Context
|
||||
|
||||
- **Requesting Agent**: Which agent is making the request
|
||||
- **Project Context**: Current project phase and relevant background
|
||||
- **Previous Research**: Check research log for related prior work
|
||||
- **Urgency Level**: Timeline constraints and priority
|
||||
|
||||
#### Research Objective
|
||||
|
||||
- **Primary Goal**: What specific question or problem needs researching
|
||||
- **Success Criteria**: How to measure if research achieved its objective
|
||||
- **Scope Boundaries**: What to include/exclude from research
|
||||
- **Decision Impact**: How results will be used
|
||||
|
||||
#### Domain Specialization Requirements
|
||||
|
||||
- **Primary Domain**: Main area of expertise needed (technical, market, user, etc.)
|
||||
- **Secondary Domains**: Additional perspectives required
|
||||
- **Specific Expertise**: Particular skills or knowledge areas
|
||||
- **Research Depth**: High-level overview vs deep technical analysis
|
||||
|
||||
#### Output Requirements
|
||||
|
||||
- **Format**: Executive summary, detailed report, comparison matrix, etc.
|
||||
- **Audience**: Who will consume the research results
|
||||
- **Integration**: How results feed into next steps
|
||||
|
|
@ -2653,12 +2918,14 @@ Each Researcher Agent will:
|
|||
### 4. Result Delivery
|
||||
|
||||
#### To Requesting Agent
|
||||
|
||||
- **Executive Summary**: Key findings and recommendations
|
||||
- **Detailed Analysis**: Comprehensive research results
|
||||
- **Source Documentation**: Links and citations for verification
|
||||
- **Next Steps**: Recommended actions or follow-up research
|
||||
|
||||
#### To Research Log
|
||||
|
||||
- **Research Entry**: Concise summary stored in `docs/research/YYYY-MM-DD-research-topic.md`
|
||||
- **Index Update**: Add entry to `docs/research/research-index.md`
|
||||
- **Tag Classification**: Add searchable tags for future reference
|
||||
|
|
@ -2677,40 +2944,40 @@ When executing this task, use this structure for research requests:
|
|||
```yaml
|
||||
research_request:
|
||||
metadata:
|
||||
requesting_agent: "[agent-id]"
|
||||
request_date: "[YYYY-MM-DD]"
|
||||
priority: "[high|medium|low]"
|
||||
timeline: "[timeframe needed]"
|
||||
requesting_agent: '[agent-id]'
|
||||
request_date: '[YYYY-MM-DD]'
|
||||
priority: '[high|medium|low]'
|
||||
timeline: '[timeframe needed]'
|
||||
|
||||
context:
|
||||
project_phase: "[planning|development|validation|etc]"
|
||||
background: "[relevant project context]"
|
||||
related_docs: "[PRD, architecture, stories, etc]"
|
||||
previous_research: "[check research log references]"
|
||||
project_phase: '[planning|development|validation|etc]'
|
||||
background: '[relevant project context]'
|
||||
related_docs: '[PRD, architecture, stories, etc]'
|
||||
previous_research: '[check research log references]'
|
||||
|
||||
objective:
|
||||
primary_goal: "[specific research question]"
|
||||
success_criteria: "[how to measure success]"
|
||||
scope: "[boundaries and limitations]"
|
||||
decision_impact: "[how results will be used]"
|
||||
primary_goal: '[specific research question]'
|
||||
success_criteria: '[how to measure success]'
|
||||
scope: '[boundaries and limitations]'
|
||||
decision_impact: '[how results will be used]'
|
||||
|
||||
specialization:
|
||||
primary_domain: "[technical|market|user|competitive|regulatory|etc]"
|
||||
secondary_domains: "[additional perspectives needed]"
|
||||
specific_expertise: "[particular skills required]"
|
||||
research_depth: "[overview|detailed|comprehensive]"
|
||||
primary_domain: '[technical|market|user|competitive|regulatory|etc]'
|
||||
secondary_domains: '[additional perspectives needed]'
|
||||
specific_expertise: '[particular skills required]'
|
||||
research_depth: '[overview|detailed|comprehensive]'
|
||||
|
||||
team_config:
|
||||
researcher_count: "[1-3, default 3]"
|
||||
perspective_1: "[domain and focus area]"
|
||||
perspective_2: "[domain and focus area]"
|
||||
perspective_3: "[domain and focus area]"
|
||||
researcher_count: '[1-3, default 3]'
|
||||
perspective_1: '[domain and focus area]'
|
||||
perspective_2: '[domain and focus area]'
|
||||
perspective_3: '[domain and focus area]'
|
||||
|
||||
output:
|
||||
format: "[executive_summary|detailed_report|comparison_matrix|etc]"
|
||||
audience: "[who will use results]"
|
||||
integration: "[how results feed into workflow]"
|
||||
citation_level: "[minimal|standard|comprehensive]"
|
||||
format: '[executive_summary|detailed_report|comparison_matrix|etc]'
|
||||
audience: '[who will use results]'
|
||||
integration: '[how results feed into workflow]'
|
||||
citation_level: '[minimal|standard|comprehensive]'
|
||||
```
|
||||
|
||||
## Integration with Existing Agents
|
||||
|
|
@ -2742,26 +3009,32 @@ commands:
|
|||
## Research Log Structure
|
||||
|
||||
### Research Index (`docs/research/research-index.md`)
|
||||
|
||||
```markdown
|
||||
# Research Index
|
||||
|
||||
## Recent Research
|
||||
|
||||
- [2024-01-15: AI Model Comparison](2024-01-15-ai-model-comparison.md) - Technical analysis of LLM options
|
||||
- [2024-01-12: Payment Gateway Analysis](2024-01-12-payment-gateway-analysis.md) - Market comparison of payment solutions
|
||||
|
||||
## Research by Category
|
||||
|
||||
### Technical Research
|
||||
|
||||
- AI/ML Models
|
||||
- Architecture Decisions
|
||||
- Technology Stacks
|
||||
|
||||
### Market Research
|
||||
|
||||
- Competitive Analysis
|
||||
- User Behavior
|
||||
- Industry Trends
|
||||
```
|
||||
|
||||
### Individual Research Files (`docs/research/YYYY-MM-DD-topic.md`)
|
||||
|
||||
```markdown
|
||||
# Research: [Topic]
|
||||
|
||||
|
|
@ -2770,31 +3043,41 @@ commands:
|
|||
**Research Team**: [perspectives used]
|
||||
|
||||
## Executive Summary
|
||||
|
||||
[Key findings and recommendations]
|
||||
|
||||
## Research Objective
|
||||
|
||||
[What was being researched and why]
|
||||
|
||||
## Key Findings
|
||||
|
||||
[Main insights from all perspectives]
|
||||
|
||||
## Recommendations
|
||||
|
||||
[Actionable next steps]
|
||||
|
||||
## Research Team Perspectives
|
||||
|
||||
### Perspective 1: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 2: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
### Perspective 3: [Domain]
|
||||
|
||||
[Key insights from this angle]
|
||||
|
||||
## Sources and References
|
||||
|
||||
[Credible sources cited by research team]
|
||||
|
||||
## Tags
|
||||
|
||||
[Searchable tags for future reference]
|
||||
```
|
||||
|
||||
|
|
|
|||
|
|
@ -1732,19 +1732,23 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 1. Research Request Intake
|
||||
|
||||
#### Process Incoming Request
|
||||
|
||||
**If called via unified request-research task:**
|
||||
|
||||
- Extract research request YAML structure
|
||||
- Validate all required fields are present
|
||||
- Understand requesting agent context and needs
|
||||
- Assess urgency and timeline constraints
|
||||
|
||||
**If called directly by user/agent:**
|
||||
|
||||
- Elicit research requirements using structured approach
|
||||
- Guide user through research request specification
|
||||
- Ensure clarity on objectives and expected outcomes
|
||||
- Document request in standard format
|
||||
|
||||
#### Critical Elements to Capture
|
||||
|
||||
- **Requesting Agent**: Which agent needs the research
|
||||
- **Research Objective**: Specific question or problem
|
||||
- **Context**: Project phase, background, constraints
|
||||
|
|
@ -1756,6 +1760,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 2. Research Log Analysis
|
||||
|
||||
#### Check for Existing Research
|
||||
|
||||
1. **Search Research Index**: Look for related prior research
|
||||
- Search by topic keywords
|
||||
- Check domain tags and categories
|
||||
|
|
@ -1777,6 +1782,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 3. Research Strategy Design
|
||||
|
||||
#### Multi-Perspective Planning
|
||||
|
||||
1. **Determine Research Team Size**
|
||||
- Default: 3 researchers for comprehensive coverage
|
||||
- Configurable based on complexity and timeline
|
||||
|
|
@ -1789,6 +1795,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
- **Maximize Coverage**: Balance breadth vs depth
|
||||
|
||||
#### Common Research Team Configurations
|
||||
|
||||
- **Technology Assessment**: Technical + Scalability + Security
|
||||
- **Market Analysis**: Market + Competitive + User
|
||||
- **Product Decision**: Technical + Business + User
|
||||
|
|
@ -1798,6 +1805,7 @@ This task is the primary workflow for the Research Coordinator to manage multi-p
|
|||
### 4. Researcher Deployment
|
||||
|
||||
#### Configure Research Teams
|
||||
|
||||
For each researcher agent:
|
||||
|
||||
1. **Specialization Configuration**
|
||||
|
|
@ -1819,28 +1827,31 @@ For each researcher agent:
|
|||
- Quality standards and source requirements
|
||||
|
||||
#### Research Assignment Template
|
||||
|
||||
```yaml
|
||||
researcher_briefing:
|
||||
research_context: "[Context from original request]"
|
||||
assigned_domain: "[Primary specialization]"
|
||||
perspective_focus: "[Specific angle to investigate]"
|
||||
research_questions: "[Domain-specific questions to address]"
|
||||
source_priorities: "[Types of sources to prioritize]"
|
||||
analysis_framework: "[How to analyze information]"
|
||||
coordination_role: "[How this fits with other researchers]"
|
||||
deliverable_format: "[Expected output structure]"
|
||||
timeline: "[Deadlines and checkpoints]"
|
||||
research_context: '[Context from original request]'
|
||||
assigned_domain: '[Primary specialization]'
|
||||
perspective_focus: '[Specific angle to investigate]'
|
||||
research_questions: '[Domain-specific questions to address]'
|
||||
source_priorities: '[Types of sources to prioritize]'
|
||||
analysis_framework: '[How to analyze information]'
|
||||
coordination_role: '[How this fits with other researchers]'
|
||||
deliverable_format: '[Expected output structure]'
|
||||
timeline: '[Deadlines and checkpoints]'
|
||||
```
|
||||
|
||||
### 5. Research Coordination
|
||||
|
||||
#### Monitor Research Progress
|
||||
|
||||
- **Progress Checkpoints**: Regular status updates from researchers
|
||||
- **Quality Review**: Interim assessment of findings quality
|
||||
- **Coordination Adjustments**: Modify approach based on early findings
|
||||
- **Conflict Resolution**: Address disagreements between researchers
|
||||
|
||||
#### Handle Research Challenges
|
||||
|
||||
- **Information Gaps**: Redirect research focus if sources unavailable
|
||||
- **Conflicting Findings**: Document disagreements for synthesis
|
||||
- **Scope Creep**: Keep research focused on original objectives
|
||||
|
|
@ -1849,6 +1860,7 @@ researcher_briefing:
|
|||
### 6. Findings Synthesis
|
||||
|
||||
#### Synthesis Process
|
||||
|
||||
1. **Gather Individual Reports**
|
||||
- Collect findings from each researcher
|
||||
- Review quality and completeness
|
||||
|
|
@ -1868,6 +1880,7 @@ researcher_briefing:
|
|||
- Identify areas needing additional research
|
||||
|
||||
#### Synthesis Output Structure
|
||||
|
||||
Using research-synthesis-tmpl.yaml:
|
||||
|
||||
1. **Executive Summary**: Key insights and recommendations
|
||||
|
|
@ -1881,12 +1894,14 @@ Using research-synthesis-tmpl.yaml:
|
|||
### 7. Delivery and Documentation
|
||||
|
||||
#### Deliver to Requesting Agent
|
||||
|
||||
1. **Primary Deliverable**: Synthesized research report
|
||||
2. **Executive Summary**: Key findings and recommendations
|
||||
3. **Supporting Detail**: Access to full analysis as needed
|
||||
4. **Next Steps**: Recommended actions and follow-up research
|
||||
|
||||
#### Update Research Index
|
||||
|
||||
Using research-log-entry-tmpl.yaml:
|
||||
|
||||
1. **Add Index Entry**: New research to chronological list
|
||||
|
|
@ -1895,6 +1910,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
4. **Cross-References**: Link to related prior research
|
||||
|
||||
#### Store Research Artifacts
|
||||
|
||||
- **Primary Report**: Store in docs/research/ with date-topic filename
|
||||
- **Research Index**: Update research-index.md with new entry
|
||||
- **Source Documentation**: Preserve links and references
|
||||
|
|
@ -1903,6 +1919,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 8. Quality Assurance
|
||||
|
||||
#### Research Quality Checklist
|
||||
|
||||
- **Objective Completion**: All research questions addressed
|
||||
- **Source Credibility**: Reliable, recent, and relevant sources
|
||||
- **Perspective Diversity**: Genuinely different analytical angles
|
||||
|
|
@ -1912,6 +1929,7 @@ Using research-log-entry-tmpl.yaml:
|
|||
- **Uncertainty Documentation**: Limitations and gaps clearly stated
|
||||
|
||||
#### Validation Steps
|
||||
|
||||
1. **Internal Review**: Coordinator validates synthesis quality
|
||||
2. **Source Verification**: Spot-check key sources and evidence
|
||||
3. **Logic Check**: Ensure recommendations follow from findings
|
||||
|
|
@ -1920,12 +1938,14 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 9. Error Handling and Edge Cases
|
||||
|
||||
#### Common Challenges
|
||||
|
||||
- **Researcher Unavailability**: Adjust team size or perspective assignments
|
||||
- **Source Access Issues**: Graceful degradation to available information
|
||||
- **Conflicting Deadlines**: Prioritize critical research elements
|
||||
- **Quality Problems**: Reassign research or adjust scope
|
||||
|
||||
#### Escalation Triggers
|
||||
|
||||
- **Irreconcilable Conflicts**: Major disagreements between researchers
|
||||
- **Missing Critical Information**: Gaps that prevent objective completion
|
||||
- **Quality Failures**: Repeated issues with source credibility or analysis
|
||||
|
|
@ -1934,12 +1954,14 @@ Using research-log-entry-tmpl.yaml:
|
|||
### 10. Continuous Improvement
|
||||
|
||||
#### Research Process Optimization
|
||||
|
||||
- **Track Research Effectiveness**: Monitor how research informs decisions
|
||||
- **Identify Common Patterns**: Frequently requested research types
|
||||
- **Optimize Team Configurations**: Most effective perspective combinations
|
||||
- **Improve Synthesis Quality**: Better integration techniques
|
||||
|
||||
#### Knowledge Base Enhancement
|
||||
|
||||
- **Update Domain Profiles**: Refine specialization descriptions
|
||||
- **Expand Source Directories**: Add new credible source types
|
||||
- **Improve Methodologies**: Better research and analysis frameworks
|
||||
|
|
@ -1968,6 +1990,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
### 1. Search Strategy
|
||||
|
||||
#### Check Research Index
|
||||
|
||||
1. **Load Research Index**: Read `docs/research/research-index.md`
|
||||
2. **Keyword Search**: Search for related terms in:
|
||||
- Research titles and descriptions
|
||||
|
|
@ -1976,6 +1999,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
- Requesting agent information
|
||||
|
||||
#### Search Parameters
|
||||
|
||||
- **Topic Keywords**: Core subject terms from research request
|
||||
- **Domain Tags**: Technical, market, user, competitive, etc.
|
||||
- **Date Range**: Recent research vs historical
|
||||
|
|
@ -1984,6 +2008,7 @@ This task enables the Research Coordinator to search existing research logs to i
|
|||
### 2. Analysis Process
|
||||
|
||||
#### Evaluate Matches
|
||||
|
||||
For each potential match:
|
||||
|
||||
1. **Relevance Assessment**
|
||||
|
|
@ -2004,21 +2029,25 @@ For each potential match:
|
|||
### 3. Output Options
|
||||
|
||||
#### Full Coverage Exists
|
||||
|
||||
- **Recommendation**: Refer to existing research
|
||||
- **Action**: Provide link and summary of relevant findings
|
||||
- **Update Strategy**: Consider if refresh needed due to age
|
||||
|
||||
#### Partial Coverage Available
|
||||
|
||||
- **Recommendation**: Build on existing research
|
||||
- **Action**: Identify specific gaps to focus new research
|
||||
- **Integration Strategy**: How to combine old and new findings
|
||||
|
||||
#### No Relevant Coverage
|
||||
|
||||
- **Recommendation**: Proceed with full research effort
|
||||
- **Action**: Document search results to avoid future confusion
|
||||
- **Baseline**: Use existing research as context background
|
||||
|
||||
#### Outdated Coverage
|
||||
|
||||
- **Recommendation**: Update/refresh existing research
|
||||
- **Action**: Compare current request to prior research scope
|
||||
- **Strategy**: Full refresh vs targeted updates
|
||||
|
|
@ -2026,6 +2055,7 @@ For each potential match:
|
|||
### 4. Documentation
|
||||
|
||||
#### Search Results Summary
|
||||
|
||||
```markdown
|
||||
## Research Log Search Results
|
||||
|
||||
|
|
@ -2034,6 +2064,7 @@ For each potential match:
|
|||
**Matches Found**: [number of potential matches]
|
||||
|
||||
### Relevant Prior Research
|
||||
|
||||
1. **[Research Title]** (Date: YYYY-MM-DD)
|
||||
- **Relevance**: [how closely it matches]
|
||||
- **Coverage**: [what aspects are covered]
|
||||
|
|
@ -2042,6 +2073,7 @@ For each potential match:
|
|||
- **Recommendation**: [use as-is/build-on/refresh/ignore]
|
||||
|
||||
### Search Conclusion
|
||||
|
||||
- **Overall Assessment**: [full/partial/no/outdated coverage]
|
||||
- **Recommended Action**: [refer/build-on/proceed/refresh]
|
||||
- **Integration Strategy**: [how to use prior work]
|
||||
|
|
@ -2050,12 +2082,14 @@ For each potential match:
|
|||
### 5. Integration Recommendations
|
||||
|
||||
#### Building on Prior Research
|
||||
|
||||
- **Reference Strategy**: How to cite and build upon existing work
|
||||
- **Gap Focus**: Specific areas to concentrate new research efforts
|
||||
- **Perspective Additions**: New angles not covered in prior research
|
||||
- **Update Requirements**: Refresh outdated information
|
||||
|
||||
#### Avoiding Duplication
|
||||
|
||||
- **Scope Differentiation**: How current request differs from prior work
|
||||
- **Methodology Variation**: Different research approaches to try
|
||||
- **Source Expansion**: New information sources to explore
|
||||
|
|
@ -2358,6 +2392,7 @@ sections:
|
|||
## Pre-Research Planning
|
||||
|
||||
### Research Objective Clarity
|
||||
|
||||
- [ ] Research objective is specific and measurable
|
||||
- [ ] Success criteria are clearly defined
|
||||
- [ ] Scope boundaries are explicitly stated
|
||||
|
|
@ -2365,6 +2400,7 @@ sections:
|
|||
- [ ] Timeline and priority constraints are documented
|
||||
|
||||
### Research Strategy Design
|
||||
|
||||
- [ ] Multi-perspective approach is appropriate for complexity
|
||||
- [ ] Domain specializations are properly assigned
|
||||
- [ ] Research team size matches scope and timeline
|
||||
|
|
@ -2372,6 +2408,7 @@ sections:
|
|||
- [ ] Research methodologies are appropriate for objectives
|
||||
|
||||
### Prior Research Review
|
||||
|
||||
- [ ] Research log has been searched for related work
|
||||
- [ ] Prior research relevance has been assessed
|
||||
- [ ] Strategy for building on existing work is defined
|
||||
|
|
@ -2380,6 +2417,7 @@ sections:
|
|||
## During Research Execution
|
||||
|
||||
### Source Quality and Credibility
|
||||
|
||||
- [ ] Sources are credible and authoritative
|
||||
- [ ] Information recency is appropriate for topic
|
||||
- [ ] Source diversity provides multiple viewpoints
|
||||
|
|
@ -2387,6 +2425,7 @@ sections:
|
|||
- [ ] Primary sources are prioritized over secondary when available
|
||||
|
||||
### Research Methodology
|
||||
|
||||
- [ ] Research approach is systematic and thorough
|
||||
- [ ] Domain expertise lens is consistently applied
|
||||
- [ ] Web search capabilities are effectively utilized
|
||||
|
|
@ -2394,6 +2433,7 @@ sections:
|
|||
- [ ] Analysis frameworks are appropriate for domain
|
||||
|
||||
### Quality Assurance
|
||||
|
||||
- [ ] Key findings are supported by multiple sources
|
||||
- [ ] Conflicting information is properly documented
|
||||
- [ ] Uncertainty levels are clearly identified
|
||||
|
|
@ -2403,6 +2443,7 @@ sections:
|
|||
## Synthesis and Integration
|
||||
|
||||
### Multi-Perspective Synthesis
|
||||
|
||||
- [ ] Findings from all researchers are properly integrated
|
||||
- [ ] Convergent insights are clearly identified
|
||||
- [ ] Divergent viewpoints are fairly represented
|
||||
|
|
@ -2410,6 +2451,7 @@ sections:
|
|||
- [ ] Gaps requiring additional research are documented
|
||||
|
||||
### Analysis Quality
|
||||
|
||||
- [ ] Key findings directly address research objectives
|
||||
- [ ] Evidence supports conclusions and recommendations
|
||||
- [ ] Limitations and uncertainties are transparently documented
|
||||
|
|
@ -2417,6 +2459,7 @@ sections:
|
|||
- [ ] Recommendations are actionable and specific
|
||||
|
||||
### Documentation Standards
|
||||
|
||||
- [ ] Executive summary captures key insights effectively
|
||||
- [ ] Detailed analysis is well-organized and comprehensive
|
||||
- [ ] Source documentation enables verification
|
||||
|
|
@ -2426,6 +2469,7 @@ sections:
|
|||
## Final Deliverable Review
|
||||
|
||||
### Completeness
|
||||
|
||||
- [ ] All research questions have been addressed
|
||||
- [ ] Success criteria have been met
|
||||
- [ ] Output format matches requestor requirements
|
||||
|
|
@ -2433,6 +2477,7 @@ sections:
|
|||
- [ ] Next steps and follow-up needs are identified
|
||||
|
||||
### Decision Support Quality
|
||||
|
||||
- [ ] Findings directly inform decision-making needs
|
||||
- [ ] Confidence levels help assess decision risk
|
||||
- [ ] Recommendations are prioritized and actionable
|
||||
|
|
@ -2440,6 +2485,7 @@ sections:
|
|||
- [ ] Risk factors and mitigation strategies are provided
|
||||
|
||||
### Integration and Handoff
|
||||
|
||||
- [ ] Results are properly formatted for requesting agent
|
||||
- [ ] Research log has been updated with new entry
|
||||
- [ ] Index categorization is accurate and searchable
|
||||
|
|
@ -2449,6 +2495,7 @@ sections:
|
|||
## Post-Research Evaluation
|
||||
|
||||
### Research Effectiveness
|
||||
|
||||
- [ ] Research objectives were successfully achieved
|
||||
- [ ] Timeline and resource constraints were managed effectively
|
||||
- [ ] Quality standards were maintained throughout process
|
||||
|
|
@ -2456,6 +2503,7 @@ sections:
|
|||
- [ ] Lessons learned are documented for process improvement
|
||||
|
||||
### Knowledge Management
|
||||
|
||||
- [ ] Research artifacts are properly stored and indexed
|
||||
- [ ] Key insights are preserved for future reference
|
||||
- [ ] Research methodology insights can inform future efforts
|
||||
|
|
@ -2465,6 +2513,7 @@ sections:
|
|||
## Quality Escalation Triggers
|
||||
|
||||
### Immediate Review Required
|
||||
|
||||
- [ ] Major conflicts between research perspectives cannot be reconciled
|
||||
- [ ] Key sources are found to be unreliable or biased
|
||||
- [ ] Research scope significantly exceeds original boundaries
|
||||
|
|
@ -2472,6 +2521,7 @@ sections:
|
|||
- [ ] Timeline constraints threaten quality standards
|
||||
|
||||
### Process Improvement Needed
|
||||
|
||||
- [ ] Repeated issues with source credibility or access
|
||||
- [ ] Frequent scope creep or objective changes
|
||||
- [ ] Consistent challenges with perspective coordination
|
||||
|
|
@ -2481,6 +2531,7 @@ sections:
|
|||
## Continuous Improvement
|
||||
|
||||
### Research Process Enhancement
|
||||
|
||||
- [ ] Track research effectiveness and decision impact
|
||||
- [ ] Identify patterns in research requests and optimize approaches
|
||||
- [ ] Refine domain specialization profiles based on experience
|
||||
|
|
@ -2488,6 +2539,7 @@ sections:
|
|||
- [ ] Enhance coordination methods between research perspectives
|
||||
|
||||
### Knowledge Base Development
|
||||
|
||||
- [ ] Update research methodologies based on lessons learned
|
||||
- [ ] Expand credible source directories with new discoveries
|
||||
- [ ] Improve domain expertise profiles with refined specializations
|
||||
|
|
@ -2505,6 +2557,7 @@ sections:
|
|||
### Technical Research Methodologies
|
||||
|
||||
#### Technology Assessment Framework
|
||||
|
||||
- **Capability Analysis**: Feature sets, performance characteristics, scalability limits
|
||||
- **Implementation Evaluation**: Complexity, learning curve, integration requirements
|
||||
- **Ecosystem Assessment**: Community support, documentation quality, maintenance status
|
||||
|
|
@ -2512,6 +2565,7 @@ sections:
|
|||
- **Security Analysis**: Vulnerability assessment, security model evaluation
|
||||
|
||||
#### Technical Source Priorities
|
||||
|
||||
1. **Official Documentation**: Primary source for capabilities and limitations
|
||||
2. **GitHub Repositories**: Code quality, activity level, issue resolution patterns
|
||||
3. **Technical Blogs**: Implementation experiences, best practices, lessons learned
|
||||
|
|
@ -2521,6 +2575,7 @@ sections:
|
|||
### Market Research Methodologies
|
||||
|
||||
#### Market Analysis Framework
|
||||
|
||||
- **Market Sizing**: TAM/SAM/SOM analysis, growth rate assessment
|
||||
- **Competitive Landscape**: Player mapping, market share analysis, positioning
|
||||
- **Customer Segmentation**: Demographics, psychographics, behavioral patterns
|
||||
|
|
@ -2528,6 +2583,7 @@ sections:
|
|||
- **Opportunity Assessment**: Market gaps, underserved segments, entry barriers
|
||||
|
||||
#### Market Source Priorities
|
||||
|
||||
1. **Industry Reports**: Analyst research, market studies, trend analyses
|
||||
2. **Financial Data**: Public company reports, funding announcements, valuations
|
||||
3. **Survey Data**: Customer research, market studies, adoption surveys
|
||||
|
|
@ -2537,6 +2593,7 @@ sections:
|
|||
### User Research Methodologies
|
||||
|
||||
#### User-Centered Research Framework
|
||||
|
||||
- **Behavioral Analysis**: User journey mapping, interaction patterns, pain points
|
||||
- **Needs Assessment**: Jobs-to-be-done analysis, unmet needs identification
|
||||
- **Experience Evaluation**: Usability assessment, satisfaction measurement
|
||||
|
|
@ -2544,6 +2601,7 @@ sections:
|
|||
- **Context Analysis**: Use case scenarios, environmental factors, constraints
|
||||
|
||||
#### User Research Source Priorities
|
||||
|
||||
1. **User Studies**: Direct research, surveys, interviews, focus groups
|
||||
2. **Product Reviews**: Customer feedback, ratings, detailed experiences
|
||||
3. **Social Media**: User discussions, complaints, feature requests
|
||||
|
|
@ -2553,6 +2611,7 @@ sections:
|
|||
### Competitive Research Methodologies
|
||||
|
||||
#### Competitive Intelligence Framework
|
||||
|
||||
- **Feature Comparison**: Capability matrices, feature gap analysis
|
||||
- **Strategic Analysis**: Business model evaluation, positioning assessment
|
||||
- **Performance Benchmarking**: Speed, reliability, user experience comparisons
|
||||
|
|
@ -2560,6 +2619,7 @@ sections:
|
|||
- **Innovation Tracking**: Product roadmaps, patent filings, investment areas
|
||||
|
||||
#### Competitive Source Priorities
|
||||
|
||||
1. **Competitor Websites**: Product information, pricing, positioning messages
|
||||
2. **Product Demos**: Hands-on evaluation, feature testing, user experience
|
||||
3. **Press Releases**: Strategic announcements, product launches, partnerships
|
||||
|
|
@ -2569,6 +2629,7 @@ sections:
|
|||
### Scientific Research Methodologies
|
||||
|
||||
#### Scientific Analysis Framework
|
||||
|
||||
- **Literature Review**: Peer-reviewed research, citation analysis, consensus building
|
||||
- **Methodology Assessment**: Research design quality, statistical validity, reproducibility
|
||||
- **Evidence Evaluation**: Study quality, sample sizes, control factors
|
||||
|
|
@ -2576,6 +2637,7 @@ sections:
|
|||
- **Application Assessment**: Practical implications, implementation feasibility
|
||||
|
||||
#### Scientific Source Priorities
|
||||
|
||||
1. **Peer-Reviewed Journals**: Primary research, systematic reviews, meta-analyses
|
||||
2. **Academic Databases**: Research repositories, citation networks, preprints
|
||||
3. **Conference Proceedings**: Latest research, emerging trends, expert presentations
|
||||
|
|
@ -2587,6 +2649,7 @@ sections:
|
|||
### Source Credibility Assessment
|
||||
|
||||
#### Primary Source Evaluation
|
||||
|
||||
- **Authority**: Expertise of authors, institutional affiliation, credentials
|
||||
- **Accuracy**: Fact-checking, peer review process, error correction mechanisms
|
||||
- **Objectivity**: Bias assessment, funding sources, conflict of interest disclosure
|
||||
|
|
@ -2594,6 +2657,7 @@ sections:
|
|||
- **Coverage**: Scope comprehensiveness, detail level, methodology transparency
|
||||
|
||||
#### Secondary Source Validation
|
||||
|
||||
- **Citation Quality**: Primary source references, citation accuracy, source diversity
|
||||
- **Synthesis Quality**: Analysis depth, logical coherence, balanced perspective
|
||||
- **Author Expertise**: Subject matter knowledge, track record, reputation
|
||||
|
|
@ -2603,6 +2667,7 @@ sections:
|
|||
### Information Synthesis Approaches
|
||||
|
||||
#### Multi-Perspective Integration
|
||||
|
||||
- **Convergence Analysis**: Identify areas where sources agree consistently
|
||||
- **Divergence Documentation**: Note significant disagreements and analyze causes
|
||||
- **Confidence Weighting**: Assign confidence levels based on source quality and consensus
|
||||
|
|
@ -2610,6 +2675,7 @@ sections:
|
|||
- **Uncertainty Quantification**: Document limitations and areas of unclear evidence
|
||||
|
||||
#### Evidence Hierarchy
|
||||
|
||||
1. **High Confidence**: Multiple credible sources, recent information, expert consensus
|
||||
2. **Medium Confidence**: Some credible sources, mixed consensus, moderate currency
|
||||
3. **Low Confidence**: Limited sources, significant disagreement, dated information
|
||||
|
|
@ -2619,6 +2685,7 @@ sections:
|
|||
## Domain-Specific Analysis Frameworks
|
||||
|
||||
### Technical Analysis Framework
|
||||
|
||||
- **Feasibility Assessment**: Technical viability, implementation complexity, resource requirements
|
||||
- **Scalability Analysis**: Performance under load, growth accommodation, architectural limits
|
||||
- **Integration Evaluation**: Compatibility assessment, integration complexity, ecosystem fit
|
||||
|
|
@ -2626,6 +2693,7 @@ sections:
|
|||
- **Risk Assessment**: Technical risks, dependency risks, obsolescence potential
|
||||
|
||||
### Business Analysis Framework
|
||||
|
||||
- **Value Proposition**: Customer value delivery, competitive advantage, market differentiation
|
||||
- **Financial Impact**: Cost analysis, revenue potential, ROI assessment, budget implications
|
||||
- **Strategic Alignment**: Goal consistency, priority alignment, resource allocation fit
|
||||
|
|
@ -2633,6 +2701,7 @@ sections:
|
|||
- **Risk-Benefit Analysis**: Potential rewards vs implementation risks and costs
|
||||
|
||||
### User Impact Framework
|
||||
|
||||
- **User Experience**: Ease of use, learning curve, satisfaction factors, accessibility
|
||||
- **Adoption Factors**: Barriers to adoption, motivation drivers, change management needs
|
||||
- **Value Delivery**: User benefit realization, problem solving effectiveness, outcome achievement
|
||||
|
|
@ -2642,6 +2711,7 @@ sections:
|
|||
## Research Coordination Best Practices
|
||||
|
||||
### Multi-Researcher Coordination
|
||||
|
||||
- **Perspective Assignment**: Clear domain boundaries, minimal overlap, comprehensive coverage
|
||||
- **Communication Protocols**: Regular check-ins, conflict resolution processes, coordination methods
|
||||
- **Quality Standards**: Consistent source credibility requirements, analysis depth expectations
|
||||
|
|
@ -2649,6 +2719,7 @@ sections:
|
|||
- **Integration Planning**: Synthesis approach design, conflict resolution strategies, gap handling
|
||||
|
||||
### Research Efficiency Optimization
|
||||
|
||||
- **Source Sharing**: Avoid duplicate source evaluation across researchers
|
||||
- **Finding Coordination**: Share relevant discoveries between perspectives
|
||||
- **Quality Checks**: Cross-validation of key findings, source verification collaboration
|
||||
|
|
|
|||
Loading…
Reference in New Issue