mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-11 02:33:51 +08:00
feat: add workflow prompt templates for planning phases
Add CLI prompt templates for workflow planning integration: - analysis-results-structure.txt: ANALYSIS_RESULTS.md generation template - gemini-solution-design.txt: Solution design analysis template - codex-feasibility-validation.txt: Technical feasibility validation template These templates support the workflow planning phase with standardized analysis and design documentation formats. 🤖 Generated with [Claude Code](https://claude.com/claude-code) Co-Authored-By: Claude <noreply@anthropic.com>
This commit is contained in:
catlog22
@@ -0,0 +1,224 @@
|
|||||||
|
Generate ANALYSIS_RESULTS.md with comprehensive solution design and technical analysis.
|
||||||
|
|
||||||
|
## OUTPUT FILE STRUCTURE
|
||||||
|
|
||||||
|
### Required Sections
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# Technical Analysis & Solution Design
|
||||||
|
|
||||||
|
## Executive Summary
|
||||||
|
- **Analysis Focus**: {core_problem_or_improvement_area}
|
||||||
|
- **Analysis Timestamp**: {timestamp}
|
||||||
|
- **Tools Used**: {analysis_tools}
|
||||||
|
- **Overall Assessment**: {feasibility_score}/5 - {recommendation_status}
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 1. Current State Analysis
|
||||||
|
|
||||||
|
### Architecture Overview
|
||||||
|
- **Existing Patterns**: {key_architectural_patterns}
|
||||||
|
- **Code Structure**: {current_codebase_organization}
|
||||||
|
- **Integration Points**: {system_integration_touchpoints}
|
||||||
|
- **Technical Debt Areas**: {identified_debt_with_impact}
|
||||||
|
|
||||||
|
### Compatibility & Dependencies
|
||||||
|
- **Framework Alignment**: {framework_compatibility_assessment}
|
||||||
|
- **Dependency Analysis**: {critical_dependencies_and_risks}
|
||||||
|
- **Migration Considerations**: {backward_compatibility_concerns}
|
||||||
|
|
||||||
|
### Critical Findings
|
||||||
|
- **Strengths**: {what_works_well}
|
||||||
|
- **Gaps**: {missing_capabilities_or_issues}
|
||||||
|
- **Risks**: {identified_technical_and_business_risks}
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 2. Proposed Solution Design
|
||||||
|
|
||||||
|
### Core Architecture Principles
|
||||||
|
- **Design Philosophy**: {key_design_principles}
|
||||||
|
- **Architectural Approach**: {chosen_architectural_pattern_with_rationale}
|
||||||
|
- **Scalability Strategy**: {how_solution_scales}
|
||||||
|
|
||||||
|
### System Design
|
||||||
|
- **Component Architecture**: {high_level_component_design}
|
||||||
|
- **Data Flow**: {data_flow_patterns_and_state_management}
|
||||||
|
- **API Design**: {interface_contracts_and_specifications}
|
||||||
|
- **Integration Strategy**: {how_components_integrate}
|
||||||
|
|
||||||
|
### Key Design Decisions
|
||||||
|
1. **Decision**: {critical_design_choice}
|
||||||
|
- **Rationale**: {why_this_approach}
|
||||||
|
- **Alternatives Considered**: {other_options_and_tradeoffs}
|
||||||
|
- **Impact**: {implications_on_architecture}
|
||||||
|
|
||||||
|
2. **Decision**: {another_critical_choice}
|
||||||
|
- **Rationale**: {reasoning}
|
||||||
|
- **Alternatives Considered**: {tradeoffs}
|
||||||
|
- **Impact**: {consequences}
|
||||||
|
|
||||||
|
### Technical Specifications
|
||||||
|
- **Technology Stack**: {chosen_technologies_with_justification}
|
||||||
|
- **Code Organization**: {module_structure_and_patterns}
|
||||||
|
- **Testing Strategy**: {testing_approach_and_coverage}
|
||||||
|
- **Performance Targets**: {performance_requirements_and_benchmarks}
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 3. Implementation Strategy
|
||||||
|
|
||||||
|
### Development Approach
|
||||||
|
- **Core Implementation Pattern**: {primary_implementation_strategy}
|
||||||
|
- **Module Dependencies**: {dependency_graph_and_order}
|
||||||
|
- **Quality Assurance**: {qa_approach_and_validation}
|
||||||
|
|
||||||
|
### Code Modification Targets
|
||||||
|
**Purpose**: Specific code locations for modification AND new files to create
|
||||||
|
|
||||||
|
**Identified Targets**:
|
||||||
|
1. **Target**: `src/module/File.ts:function:45-52`
|
||||||
|
- **Type**: Modify existing
|
||||||
|
- **Modification**: {what_to_change}
|
||||||
|
- **Rationale**: {why_change_needed}
|
||||||
|
|
||||||
|
2. **Target**: `src/module/NewFile.ts`
|
||||||
|
- **Type**: Create new file
|
||||||
|
- **Purpose**: {file_purpose}
|
||||||
|
- **Rationale**: {why_new_file_needed}
|
||||||
|
|
||||||
|
**Format Rules**:
|
||||||
|
- Existing files: `file:function:lines` (with line numbers)
|
||||||
|
- New files: `file` (no function or lines)
|
||||||
|
- Unknown lines: `file:function:*`
|
||||||
|
|
||||||
|
### Feasibility Assessment
|
||||||
|
- **Technical Complexity**: {complexity_rating_and_analysis}
|
||||||
|
- **Performance Impact**: {expected_performance_characteristics}
|
||||||
|
- **Resource Requirements**: {development_resources_needed}
|
||||||
|
- **Maintenance Burden**: {ongoing_maintenance_considerations}
|
||||||
|
|
||||||
|
### Risk Mitigation
|
||||||
|
- **Technical Risks**: {implementation_risks_and_mitigation}
|
||||||
|
- **Integration Risks**: {compatibility_challenges_and_solutions}
|
||||||
|
- **Performance Risks**: {performance_concerns_and_strategies}
|
||||||
|
- **Security Risks**: {security_vulnerabilities_and_controls}
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 4. Solution Optimization
|
||||||
|
|
||||||
|
### Performance Optimization
|
||||||
|
- **Optimization Strategies**: {key_performance_improvements}
|
||||||
|
- **Caching Strategy**: {caching_approach_and_invalidation}
|
||||||
|
- **Resource Management**: {resource_utilization_optimization}
|
||||||
|
- **Bottleneck Mitigation**: {identified_bottlenecks_and_solutions}
|
||||||
|
|
||||||
|
### Security Enhancements
|
||||||
|
- **Security Model**: {authentication_authorization_approach}
|
||||||
|
- **Data Protection**: {data_security_and_encryption}
|
||||||
|
- **Vulnerability Mitigation**: {known_vulnerabilities_and_controls}
|
||||||
|
- **Compliance**: {regulatory_and_compliance_considerations}
|
||||||
|
|
||||||
|
### Code Quality
|
||||||
|
- **Code Standards**: {coding_conventions_and_patterns}
|
||||||
|
- **Testing Coverage**: {test_strategy_and_coverage_goals}
|
||||||
|
- **Documentation**: {documentation_requirements}
|
||||||
|
- **Maintainability**: {maintainability_practices}
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 5. Critical Success Factors
|
||||||
|
|
||||||
|
### Technical Requirements
|
||||||
|
- **Must Have**: {essential_technical_capabilities}
|
||||||
|
- **Should Have**: {important_but_not_critical_features}
|
||||||
|
- **Nice to Have**: {optional_enhancements}
|
||||||
|
|
||||||
|
### Quality Metrics
|
||||||
|
- **Performance Benchmarks**: {measurable_performance_targets}
|
||||||
|
- **Code Quality Standards**: {quality_metrics_and_thresholds}
|
||||||
|
- **Test Coverage Goals**: {testing_coverage_requirements}
|
||||||
|
- **Security Standards**: {security_compliance_requirements}
|
||||||
|
|
||||||
|
### Success Validation
|
||||||
|
- **Acceptance Criteria**: {how_to_validate_success}
|
||||||
|
- **Testing Strategy**: {validation_testing_approach}
|
||||||
|
- **Monitoring Plan**: {production_monitoring_strategy}
|
||||||
|
- **Rollback Plan**: {failure_recovery_strategy}
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 6. Analysis Confidence & Recommendations
|
||||||
|
|
||||||
|
### Assessment Scores
|
||||||
|
- **Conceptual Integrity**: {score}/5 - {brief_assessment}
|
||||||
|
- **Architectural Soundness**: {score}/5 - {brief_assessment}
|
||||||
|
- **Technical Feasibility**: {score}/5 - {brief_assessment}
|
||||||
|
- **Implementation Readiness**: {score}/5 - {brief_assessment}
|
||||||
|
- **Overall Confidence**: {overall_score}/5
|
||||||
|
|
||||||
|
### Final Recommendation
|
||||||
|
**Status**: {PROCEED|PROCEED_WITH_MODIFICATIONS|RECONSIDER|REJECT}
|
||||||
|
|
||||||
|
**Rationale**: {clear_explanation_of_recommendation}
|
||||||
|
|
||||||
|
**Critical Prerequisites**: {what_must_be_resolved_before_proceeding}
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 7. Reference Information
|
||||||
|
|
||||||
|
### Tool Analysis Summary
|
||||||
|
- **Gemini Insights**: {key_architectural_and_pattern_insights}
|
||||||
|
- **Codex Validation**: {technical_feasibility_and_implementation_notes}
|
||||||
|
- **Consensus Points**: {agreements_between_tools}
|
||||||
|
- **Conflicting Views**: {disagreements_and_resolution}
|
||||||
|
|
||||||
|
### Context & Resources
|
||||||
|
- **Analysis Context**: {context_package_reference}
|
||||||
|
- **Documentation References**: {relevant_documentation}
|
||||||
|
- **Related Patterns**: {similar_implementations_in_codebase}
|
||||||
|
- **External Resources**: {external_references_and_best_practices}
|
||||||
|
```
|
||||||
|
|
||||||
|
## CONTENT REQUIREMENTS
|
||||||
|
|
||||||
|
### Analysis Priority Sources
|
||||||
|
1. **PRIMARY**: Individual role analysis.md files (system-architect, ui-designer, etc.) - technical details, ADRs, decision context
|
||||||
|
2. **SECONDARY**: synthesis-specification.md - integrated requirements, cross-role alignment
|
||||||
|
3. **REFERENCE**: topic-framework.md - discussion context
|
||||||
|
|
||||||
|
### Focus Areas
|
||||||
|
- **SOLUTION IMPROVEMENTS**: How to enhance current design
|
||||||
|
- **KEY DESIGN DECISIONS**: Critical choices with rationale, alternatives, tradeoffs
|
||||||
|
- **CRITICAL INSIGHTS**: Non-obvious findings, risks, opportunities
|
||||||
|
- **OPTIMIZATION**: Performance, security, code quality recommendations
|
||||||
|
|
||||||
|
### Exclusions
|
||||||
|
- ❌ Task lists or implementation steps
|
||||||
|
- ❌ Code examples or snippets
|
||||||
|
- ❌ Project management timelines
|
||||||
|
- ❌ Resource allocation details
|
||||||
|
|
||||||
|
## OUTPUT VALIDATION
|
||||||
|
|
||||||
|
### Completeness Checklist
|
||||||
|
□ All 7 sections present with content
|
||||||
|
□ Executive Summary with feasibility score
|
||||||
|
□ Current State Analysis with findings
|
||||||
|
□ Solution Design with 2+ key decisions
|
||||||
|
□ Implementation Strategy with code targets
|
||||||
|
□ Optimization recommendations in 3 areas
|
||||||
|
□ Confidence scores with final recommendation
|
||||||
|
□ Reference information included
|
||||||
|
|
||||||
|
### Quality Standards
|
||||||
|
□ Design decisions include rationale and alternatives
|
||||||
|
□ Code targets specify file:function:lines format
|
||||||
|
□ Risk assessment with mitigation strategies
|
||||||
|
□ Quantified scores (X/5) for all assessments
|
||||||
|
□ Clear PROCEED/RECONSIDER/REJECT recommendation
|
||||||
|
|
||||||
|
Focus: Solution-focused technical analysis emphasizing design decisions and critical insights.
|
||||||
@@ -0,0 +1,176 @@
|
|||||||
|
Validate technical feasibility and identify implementation risks for proposed solution design.
|
||||||
|
|
||||||
|
## CORE CHECKLIST ⚡
|
||||||
|
□ Read context-package.json and gemini-solution-design.md
|
||||||
|
□ Assess complexity, validate technology choices
|
||||||
|
□ Evaluate performance and security implications
|
||||||
|
□ Focus on TECHNICAL FEASIBILITY and RISK ASSESSMENT
|
||||||
|
□ Write output to specified .workflow/{session_id}/.process/ path
|
||||||
|
|
||||||
|
## PREREQUISITE ANALYSIS
|
||||||
|
|
||||||
|
### Required Input Files
|
||||||
|
1. **context-package.json**: Task requirements, source files, tech stack
|
||||||
|
2. **gemini-solution-design.md**: Proposed solution design and architecture
|
||||||
|
3. **workflow-session.json**: Session state and context
|
||||||
|
4. **CLAUDE.md**: Project standards and conventions
|
||||||
|
|
||||||
|
### Analysis Dependencies
|
||||||
|
- Review Gemini's proposed solution design
|
||||||
|
- Validate against actual codebase capabilities
|
||||||
|
- Assess implementation complexity realistically
|
||||||
|
- Identify gaps between design and execution
|
||||||
|
|
||||||
|
## REQUIRED VALIDATION
|
||||||
|
|
||||||
|
### 1. Feasibility Assessment
|
||||||
|
- **Complexity Rating**: Rate technical complexity (1-5 scale)
|
||||||
|
- 1: Trivial - straightforward implementation
|
||||||
|
- 2: Simple - well-known patterns
|
||||||
|
- 3: Moderate - some challenges
|
||||||
|
- 4: Complex - significant challenges
|
||||||
|
- 5: Very Complex - high risk, major unknowns
|
||||||
|
|
||||||
|
- **Resource Requirements**: Estimate development effort
|
||||||
|
- Development time (hours/days/weeks)
|
||||||
|
- Required expertise level
|
||||||
|
- Infrastructure needs
|
||||||
|
|
||||||
|
- **Technology Compatibility**: Validate proposed tech stack
|
||||||
|
- Framework version compatibility
|
||||||
|
- Library maturity and support
|
||||||
|
- Integration with existing systems
|
||||||
|
|
||||||
|
### 2. Risk Analysis
|
||||||
|
- **Implementation Risks**: Technical challenges and blockers
|
||||||
|
- Unknown implementation patterns
|
||||||
|
- Missing capabilities or APIs
|
||||||
|
- Breaking changes to existing code
|
||||||
|
|
||||||
|
- **Integration Challenges**: System integration concerns
|
||||||
|
- Data format compatibility
|
||||||
|
- API contract changes
|
||||||
|
- Dependency conflicts
|
||||||
|
|
||||||
|
- **Performance Concerns**: Performance and scalability risks
|
||||||
|
- Resource consumption (CPU, memory, I/O)
|
||||||
|
- Latency and throughput impact
|
||||||
|
- Caching and optimization needs
|
||||||
|
|
||||||
|
- **Security Concerns**: Security vulnerabilities and threats
|
||||||
|
- Authentication/authorization gaps
|
||||||
|
- Data exposure risks
|
||||||
|
- Compliance violations
|
||||||
|
|
||||||
|
### 3. Implementation Validation
|
||||||
|
- **Development Approach**: Validate proposed implementation strategy
|
||||||
|
- Verify module dependency order
|
||||||
|
- Assess incremental development feasibility
|
||||||
|
- Evaluate testing approach
|
||||||
|
|
||||||
|
- **Quality Standards**: Validate quality requirements
|
||||||
|
- Test coverage achievability
|
||||||
|
- Performance benchmark realism
|
||||||
|
- Documentation completeness
|
||||||
|
|
||||||
|
- **Maintenance Implications**: Long-term sustainability
|
||||||
|
- Code maintainability assessment
|
||||||
|
- Technical debt evaluation
|
||||||
|
- Evolution and extensibility
|
||||||
|
|
||||||
|
### 4. Code Target Verification
|
||||||
|
Review Gemini's proposed code targets:
|
||||||
|
- **Validate existing targets**: Confirm file:function:lines exist
|
||||||
|
- **Assess new file targets**: Evaluate necessity and placement
|
||||||
|
- **Identify missing targets**: Suggest additional modification points
|
||||||
|
- **Refine target specifications**: Provide more precise line numbers if possible
|
||||||
|
|
||||||
|
### 5. Recommendations
|
||||||
|
- **Must-Have Requirements**: Critical requirements for success
|
||||||
|
- **Optimization Opportunities**: Performance and quality improvements
|
||||||
|
- **Security Controls**: Essential security measures
|
||||||
|
- **Risk Mitigation**: Strategies to reduce identified risks
|
||||||
|
|
||||||
|
## OUTPUT REQUIREMENTS
|
||||||
|
|
||||||
|
### Output File
|
||||||
|
**Path**: `.workflow/{session_id}/.process/codex-feasibility-validation.md`
|
||||||
|
**Format**: Follow structure from `~/.claude/workflows/cli-templates/prompts/workflow/analysis-results-structure.txt`
|
||||||
|
|
||||||
|
### Required Sections
|
||||||
|
Focus on these sections from the template:
|
||||||
|
- Executive Summary (with Codex perspective)
|
||||||
|
- Current State Analysis (validation findings)
|
||||||
|
- Implementation Strategy (feasibility assessment)
|
||||||
|
- Solution Optimization (risk mitigation)
|
||||||
|
- Confidence Scores (technical feasibility focus)
|
||||||
|
|
||||||
|
### Content Guidelines
|
||||||
|
- ✅ Focus on technical feasibility and risk assessment
|
||||||
|
- ✅ Verify code targets from Gemini's design
|
||||||
|
- ✅ Provide concrete risk mitigation strategies
|
||||||
|
- ✅ Quantify complexity and effort estimates
|
||||||
|
- ❌ Do NOT create task breakdowns
|
||||||
|
- ❌ Do NOT provide step-by-step implementation guides
|
||||||
|
- ❌ Do NOT include code examples
|
||||||
|
|
||||||
|
## VALIDATION METHODOLOGY
|
||||||
|
|
||||||
|
### Complexity Scoring
|
||||||
|
Rate each aspect on 1-5 scale:
|
||||||
|
- Technical Complexity
|
||||||
|
- Integration Complexity
|
||||||
|
- Performance Risk
|
||||||
|
- Security Risk
|
||||||
|
- Maintenance Burden
|
||||||
|
|
||||||
|
### Risk Classification
|
||||||
|
- **LOW**: Minor issues, easily addressable
|
||||||
|
- **MEDIUM**: Manageable challenges with clear mitigation
|
||||||
|
- **HIGH**: Significant concerns requiring major mitigation
|
||||||
|
- **CRITICAL**: Fundamental viability threats
|
||||||
|
|
||||||
|
### Feasibility Judgment
|
||||||
|
- **PROCEED**: Technically feasible with acceptable risk
|
||||||
|
- **PROCEED_WITH_MODIFICATIONS**: Feasible but needs adjustments
|
||||||
|
- **RECONSIDER**: High risk, major changes needed
|
||||||
|
- **REJECT**: Not feasible with current approach
|
||||||
|
|
||||||
|
## CONTEXT INTEGRATION
|
||||||
|
|
||||||
|
### Gemini Analysis Integration
|
||||||
|
- Review proposed architecture and design decisions
|
||||||
|
- Validate assumptions and technology choices
|
||||||
|
- Cross-check code targets against actual codebase
|
||||||
|
- Assess realism of performance targets
|
||||||
|
|
||||||
|
### Codebase Reality Check
|
||||||
|
- Verify existing code capabilities
|
||||||
|
- Identify actual technical constraints
|
||||||
|
- Assess team skill compatibility
|
||||||
|
- Evaluate infrastructure readiness
|
||||||
|
|
||||||
|
### Session Context
|
||||||
|
- Consider session history and previous decisions
|
||||||
|
- Align with project architecture standards
|
||||||
|
- Respect existing patterns and conventions
|
||||||
|
|
||||||
|
## EXECUTION MODE
|
||||||
|
|
||||||
|
**Mode**: Analysis with write permission for output file
|
||||||
|
**CLI Tool**: Codex with --skip-git-repo-check -s danger-full-access
|
||||||
|
**Timeout**: 60-90 minutes for complex tasks
|
||||||
|
**Output**: Single file codex-feasibility-validation.md
|
||||||
|
**Trigger**: Only for complex tasks (>6 modules)
|
||||||
|
|
||||||
|
## VERIFICATION CHECKLIST ✓
|
||||||
|
□ context-package.json and gemini-solution-design.md read
|
||||||
|
□ Complexity rated on 1-5 scale with justification
|
||||||
|
□ All risk categories assessed (technical, integration, performance, security)
|
||||||
|
□ Code targets verified and refined
|
||||||
|
□ Risk mitigation strategies provided
|
||||||
|
□ Resource requirements estimated
|
||||||
|
□ Final feasibility judgment (PROCEED/RECONSIDER/REJECT)
|
||||||
|
□ Output written to .workflow/{session_id}/.process/codex-feasibility-validation.md
|
||||||
|
|
||||||
|
Focus: Technical feasibility validation with realistic risk assessment and mitigation strategies.
|
||||||
@@ -0,0 +1,131 @@
|
|||||||
|
Analyze and design optimal solution with comprehensive architecture evaluation and design decisions.
|
||||||
|
|
||||||
|
## CORE CHECKLIST ⚡
|
||||||
|
□ Read context-package.json to understand task requirements, source files, tech stack
|
||||||
|
□ Analyze current architecture patterns and code structure
|
||||||
|
□ Propose solution design with key decisions and rationale
|
||||||
|
□ Focus on SOLUTION IMPROVEMENTS and KEY DESIGN DECISIONS
|
||||||
|
□ Write output to specified .workflow/{session_id}/.process/ path
|
||||||
|
|
||||||
|
## ANALYSIS PRIORITY
|
||||||
|
|
||||||
|
### Source Hierarchy
|
||||||
|
1. **PRIMARY**: Individual role analysis.md files (system-architect, ui-designer, data-architect, etc.)
|
||||||
|
- Technical details and implementation considerations
|
||||||
|
- Architecture Decision Records (ADRs)
|
||||||
|
- Design decision context and rationale
|
||||||
|
|
||||||
|
2. **SECONDARY**: synthesis-specification.md
|
||||||
|
- Integrated requirements across roles
|
||||||
|
- Cross-role alignment and dependencies
|
||||||
|
- Unified feature specifications
|
||||||
|
|
||||||
|
3. **REFERENCE**: topic-framework.md
|
||||||
|
- Discussion context and background
|
||||||
|
- Initial problem framing
|
||||||
|
|
||||||
|
## REQUIRED ANALYSIS
|
||||||
|
|
||||||
|
### 1. Current State Assessment
|
||||||
|
- Identify existing architectural patterns and code structure
|
||||||
|
- Map integration points and dependencies
|
||||||
|
- Evaluate technical debt and pain points
|
||||||
|
- Assess framework compatibility and constraints
|
||||||
|
|
||||||
|
### 2. Solution Design
|
||||||
|
- Propose core architecture principles and approach
|
||||||
|
- Design component architecture and data flow
|
||||||
|
- Specify API contracts and integration strategy
|
||||||
|
- Define technology stack with justification
|
||||||
|
|
||||||
|
### 3. Key Design Decisions
|
||||||
|
For each critical decision:
|
||||||
|
- **Decision**: What is being decided
|
||||||
|
- **Rationale**: Why this approach
|
||||||
|
- **Alternatives Considered**: Other options and their tradeoffs
|
||||||
|
- **Impact**: Implications on architecture, performance, maintainability
|
||||||
|
|
||||||
|
Minimum 2 key decisions required.
|
||||||
|
|
||||||
|
### 4. Code Modification Targets
|
||||||
|
Identify specific code locations for changes:
|
||||||
|
- **Existing files**: `file:function:lines` format (e.g., `src/auth/login.ts:validateUser:45-52`)
|
||||||
|
- **New files**: `file` only (e.g., `src/auth/PasswordReset.ts`)
|
||||||
|
- **Unknown lines**: `file:function:*` (e.g., `src/auth/service.ts:refreshToken:*`)
|
||||||
|
|
||||||
|
For each target:
|
||||||
|
- Type: Modify existing | Create new
|
||||||
|
- Modification/Purpose: What changes needed
|
||||||
|
- Rationale: Why this target
|
||||||
|
|
||||||
|
### 5. Critical Insights
|
||||||
|
- Strengths: What works well in current/proposed design
|
||||||
|
- Gaps: Missing capabilities or concerns
|
||||||
|
- Risks: Technical, integration, performance, security
|
||||||
|
- Optimization Opportunities: Performance, security, code quality
|
||||||
|
|
||||||
|
### 6. Feasibility Assessment
|
||||||
|
- Technical Complexity: Rating and analysis
|
||||||
|
- Performance Impact: Expected characteristics
|
||||||
|
- Resource Requirements: Development effort
|
||||||
|
- Maintenance Burden: Ongoing considerations
|
||||||
|
|
||||||
|
## OUTPUT REQUIREMENTS
|
||||||
|
|
||||||
|
### Output File
|
||||||
|
**Path**: `.workflow/{session_id}/.process/gemini-solution-design.md`
|
||||||
|
**Format**: Follow structure from `~/.claude/workflows/cli-templates/prompts/workflow/analysis-results-structure.txt`
|
||||||
|
|
||||||
|
### Required Sections
|
||||||
|
- Executive Summary with feasibility score
|
||||||
|
- Current State Analysis
|
||||||
|
- Proposed Solution Design with 2+ key decisions
|
||||||
|
- Implementation Strategy with code targets
|
||||||
|
- Solution Optimization (performance, security, quality)
|
||||||
|
- Critical Success Factors
|
||||||
|
- Confidence Scores with recommendation
|
||||||
|
|
||||||
|
### Content Guidelines
|
||||||
|
- ✅ Focus on solution improvements and key design decisions
|
||||||
|
- ✅ Include rationale, alternatives, and tradeoffs for decisions
|
||||||
|
- ✅ Provide specific code targets in correct format
|
||||||
|
- ✅ Quantify assessments with scores (X/5)
|
||||||
|
- ❌ Do NOT create task lists or implementation steps
|
||||||
|
- ❌ Do NOT include code examples or snippets
|
||||||
|
- ❌ Do NOT create project management timelines
|
||||||
|
|
||||||
|
## CONTEXT INTEGRATION
|
||||||
|
|
||||||
|
### Session Context
|
||||||
|
- Load context-package.json for task requirements
|
||||||
|
- Reference workflow-session.json for session state
|
||||||
|
- Review CLAUDE.md for project standards
|
||||||
|
|
||||||
|
### Brainstorm Context
|
||||||
|
If brainstorming artifacts exist:
|
||||||
|
- Prioritize individual role analysis.md files
|
||||||
|
- Use synthesis-specification.md for integrated view
|
||||||
|
- Reference topic-framework.md for context
|
||||||
|
|
||||||
|
### Codebase Context
|
||||||
|
- Identify similar patterns in existing code
|
||||||
|
- Evaluate success/failure of current approaches
|
||||||
|
- Ensure consistency with project architecture
|
||||||
|
|
||||||
|
## EXECUTION MODE
|
||||||
|
|
||||||
|
**Mode**: Analysis with write permission for output file
|
||||||
|
**CLI Tool**: Gemini wrapper with --approval-mode yolo
|
||||||
|
**Timeout**: 40-60 minutes based on complexity
|
||||||
|
**Output**: Single file gemini-solution-design.md
|
||||||
|
|
||||||
|
## VERIFICATION CHECKLIST ✓
|
||||||
|
□ context-package.json read and analyzed
|
||||||
|
□ All 7 required sections present in output
|
||||||
|
□ 2+ key design decisions with rationale and alternatives
|
||||||
|
□ Code targets specified in correct format
|
||||||
|
□ Feasibility scores provided (X/5)
|
||||||
|
□ Final recommendation (PROCEED/RECONSIDER/REJECT)
|
||||||
|
□ Output written to .workflow/{session_id}/.process/gemini-solution-design.md
|
||||||
|
|
||||||
|
Focus: Comprehensive solution design emphasizing architecture decisions and critical insights.
|
||||||
Reference in New Issue
Block a user