mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-05 01:50:27 +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