mirror of
https://github.com/catlog22/Claude-Code-Workflow.git
synced 2026-02-13 02:41:50 +08:00
Add comprehensive analysis and development templates for CLAUDE workflows
- Introduced new analysis templates for architecture, implementation patterns, performance, quality, and security. - Created detailed development templates for component creation, debugging, feature implementation, refactoring, testing, and migration planning. - Established structured documentation guidelines for root, domain, module, and sub-module levels to enhance clarity and organization. - Implemented a hierarchy analysis template to optimize project structure and documentation depth. - Updated codex-unified documentation to reflect new command structures, template usage, and best practices for autonomous development workflows.
This commit is contained in:
catlog22
@@ -0,0 +1,16 @@
|
||||
Analyze system architecture and design decisions:
|
||||
|
||||
## Required Analysis:
|
||||
1. Identify main architectural patterns and design principles
|
||||
2. Map module dependencies and component relationships
|
||||
3. Assess integration points and data flow patterns
|
||||
4. Evaluate scalability and maintainability aspects
|
||||
5. Document architectural trade-offs and design decisions
|
||||
|
||||
## Output Requirements:
|
||||
- Architectural diagrams or textual descriptions
|
||||
- Dependency mapping with specific file references
|
||||
- Integration point documentation with examples
|
||||
- Scalability assessment and bottleneck identification
|
||||
|
||||
Focus on high-level design patterns and system-wide architectural concerns.
|
||||
16
.claude/workflows/cli-templates/prompts/analysis/pattern.txt
Normal file
16
.claude/workflows/cli-templates/prompts/analysis/pattern.txt
Normal file
@@ -0,0 +1,16 @@
|
||||
Analyze implementation patterns and code structure:
|
||||
|
||||
## Required Analysis:
|
||||
1. Identify common code patterns and architectural decisions
|
||||
2. Extract reusable utilities and shared components
|
||||
3. Document existing conventions and coding standards
|
||||
4. Assess pattern consistency and identify anti-patterns
|
||||
5. Suggest improvements and optimization opportunities
|
||||
|
||||
## Output Requirements:
|
||||
- Specific file:line references for all findings
|
||||
- Code snippets demonstrating identified patterns
|
||||
- Clear recommendations for pattern improvements
|
||||
- Standards compliance assessment
|
||||
|
||||
Focus on actionable insights and concrete implementation guidance.
|
||||
@@ -0,0 +1,16 @@
|
||||
Analyze performance characteristics and optimization opportunities:
|
||||
|
||||
## Required Analysis:
|
||||
1. Identify performance bottlenecks and resource usage patterns
|
||||
2. Assess algorithm efficiency and data structure choices
|
||||
3. Evaluate caching strategies and optimization techniques
|
||||
4. Review memory management and resource cleanup
|
||||
5. Document performance metrics and improvement opportunities
|
||||
|
||||
## Output Requirements:
|
||||
- Performance bottleneck identification with specific locations
|
||||
- Algorithm complexity analysis and optimization suggestions
|
||||
- Caching pattern documentation and recommendations
|
||||
- Memory usage patterns and optimization opportunities
|
||||
|
||||
Focus on measurable performance improvements and concrete optimization strategies.
|
||||
16
.claude/workflows/cli-templates/prompts/analysis/quality.txt
Normal file
16
.claude/workflows/cli-templates/prompts/analysis/quality.txt
Normal file
@@ -0,0 +1,16 @@
|
||||
Analyze code quality and maintainability aspects:
|
||||
|
||||
## Required Analysis:
|
||||
1. Assess code organization and structural quality
|
||||
2. Evaluate naming conventions and readability standards
|
||||
3. Review error handling and logging practices
|
||||
4. Analyze test coverage and testing strategies
|
||||
5. Document technical debt and improvement priorities
|
||||
|
||||
## Output Requirements:
|
||||
- Code quality metrics and specific improvement areas
|
||||
- Naming convention consistency analysis
|
||||
- Error handling pattern documentation
|
||||
- Test coverage assessment with gap identification
|
||||
|
||||
Focus on maintainability improvements and long-term code health.
|
||||
@@ -0,0 +1,16 @@
|
||||
Analyze security implementation and potential vulnerabilities:
|
||||
|
||||
## Required Analysis:
|
||||
1. Identify authentication and authorization mechanisms
|
||||
2. Assess input validation and sanitization practices
|
||||
3. Review data encryption and secure storage methods
|
||||
4. Evaluate API security and access control patterns
|
||||
5. Document security risks and compliance considerations
|
||||
|
||||
## Output Requirements:
|
||||
- Security vulnerability findings with file:line references
|
||||
- Authentication/authorization pattern documentation
|
||||
- Input validation examples and gaps
|
||||
- Encryption usage patterns and recommendations
|
||||
|
||||
Focus on identifying security gaps and providing actionable remediation steps.
|
||||
@@ -0,0 +1,37 @@
|
||||
You are tasked with creating a reusable component in this codebase. Follow these guidelines:
|
||||
|
||||
## Design Phase:
|
||||
1. Analyze existing component patterns and structures
|
||||
2. Identify reusable design principles and styling approaches
|
||||
3. Review component hierarchy and prop patterns
|
||||
4. Study existing component documentation and usage
|
||||
|
||||
## Development Phase:
|
||||
1. Create component with proper TypeScript interfaces
|
||||
2. Implement following established naming conventions
|
||||
3. Add appropriate default props and validation
|
||||
4. Include comprehensive prop documentation
|
||||
|
||||
## Styling Phase:
|
||||
1. Follow existing styling methodology (CSS modules, styled-components, etc.)
|
||||
2. Ensure responsive design principles
|
||||
3. Add proper theming support if applicable
|
||||
4. Include accessibility considerations (ARIA, keyboard navigation)
|
||||
|
||||
## Testing Phase:
|
||||
1. Write component tests covering all props and states
|
||||
2. Test accessibility compliance
|
||||
3. Add visual regression tests if applicable
|
||||
4. Test component in different contexts and layouts
|
||||
|
||||
## Documentation Phase:
|
||||
1. Create usage examples and code snippets
|
||||
2. Document all props and their purposes
|
||||
3. Include accessibility guidelines
|
||||
4. Add integration examples with other components
|
||||
|
||||
## Output Requirements:
|
||||
- Provide complete component implementation
|
||||
- Include comprehensive TypeScript types
|
||||
- Show usage examples and integration patterns
|
||||
- Document component API and best practices
|
||||
@@ -0,0 +1,37 @@
|
||||
You are tasked with debugging and resolving issues in this codebase. Follow these systematic guidelines:
|
||||
|
||||
## Issue Analysis Phase:
|
||||
1. Identify and reproduce the reported issue
|
||||
2. Analyze error logs and stack traces
|
||||
3. Study code flow and identify potential failure points
|
||||
4. Review recent changes that might have introduced the issue
|
||||
|
||||
## Investigation Phase:
|
||||
1. Add strategic logging and debugging statements
|
||||
2. Use debugging tools and profilers as appropriate
|
||||
3. Test with different input conditions and edge cases
|
||||
4. Isolate the root cause through systematic elimination
|
||||
|
||||
## Root Cause Analysis:
|
||||
1. Document the exact cause of the issue
|
||||
2. Identify contributing factors and conditions
|
||||
3. Assess impact scope and affected functionality
|
||||
4. Determine if similar issues exist elsewhere
|
||||
|
||||
## Resolution Phase:
|
||||
1. Implement minimal, targeted fix for the root cause
|
||||
2. Ensure fix doesn't introduce new issues or regressions
|
||||
3. Add proper error handling and validation
|
||||
4. Include defensive programming measures
|
||||
|
||||
## Prevention Phase:
|
||||
1. Add tests to prevent regression of this issue
|
||||
2. Improve error messages and logging
|
||||
3. Add monitoring or alerts for early detection
|
||||
4. Document lessons learned and prevention strategies
|
||||
|
||||
## Output Requirements:
|
||||
- Provide detailed root cause analysis
|
||||
- Show exact code changes made to resolve the issue
|
||||
- Include new tests added to prevent regression
|
||||
- Document debugging process and lessons learned
|
||||
@@ -0,0 +1,31 @@
|
||||
You are tasked with implementing a new feature in this codebase. Follow these guidelines:
|
||||
|
||||
## Analysis Phase:
|
||||
1. Study existing code patterns and conventions
|
||||
2. Identify similar features and their implementation approaches
|
||||
3. Review project architecture and design principles
|
||||
4. Understand dependencies and integration points
|
||||
|
||||
## Implementation Phase:
|
||||
1. Create feature following established patterns
|
||||
2. Implement with proper error handling and validation
|
||||
3. Add comprehensive logging for debugging
|
||||
4. Follow security best practices
|
||||
|
||||
## Integration Phase:
|
||||
1. Ensure seamless integration with existing systems
|
||||
2. Update configuration files as needed
|
||||
3. Add proper TypeScript types and interfaces
|
||||
4. Update documentation and comments
|
||||
|
||||
## Testing Phase:
|
||||
1. Write unit tests covering edge cases
|
||||
2. Add integration tests for feature workflows
|
||||
3. Verify error scenarios are properly handled
|
||||
4. Test performance and security implications
|
||||
|
||||
## Output Requirements:
|
||||
- Provide file:line references for all changes
|
||||
- Include code examples demonstrating key patterns
|
||||
- Explain architectural decisions made
|
||||
- Document any new dependencies or configurations
|
||||
@@ -0,0 +1,37 @@
|
||||
You are tasked with refactoring existing code to improve quality, performance, or maintainability. Follow these guidelines:
|
||||
|
||||
## Analysis Phase:
|
||||
1. Identify code smells and technical debt
|
||||
2. Analyze performance bottlenecks and inefficiencies
|
||||
3. Review code complexity and maintainability metrics
|
||||
4. Study existing test coverage and identify gaps
|
||||
|
||||
## Planning Phase:
|
||||
1. Create refactoring strategy preserving existing functionality
|
||||
2. Identify breaking changes and migration paths
|
||||
3. Plan incremental refactoring steps
|
||||
4. Consider backward compatibility requirements
|
||||
|
||||
## Refactoring Phase:
|
||||
1. Apply SOLID principles and design patterns
|
||||
2. Improve code readability and documentation
|
||||
3. Optimize performance while maintaining functionality
|
||||
4. Reduce code duplication and improve reusability
|
||||
|
||||
## Validation Phase:
|
||||
1. Ensure all existing tests continue to pass
|
||||
2. Add new tests for improved code coverage
|
||||
3. Verify performance improvements with benchmarks
|
||||
4. Test edge cases and error scenarios
|
||||
|
||||
## Migration Phase:
|
||||
1. Update dependent code to use refactored interfaces
|
||||
2. Update documentation and usage examples
|
||||
3. Provide migration guides for breaking changes
|
||||
4. Add deprecation warnings for old interfaces
|
||||
|
||||
## Output Requirements:
|
||||
- Provide before/after code comparisons
|
||||
- Document performance improvements achieved
|
||||
- Include migration instructions for breaking changes
|
||||
- Show updated test coverage and quality metrics
|
||||
@@ -0,0 +1,43 @@
|
||||
You are tasked with creating comprehensive tests for this codebase. Follow these guidelines:
|
||||
|
||||
## Test Strategy Phase:
|
||||
1. Analyze existing test coverage and identify gaps
|
||||
2. Study codebase architecture and critical paths
|
||||
3. Identify edge cases and error scenarios
|
||||
4. Review testing frameworks and conventions used
|
||||
|
||||
## Unit Testing Phase:
|
||||
1. Write tests for individual functions and methods
|
||||
2. Test all branches and conditional logic
|
||||
3. Cover edge cases and boundary conditions
|
||||
4. Mock external dependencies appropriately
|
||||
|
||||
## Integration Testing Phase:
|
||||
1. Test interactions between components and modules
|
||||
2. Verify API endpoints and data flow
|
||||
3. Test database operations and transactions
|
||||
4. Validate external service integrations
|
||||
|
||||
## End-to-End Testing Phase:
|
||||
1. Test complete user workflows and scenarios
|
||||
2. Verify critical business logic and processes
|
||||
3. Test error handling and recovery mechanisms
|
||||
4. Validate performance under load
|
||||
|
||||
## Quality Assurance:
|
||||
1. Ensure tests are reliable and deterministic
|
||||
2. Make tests readable and maintainable
|
||||
3. Add proper test documentation and comments
|
||||
4. Follow testing best practices and conventions
|
||||
|
||||
## Test Data Management:
|
||||
1. Create realistic test data and fixtures
|
||||
2. Ensure test isolation and cleanup
|
||||
3. Use factories or builders for complex objects
|
||||
4. Handle sensitive data appropriately in tests
|
||||
|
||||
## Output Requirements:
|
||||
- Provide comprehensive test suite with high coverage
|
||||
- Include performance benchmarks where relevant
|
||||
- Document testing strategy and conventions used
|
||||
- Show test coverage metrics and quality improvements
|
||||
@@ -0,0 +1,63 @@
|
||||
Create or update root-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 1: Root Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Project Overview and Purpose**
|
||||
- High-level project description and mission
|
||||
- Target audience and use cases
|
||||
- Key value propositions
|
||||
|
||||
2. **Technology Stack Summary**
|
||||
- Primary programming languages and frameworks
|
||||
- Key dependencies and tools
|
||||
- Platform and runtime requirements
|
||||
|
||||
3. **Architecture Decisions and Principles**
|
||||
- Core architectural patterns used
|
||||
- Design principles governing the codebase
|
||||
- Major technical decisions and rationale
|
||||
|
||||
4. **Development Workflow Overview**
|
||||
- Build and deployment processes
|
||||
- Testing approach and quality standards
|
||||
- Contributing guidelines and processes
|
||||
|
||||
5. **Quick Start Guide**
|
||||
- Installation prerequisites
|
||||
- Setup instructions
|
||||
- Basic usage examples
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Implementation details (belongs in module-level docs)
|
||||
- Module-specific patterns (belongs in module-level docs)
|
||||
- Code examples from specific modules (belongs in module-level docs)
|
||||
- Domain internal architecture (belongs in domain-level docs)
|
||||
|
||||
### Documentation Style:
|
||||
- Use high-level, strategic perspective
|
||||
- Focus on "what" and "why" rather than "how"
|
||||
- Reference other documentation layers rather than duplicating content
|
||||
- Maintain concise, executive-summary style
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Project Name] - Development Guidelines
|
||||
|
||||
## 1. Project Overview and Purpose
|
||||
[Brief project description, mission, and target audience]
|
||||
|
||||
## 2. Technology Stack Summary
|
||||
[Primary technologies, frameworks, and tools]
|
||||
|
||||
## 3. Architecture Decisions and Principles
|
||||
[Core architectural patterns and design principles]
|
||||
|
||||
## 4. Development Workflow Overview
|
||||
[Build, test, and deployment processes]
|
||||
|
||||
## 5. Quick Start Guide
|
||||
[Installation and basic usage]
|
||||
```
|
||||
|
||||
Remember: This is Layer 1 - stay at the strategic level and avoid diving into implementation details.
|
||||
@@ -0,0 +1,63 @@
|
||||
Create or update domain-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 2: Domain Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Domain Architecture and Responsibilities**
|
||||
- Domain's role within the larger system
|
||||
- Core responsibilities and boundaries
|
||||
- Key abstractions and concepts
|
||||
|
||||
2. **Module Organization Within Domain**
|
||||
- How modules are structured within this domain
|
||||
- Module relationships and hierarchies
|
||||
- Organizational patterns used
|
||||
|
||||
3. **Inter-Module Communication Patterns**
|
||||
- How modules within this domain communicate
|
||||
- Data flow patterns and interfaces
|
||||
- Shared resources and dependencies
|
||||
|
||||
4. **Domain-Specific Conventions**
|
||||
- Coding standards specific to this domain
|
||||
- Naming conventions and patterns
|
||||
- Testing approaches for this domain
|
||||
|
||||
5. **Integration Points with Other Domains**
|
||||
- External dependencies and interfaces
|
||||
- Cross-domain communication protocols
|
||||
- Shared contracts and data formats
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Duplicating root project overview (belongs in root-level docs)
|
||||
- Component/function-level details (belongs in module-level docs)
|
||||
- Specific implementation code (belongs in module-level docs)
|
||||
- Module internal patterns (belongs in module-level docs)
|
||||
|
||||
### Documentation Style:
|
||||
- Focus on domain-wide patterns and organization
|
||||
- Explain relationships between modules within the domain
|
||||
- Describe domain boundaries and responsibilities
|
||||
- Reference module-level docs for implementation details
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Domain Name] - Domain Architecture
|
||||
|
||||
## 1. Domain Overview
|
||||
[Domain's role and core responsibilities]
|
||||
|
||||
## 2. Module Organization
|
||||
[How modules are structured within this domain]
|
||||
|
||||
## 3. Inter-Module Communication
|
||||
[Communication patterns and data flow]
|
||||
|
||||
## 4. Domain Conventions
|
||||
[Domain-specific standards and patterns]
|
||||
|
||||
## 5. External Integration
|
||||
[Integration with other domains and systems]
|
||||
```
|
||||
|
||||
Remember: This is Layer 2 - focus on domain-wide organization and avoid both high-level project details and low-level implementation specifics.
|
||||
@@ -0,0 +1,66 @@
|
||||
Create or update module-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 3: Module Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Module-Specific Implementation Patterns**
|
||||
- Implementation patterns used within this module
|
||||
- Common coding approaches and idioms
|
||||
- Module-specific design patterns
|
||||
|
||||
2. **Internal Architecture and Design Decisions**
|
||||
- How the module is internally organized
|
||||
- Key design decisions and their rationale
|
||||
- Component relationships within the module
|
||||
|
||||
3. **API Contracts and Interfaces**
|
||||
- Public interfaces exposed by this module
|
||||
- Input/output contracts and data formats
|
||||
- Integration points with other modules
|
||||
|
||||
4. **Module Dependencies and Relationships**
|
||||
- Direct dependencies of this module
|
||||
- How this module fits into the larger system
|
||||
- Data flow in and out of the module
|
||||
|
||||
5. **Testing Strategies for This Module**
|
||||
- Testing approaches specific to this module
|
||||
- Test coverage strategies and targets
|
||||
- Module-specific testing tools and frameworks
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Project overview content (belongs in root-level docs)
|
||||
- Domain-wide architectural patterns (belongs in domain-level docs)
|
||||
- Detailed function documentation (belongs in sub-module-level docs)
|
||||
- Configuration specifics (belongs in sub-module-level docs)
|
||||
|
||||
### Documentation Style:
|
||||
- Focus on module-level architecture and patterns
|
||||
- Explain how components within the module work together
|
||||
- Document public interfaces and contracts
|
||||
- Reference sub-module docs for detailed implementation
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Module Name] - Module Architecture
|
||||
|
||||
## 1. Module Overview
|
||||
[Module's purpose and responsibilities]
|
||||
|
||||
## 2. Implementation Patterns
|
||||
[Common patterns and approaches used]
|
||||
|
||||
## 3. Internal Architecture
|
||||
[How the module is organized internally]
|
||||
|
||||
## 4. Public Interfaces
|
||||
[APIs and contracts exposed by this module]
|
||||
|
||||
## 5. Dependencies and Integration
|
||||
[Module dependencies and system integration]
|
||||
|
||||
## 6. Testing Strategy
|
||||
[Testing approaches for this module]
|
||||
```
|
||||
|
||||
Remember: This is Layer 3 - focus on module-level architecture and patterns, avoiding both domain-wide and detailed implementation concerns.
|
||||
@@ -0,0 +1,69 @@
|
||||
Create or update sub-module-level CLAUDE.md documentation:
|
||||
|
||||
## Layer 4: Sub-Module Level Documentation Requirements
|
||||
|
||||
### Content Focus (MUST INCLUDE):
|
||||
1. **Detailed Implementation Specifics**
|
||||
- Specific implementation details and algorithms
|
||||
- Code-level patterns and idioms
|
||||
- Implementation trade-offs and decisions
|
||||
|
||||
2. **Component/Function Documentation**
|
||||
- Individual component descriptions
|
||||
- Function signatures and behaviors
|
||||
- Class/struct/interface documentation
|
||||
|
||||
3. **Configuration Details and Examples**
|
||||
- Configuration options and parameters
|
||||
- Environment-specific settings
|
||||
- Configuration examples and templates
|
||||
|
||||
4. **Usage Examples and Patterns**
|
||||
- Code examples and usage patterns
|
||||
- Common use cases and scenarios
|
||||
- Integration examples with other components
|
||||
|
||||
5. **Performance Considerations**
|
||||
- Performance characteristics and constraints
|
||||
- Optimization strategies and techniques
|
||||
- Resource usage and scalability notes
|
||||
|
||||
### Content Restrictions (STRICTLY AVOID):
|
||||
- Architecture decisions (belong in higher levels)
|
||||
- Module-level organizational patterns (belong in module-level docs)
|
||||
- Domain or project overview content (belong in higher levels)
|
||||
- Cross-module architectural concerns (belong in higher levels)
|
||||
|
||||
### Documentation Style:
|
||||
- Focus on detailed, actionable implementation information
|
||||
- Provide concrete examples and code snippets
|
||||
- Document specific behaviors and edge cases
|
||||
- Include troubleshooting and debugging guidance
|
||||
|
||||
### Template Structure:
|
||||
```markdown
|
||||
# [Sub-Module/Component Name] - Implementation Guide
|
||||
|
||||
## 1. Component Overview
|
||||
[Specific purpose and functionality]
|
||||
|
||||
## 2. Implementation Details
|
||||
[Detailed implementation specifics]
|
||||
|
||||
## 3. API Reference
|
||||
[Function/method documentation]
|
||||
|
||||
## 4. Configuration
|
||||
[Configuration options and examples]
|
||||
|
||||
## 5. Usage Examples
|
||||
[Code examples and patterns]
|
||||
|
||||
## 6. Performance and Optimization
|
||||
[Performance considerations and tips]
|
||||
|
||||
## 7. Troubleshooting
|
||||
[Common issues and solutions]
|
||||
```
|
||||
|
||||
Remember: This is Layer 4 - focus on concrete, actionable implementation details and avoid architectural or organizational concerns.
|
||||
@@ -0,0 +1,16 @@
|
||||
Analyze project structure for DMS hierarchy optimization:
|
||||
|
||||
## Required Analysis:
|
||||
1. Assess project complexity and file organization patterns
|
||||
2. Identify logical module boundaries and responsibility separation
|
||||
3. Evaluate cross-module dependencies and integration complexity
|
||||
4. Determine optimal documentation depth and hierarchy levels
|
||||
5. Recommend content differentiation strategies across hierarchy levels
|
||||
|
||||
## Output Requirements:
|
||||
- Project complexity classification with supporting metrics
|
||||
- Module boundary recommendations with responsibility mapping
|
||||
- Hierarchy depth recommendations with level-specific focus areas
|
||||
- Content strategy with redundancy elimination guidelines
|
||||
|
||||
Focus on intelligent documentation hierarchy that scales with project complexity.
|
||||
@@ -0,0 +1,16 @@
|
||||
Guide component implementation and development patterns:
|
||||
|
||||
## Required Analysis:
|
||||
1. Define component interface and API requirements
|
||||
2. Identify reusable patterns and composition strategies
|
||||
3. Plan state management and data flow implementation
|
||||
4. Design component testing and validation approach
|
||||
5. Document integration points and usage examples
|
||||
|
||||
## Output Requirements:
|
||||
- Component specification with clear interface definition
|
||||
- Implementation patterns and best practices
|
||||
- State management strategy and data flow design
|
||||
- Testing approach and validation criteria
|
||||
|
||||
Focus on reusable, maintainable component design with clear usage patterns.
|
||||
@@ -0,0 +1,16 @@
|
||||
Plan system migration and modernization strategies:
|
||||
|
||||
## Required Analysis:
|
||||
1. Assess current system architecture and migration requirements
|
||||
2. Identify migration paths and transformation strategies
|
||||
3. Plan data migration and system cutover procedures
|
||||
4. Evaluate compatibility and integration challenges
|
||||
5. Document rollback plans and risk mitigation strategies
|
||||
|
||||
## Output Requirements:
|
||||
- Migration strategy with step-by-step execution plan
|
||||
- Data migration procedures and validation checkpoints
|
||||
- Compatibility assessment and integration requirements
|
||||
- Risk analysis and rollback procedures
|
||||
|
||||
Focus on low-risk migration strategies with comprehensive fallback options.
|
||||
@@ -0,0 +1,16 @@
|
||||
Create detailed task breakdown and implementation planning:
|
||||
|
||||
## Required Analysis:
|
||||
1. Break down complex tasks into manageable subtasks
|
||||
2. Identify dependencies and execution sequence requirements
|
||||
3. Estimate effort and resource requirements for each task
|
||||
4. Map task relationships and critical path analysis
|
||||
5. Document risks and mitigation strategies
|
||||
|
||||
## Output Requirements:
|
||||
- Hierarchical task breakdown with specific deliverables
|
||||
- Dependency mapping and execution sequence
|
||||
- Effort estimation and resource allocation
|
||||
- Risk assessment and mitigation plans
|
||||
|
||||
Focus on actionable task planning with clear deliverables and timelines.
|
||||
@@ -0,0 +1,16 @@
|
||||
Conduct comprehensive code review and quality assessment:
|
||||
|
||||
## Required Analysis:
|
||||
1. Review code against established coding standards and conventions
|
||||
2. Assess logic correctness and potential edge cases
|
||||
3. Evaluate security implications and vulnerability risks
|
||||
4. Check performance characteristics and optimization opportunities
|
||||
5. Validate test coverage and documentation completeness
|
||||
|
||||
## Output Requirements:
|
||||
- Standards compliance assessment with specific violations
|
||||
- Logic review findings with potential issue identification
|
||||
- Security assessment with vulnerability documentation
|
||||
- Performance review with optimization recommendations
|
||||
|
||||
Focus on actionable feedback with clear improvement priorities and implementation guidance.
|
||||
Reference in New Issue
Block a user