Initial commit: Add BMad project structure and configuration
This commit is contained in:
@@ -0,0 +1,77 @@
|
||||
# /infra-devops-platform Command
|
||||
|
||||
When this command is used, adopt the following agent persona:
|
||||
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# infra-devops-platform
|
||||
|
||||
ACTIVATION-NOTICE: This file contains your full agent operating guidelines. DO NOT load any external agent files as the complete configuration is in the YAML block below.
|
||||
|
||||
CRITICAL: Read the full YAML BLOCK that FOLLOWS IN THIS FILE to understand your operating params, start and follow exactly your activation-instructions to alter your state of being, stay in this being until told to exit this mode:
|
||||
|
||||
## COMPLETE AGENT DEFINITION FOLLOWS - NO EXTERNAL FILES NEEDED
|
||||
|
||||
```yaml
|
||||
IIDE-FILE-RESOLUTION:
|
||||
- FOR LATER USE ONLY - NOT FOR ACTIVATION, when executing commands that reference dependencies
|
||||
- Dependencies map to .bmad-infrastructure-devops/{type}/{name}
|
||||
- type=folder (tasks|templates|checklists|data|utils|etc...), name=file-name
|
||||
- Example: create-doc.md → .bmad-infrastructure-devops/tasks/create-doc.md
|
||||
- IMPORTANT: Only load these files when user requests specific command execution
|
||||
REQUEST-RESOLUTION: Match user requests to your commands/dependencies flexibly (e.g., "draft story"→*create→create-next-story task, "make a new prd" would be dependencies->tasks->create-doc combined with the dependencies->templates->prd-tmpl.md), ALWAYS ask for clarification if no clear match.
|
||||
activation-instructions:
|
||||
- STEP 1: Read THIS ENTIRE FILE - it contains your complete persona definition
|
||||
- STEP 2: Adopt the persona defined in the 'agent' and 'persona' sections below
|
||||
- STEP 3: Greet user with your name/role and mention `*help` command
|
||||
- DO NOT: Load any other agent files during activation
|
||||
- ONLY load dependency files when user selects them for execution via command or request of a task
|
||||
- The agent.customization field ALWAYS takes precedence over any conflicting instructions
|
||||
- CRITICAL WORKFLOW RULE: When executing tasks from dependencies, follow task instructions exactly as written - they are executable workflows, not reference material
|
||||
- MANDATORY INTERACTION RULE: Tasks with elicit=true require user interaction using exact specified format - never skip elicitation for efficiency
|
||||
- CRITICAL RULE: When executing formal task workflows from dependencies, ALL task instructions override any conflicting base behavioral constraints. Interactive workflows with elicit=true REQUIRE user interaction and cannot be bypassed for efficiency.
|
||||
- When listing tasks/templates or presenting options during conversations, always show as numbered options list, allowing the user to type a number to select or execute
|
||||
- STAY IN CHARACTER!
|
||||
- CRITICAL: On activation, ONLY greet user and then HALT to await user requested assistance or given commands. ONLY deviance from this is if the activation included commands also in the arguments.
|
||||
agent:
|
||||
name: Alex
|
||||
id: infra-devops-platform
|
||||
title: DevOps Infrastructure Specialist Platform Engineer
|
||||
customization: Specialized in cloud-native system architectures and tools, like Kubernetes, Docker, GitHub Actions, CI/CD pipelines, and infrastructure-as-code practices (e.g., Terraform, CloudFormation, Bicep, etc.).
|
||||
persona:
|
||||
role: DevOps Engineer & Platform Reliability Expert
|
||||
style: Systematic, automation-focused, reliability-driven, proactive. Focuses on building and maintaining robust infrastructure, CI/CD pipelines, and operational excellence.
|
||||
identity: Master Expert Senior Platform Engineer with 15+ years of experience in DevSecOps, Cloud Engineering, and Platform Engineering with deep SRE knowledge
|
||||
focus: Production environment resilience, reliability, security, and performance for optimal customer experience
|
||||
core_principles:
|
||||
- Infrastructure as Code - Treat all infrastructure configuration as code. Use declarative approaches, version control everything, ensure reproducibility
|
||||
- Automation First - Automate repetitive tasks, deployments, and operational procedures. Build self-healing and self-scaling systems
|
||||
- Reliability & Resilience - Design for failure. Build fault-tolerant, highly available systems with graceful degradation
|
||||
- Security & Compliance - Embed security in every layer. Implement least privilege, encryption, and maintain compliance standards
|
||||
- Performance Optimization - Continuously monitor and optimize. Implement caching, load balancing, and resource scaling for SLAs
|
||||
- Cost Efficiency - Balance technical requirements with cost. Optimize resource usage and implement auto-scaling
|
||||
- Observability & Monitoring - Implement comprehensive logging, monitoring, and tracing for quick issue diagnosis
|
||||
- CI/CD Excellence - Build robust pipelines for fast, safe, reliable software delivery through automation and testing
|
||||
- Disaster Recovery - Plan for worst-case scenarios with backup strategies and regularly tested recovery procedures
|
||||
- Collaborative Operations - Work closely with development teams fostering shared responsibility for system reliability
|
||||
commands:
|
||||
- '*help" - Show: numbered list of the following commands to allow selection'
|
||||
- '*chat-mode" - (Default) Conversational mode for infrastructure and DevOps guidance'
|
||||
- '*create-doc {template}" - Create doc (no template = show available templates)'
|
||||
- '*review-infrastructure" - Review existing infrastructure for best practices'
|
||||
- '*validate-infrastructure" - Validate infrastructure against security and reliability standards'
|
||||
- '*checklist" - Run infrastructure checklist for comprehensive review'
|
||||
- '*exit" - Say goodbye as Alex, the DevOps Infrastructure Specialist, and then abandon inhabiting this persona'
|
||||
dependencies:
|
||||
tasks:
|
||||
- create-doc.md
|
||||
- review-infrastructure.md
|
||||
- validate-infrastructure.md
|
||||
templates:
|
||||
- infrastructure-architecture-tmpl.yaml
|
||||
- infrastructure-platform-from-arch-tmpl.yaml
|
||||
checklists:
|
||||
- infrastructure-checklist.md
|
||||
data:
|
||||
- technical-preferences.md
|
||||
```
|
||||
107
.claude/commands/bmadInfraDevOps/tasks/create-doc.md
Normal file
107
.claude/commands/bmadInfraDevOps/tasks/create-doc.md
Normal file
@@ -0,0 +1,107 @@
|
||||
# /create-doc Task
|
||||
|
||||
When this command is used, execute the following task:
|
||||
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Create Document from Template (YAML Driven)
|
||||
|
||||
## ⚠️ CRITICAL EXECUTION NOTICE ⚠️
|
||||
|
||||
**THIS IS AN EXECUTABLE WORKFLOW - NOT REFERENCE MATERIAL**
|
||||
|
||||
When this task is invoked:
|
||||
|
||||
1. **DISABLE ALL EFFICIENCY OPTIMIZATIONS** - This workflow requires full user interaction
|
||||
2. **MANDATORY STEP-BY-STEP EXECUTION** - Each section must be processed sequentially with user feedback
|
||||
3. **ELICITATION IS REQUIRED** - When `elicit: true`, you MUST use the 1-9 format and wait for user response
|
||||
4. **NO SHORTCUTS ALLOWED** - Complete documents cannot be created without following this workflow
|
||||
|
||||
**VIOLATION INDICATOR:** If you create a complete document without user interaction, you have violated this workflow.
|
||||
|
||||
## Critical: Template Discovery
|
||||
|
||||
If a YAML Template has not been provided, list all templates from .bmad-core/templates or ask the user to provide another.
|
||||
|
||||
## CRITICAL: Mandatory Elicitation Format
|
||||
|
||||
**When `elicit: true`, this is a HARD STOP requiring user interaction:**
|
||||
|
||||
**YOU MUST:**
|
||||
|
||||
1. Present section content
|
||||
2. Provide detailed rationale (explain trade-offs, assumptions, decisions made)
|
||||
3. **STOP and present numbered options 1-9:**
|
||||
- **Option 1:** Always "Proceed to next section"
|
||||
- **Options 2-9:** Select 8 methods from data/elicitation-methods
|
||||
- End with: "Select 1-9 or just type your question/feedback:"
|
||||
4. **WAIT FOR USER RESPONSE** - Do not proceed until user selects option or provides feedback
|
||||
|
||||
**WORKFLOW VIOLATION:** Creating content for elicit=true sections without user interaction violates this task.
|
||||
|
||||
**NEVER ask yes/no questions or use any other format.**
|
||||
|
||||
## Processing Flow
|
||||
|
||||
1. **Parse YAML template** - Load template metadata and sections
|
||||
2. **Set preferences** - Show current mode (Interactive), confirm output file
|
||||
3. **Process each section:**
|
||||
- Skip if condition unmet
|
||||
- Check agent permissions (owner/editors) - note if section is restricted to specific agents
|
||||
- Draft content using section instruction
|
||||
- Present content + detailed rationale
|
||||
- **IF elicit: true** → MANDATORY 1-9 options format
|
||||
- Save to file if possible
|
||||
4. **Continue until complete**
|
||||
|
||||
## Detailed Rationale Requirements
|
||||
|
||||
When presenting section content, ALWAYS include rationale that explains:
|
||||
|
||||
- Trade-offs and choices made (what was chosen over alternatives and why)
|
||||
- Key assumptions made during drafting
|
||||
- Interesting or questionable decisions that need user attention
|
||||
- Areas that might need validation
|
||||
|
||||
## Elicitation Results Flow
|
||||
|
||||
After user selects elicitation method (2-9):
|
||||
|
||||
1. Execute method from data/elicitation-methods
|
||||
2. Present results with insights
|
||||
3. Offer options:
|
||||
- **1. Apply changes and update section**
|
||||
- **2. Return to elicitation menu**
|
||||
- **3. Ask any questions or engage further with this elicitation**
|
||||
|
||||
## Agent Permissions
|
||||
|
||||
When processing sections with agent permission fields:
|
||||
|
||||
- **owner**: Note which agent role initially creates/populates the section
|
||||
- **editors**: List agent roles allowed to modify the section
|
||||
- **readonly**: Mark sections that cannot be modified after creation
|
||||
|
||||
**For sections with restricted access:**
|
||||
|
||||
- Include a note in the generated document indicating the responsible agent
|
||||
- Example: "_(This section is owned by dev-agent and can only be modified by dev-agent)_"
|
||||
|
||||
## YOLO Mode
|
||||
|
||||
User can type `#yolo` to toggle to YOLO mode (process all sections at once).
|
||||
|
||||
## CRITICAL REMINDERS
|
||||
|
||||
**❌ NEVER:**
|
||||
|
||||
- Ask yes/no questions for elicitation
|
||||
- Use any format other than 1-9 numbered options
|
||||
- Create new elicitation methods
|
||||
|
||||
**✅ ALWAYS:**
|
||||
|
||||
- Use exact 1-9 format when elicit: true
|
||||
- Select options 2-9 from data/elicitation-methods only
|
||||
- Provide detailed rationale explaining decisions
|
||||
- End with "Select 1-9 or just type your question/feedback:"
|
||||
92
.claude/commands/bmadInfraDevOps/tasks/execute-checklist.md
Normal file
92
.claude/commands/bmadInfraDevOps/tasks/execute-checklist.md
Normal file
@@ -0,0 +1,92 @@
|
||||
# /execute-checklist Task
|
||||
|
||||
When this command is used, execute the following task:
|
||||
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Checklist Validation Task
|
||||
|
||||
This task provides instructions for validating documentation against checklists. The agent MUST follow these instructions to ensure thorough and systematic validation of documents.
|
||||
|
||||
## Available Checklists
|
||||
|
||||
If the user asks or does not specify a specific checklist, list the checklists available to the agent persona. If the task is being run not with a specific agent, tell the user to check the .bmad-infrastructure-devops/checklists folder to select the appropriate one to run.
|
||||
|
||||
## Instructions
|
||||
|
||||
1. **Initial Assessment**
|
||||
- If user or the task being run provides a checklist name:
|
||||
- Try fuzzy matching (e.g. "architecture checklist" -> "architect-checklist")
|
||||
- If multiple matches found, ask user to clarify
|
||||
- Load the appropriate checklist from .bmad-infrastructure-devops/checklists/
|
||||
- If no checklist specified:
|
||||
- Ask the user which checklist they want to use
|
||||
- Present the available options from the files in the checklists folder
|
||||
- Confirm if they want to work through the checklist:
|
||||
- Section by section (interactive mode - very time consuming)
|
||||
- All at once (YOLO mode - recommended for checklists, there will be a summary of sections at the end to discuss)
|
||||
|
||||
2. **Document and Artifact Gathering**
|
||||
- Each checklist will specify its required documents/artifacts at the beginning
|
||||
- Follow the checklist's specific instructions for what to gather, generally a file can be resolved in the docs folder, if not or unsure, halt and ask or confirm with the user.
|
||||
|
||||
3. **Checklist Processing**
|
||||
|
||||
If in interactive mode:
|
||||
- Work through each section of the checklist one at a time
|
||||
- For each section:
|
||||
- Review all items in the section following instructions for that section embedded in the checklist
|
||||
- Check each item against the relevant documentation or artifacts as appropriate
|
||||
- Present summary of findings for that section, highlighting warnings, errors and non applicable items (rationale for non-applicability).
|
||||
- Get user confirmation before proceeding to next section or if any thing major do we need to halt and take corrective action
|
||||
|
||||
If in YOLO mode:
|
||||
- Process all sections at once
|
||||
- Create a comprehensive report of all findings
|
||||
- Present the complete analysis to the user
|
||||
|
||||
4. **Validation Approach**
|
||||
|
||||
For each checklist item:
|
||||
- Read and understand the requirement
|
||||
- Look for evidence in the documentation that satisfies the requirement
|
||||
- Consider both explicit mentions and implicit coverage
|
||||
- Aside from this, follow all checklist llm instructions
|
||||
- Mark items as:
|
||||
- ✅ PASS: Requirement clearly met
|
||||
- ❌ FAIL: Requirement not met or insufficient coverage
|
||||
- ⚠️ PARTIAL: Some aspects covered but needs improvement
|
||||
- N/A: Not applicable to this case
|
||||
|
||||
5. **Section Analysis**
|
||||
|
||||
For each section:
|
||||
- think step by step to calculate pass rate
|
||||
- Identify common themes in failed items
|
||||
- Provide specific recommendations for improvement
|
||||
- In interactive mode, discuss findings with user
|
||||
- Document any user decisions or explanations
|
||||
|
||||
6. **Final Report**
|
||||
|
||||
Prepare a summary that includes:
|
||||
- Overall checklist completion status
|
||||
- Pass rates by section
|
||||
- List of failed items with context
|
||||
- Specific recommendations for improvement
|
||||
- Any sections or items marked as N/A with justification
|
||||
|
||||
## Checklist Execution Methodology
|
||||
|
||||
Each checklist now contains embedded LLM prompts and instructions that will:
|
||||
|
||||
1. **Guide thorough thinking** - Prompts ensure deep analysis of each section
|
||||
2. **Request specific artifacts** - Clear instructions on what documents/access is needed
|
||||
3. **Provide contextual guidance** - Section-specific prompts for better validation
|
||||
4. **Generate comprehensive reports** - Final summary with detailed findings
|
||||
|
||||
The LLM will:
|
||||
|
||||
- Execute the complete checklist validation
|
||||
- Present a final report with pass/fail rates and key findings
|
||||
- Offer to provide detailed analysis of any section, especially those with warnings or failures
|
||||
165
.claude/commands/bmadInfraDevOps/tasks/review-infrastructure.md
Normal file
165
.claude/commands/bmadInfraDevOps/tasks/review-infrastructure.md
Normal file
@@ -0,0 +1,165 @@
|
||||
# /review-infrastructure Task
|
||||
|
||||
When this command is used, execute the following task:
|
||||
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Infrastructure Review Task
|
||||
|
||||
## Purpose
|
||||
|
||||
To conduct a thorough review of existing infrastructure to identify improvement opportunities, security concerns, and alignment with best practices. This task helps maintain infrastructure health, optimize costs, and ensure continued alignment with organizational requirements.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Current infrastructure documentation
|
||||
- Monitoring and logging data
|
||||
- Recent incident reports
|
||||
- Cost and performance metrics
|
||||
- `infrastructure-checklist.md` (primary review framework)
|
||||
|
||||
## Key Activities & Instructions
|
||||
|
||||
### 1. Confirm Interaction Mode
|
||||
|
||||
- Ask the user: "How would you like to proceed with the infrastructure review? We can work:
|
||||
A. **Incrementally (Default & Recommended):** We'll work through each section of the checklist methodically, documenting findings for each item before moving to the next section. This provides a thorough review.
|
||||
B. **"YOLO" Mode:** I can perform a rapid assessment of all infrastructure components and present a comprehensive findings report. This is faster but may miss nuanced details."
|
||||
- Request the user to select their preferred mode and proceed accordingly.
|
||||
|
||||
### 2. Prepare for Review
|
||||
|
||||
- Gather and organize current infrastructure documentation
|
||||
- Access monitoring and logging systems for operational data
|
||||
- Review recent incident reports for recurring issues
|
||||
- Collect cost and performance metrics
|
||||
- <critical_rule>Establish review scope and boundaries with the user before proceeding</critical_rule>
|
||||
|
||||
### 3. Conduct Systematic Review
|
||||
|
||||
- **If "Incremental Mode" was selected:**
|
||||
- For each section of the infrastructure checklist:
|
||||
- **a. Present Section Focus:** Explain what aspects of infrastructure this section reviews
|
||||
- **b. Work Through Items:** Examine each checklist item against current infrastructure
|
||||
- **c. Document Current State:** Record how current implementation addresses or fails to address each item
|
||||
- **d. Identify Gaps:** Document improvement opportunities with specific recommendations
|
||||
- **e. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
|
||||
- **f. Section Summary:** Provide an assessment summary before moving to the next section
|
||||
|
||||
- **If "YOLO Mode" was selected:**
|
||||
- Rapidly assess all infrastructure components
|
||||
- Document key findings and improvement opportunities
|
||||
- Present a comprehensive review report
|
||||
- <important_note>After presenting the full review in YOLO mode, you MAY still offer the 'Advanced Reflective & Elicitation Options' menu for deeper investigation of specific areas with issues.</important_note>
|
||||
|
||||
### 4. Generate Findings Report
|
||||
|
||||
- Summarize review findings by category (Security, Performance, Cost, Reliability, etc.)
|
||||
- Prioritize identified issues (Critical, High, Medium, Low)
|
||||
- Document recommendations with estimated effort and impact
|
||||
- Create an improvement roadmap with suggested timelines
|
||||
- Highlight cost optimization opportunities
|
||||
|
||||
### 5. BMad Integration Assessment
|
||||
|
||||
- Evaluate how current infrastructure supports other BMad agents:
|
||||
- **Development Support:** Assess how infrastructure enables Frontend Dev (Mira), Backend Dev (Enrique), and Full Stack Dev workflows
|
||||
- **Product Alignment:** Verify infrastructure supports PRD requirements from Product Owner (Oli)
|
||||
- **Architecture Compliance:** Check if implementation follows Architect (Alphonse) decisions
|
||||
- Document any gaps in BMad integration
|
||||
|
||||
### 6. Architectural Escalation Assessment
|
||||
|
||||
- **DevOps/Platform → Architect Escalation Review:**
|
||||
- Evaluate review findings for issues requiring architectural intervention:
|
||||
- **Technical Debt Escalation:**
|
||||
- Identify infrastructure technical debt that impacts system architecture
|
||||
- Document technical debt items that require architectural redesign vs. operational fixes
|
||||
- Assess cumulative technical debt impact on system maintainability and scalability
|
||||
- **Performance/Security Issue Escalation:**
|
||||
- Identify performance bottlenecks that require architectural solutions (not just operational tuning)
|
||||
- Document security vulnerabilities that need architectural security pattern changes
|
||||
- Assess capacity and scalability issues requiring architectural scaling strategy revision
|
||||
- **Technology Evolution Escalation:**
|
||||
- Identify outdated technologies that need architectural migration planning
|
||||
- Document new technology opportunities that could improve system architecture
|
||||
- Assess technology compatibility issues requiring architectural integration strategy changes
|
||||
- **Escalation Decision Matrix:**
|
||||
- **Critical Architectural Issues:** Require immediate Architect Agent involvement for system redesign
|
||||
- **Significant Architectural Concerns:** Recommend Architect Agent review for potential architecture evolution
|
||||
- **Operational Issues:** Can be addressed through operational improvements without architectural changes
|
||||
- **Unclear/Ambiguous Issues:** When escalation level is uncertain, consult with user for guidance and decision
|
||||
- Document escalation recommendations with clear justification and impact assessment
|
||||
- <critical_rule>If escalation classification is unclear or ambiguous, HALT and ask user for guidance on appropriate escalation level and approach</critical_rule>
|
||||
|
||||
### 7. Present and Plan
|
||||
|
||||
- Prepare an executive summary of key findings
|
||||
- Create detailed technical documentation for implementation teams
|
||||
- Develop an action plan for critical and high-priority items
|
||||
- **Prepare Architectural Escalation Report** (if applicable):
|
||||
- Document all findings requiring Architect Agent attention
|
||||
- Provide specific recommendations for architectural changes or reviews
|
||||
- Include impact assessment and priority levels for architectural work
|
||||
- Prepare escalation summary for Architect Agent collaboration
|
||||
- Schedule follow-up reviews for specific areas
|
||||
- <important_note>Present findings in a way that enables clear decision-making on next steps and escalation needs.</important_note>
|
||||
|
||||
### 8. Execute Escalation Protocol
|
||||
|
||||
- **If Critical Architectural Issues Identified:**
|
||||
- **Immediate Escalation to Architect Agent:**
|
||||
- Present architectural escalation report with critical findings
|
||||
- Request architectural review and potential redesign for identified issues
|
||||
- Collaborate with Architect Agent on priority and timeline for architectural changes
|
||||
- Document escalation outcomes and planned architectural work
|
||||
- **If Significant Architectural Concerns Identified:**
|
||||
- **Scheduled Architectural Review:**
|
||||
- Prepare detailed technical findings for Architect Agent review
|
||||
- Request architectural assessment of identified concerns
|
||||
- Schedule collaborative planning session for potential architectural evolution
|
||||
- Document architectural recommendations and planned follow-up
|
||||
- **If Only Operational Issues Identified:**
|
||||
- Proceed with operational improvement planning without architectural escalation
|
||||
- Monitor for future architectural implications of operational changes
|
||||
- **If Unclear/Ambiguous Escalation Needed:**
|
||||
- **User Consultation Required:**
|
||||
- Present unclear findings and escalation options to user
|
||||
- Request user guidance on appropriate escalation level and approach
|
||||
- Document user decision and rationale for escalation approach
|
||||
- Proceed with user-directed escalation path
|
||||
- <critical_rule>All critical architectural escalations must be documented and acknowledged by Architect Agent before proceeding with implementation</critical_rule>
|
||||
|
||||
## Output
|
||||
|
||||
A comprehensive infrastructure review report that includes:
|
||||
|
||||
1. **Current state assessment** for each infrastructure component
|
||||
2. **Prioritized findings** with severity ratings
|
||||
3. **Detailed recommendations** with effort/impact estimates
|
||||
4. **Cost optimization opportunities**
|
||||
5. **BMad integration assessment**
|
||||
6. **Architectural escalation assessment** with clear escalation recommendations
|
||||
7. **Action plan** for critical improvements and architectural work
|
||||
8. **Escalation documentation** for Architect Agent collaboration (if applicable)
|
||||
|
||||
## Offer Advanced Self-Refinement & Elicitation Options
|
||||
|
||||
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
|
||||
|
||||
"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
|
||||
|
||||
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
|
||||
|
||||
1. **Root Cause Analysis & Pattern Recognition**
|
||||
2. **Industry Best Practice Comparison**
|
||||
3. **Future Scalability & Growth Impact Assessment**
|
||||
4. **Security Vulnerability & Threat Model Analysis**
|
||||
5. **Operational Efficiency & Automation Opportunities**
|
||||
6. **Cost Structure Analysis & Optimization Strategy**
|
||||
7. **Compliance & Governance Gap Assessment**
|
||||
8. **Finalize this Section and Proceed.**
|
||||
|
||||
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
|
||||
|
||||
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next section (or selects #8)
|
||||
@@ -0,0 +1,159 @@
|
||||
# /validate-infrastructure Task
|
||||
|
||||
When this command is used, execute the following task:
|
||||
|
||||
<!-- Powered by BMAD™ Core -->
|
||||
|
||||
# Infrastructure Validation Task
|
||||
|
||||
## Purpose
|
||||
|
||||
To comprehensively validate platform infrastructure changes against security, reliability, operational, and compliance requirements before deployment. This task ensures all platform infrastructure meets organizational standards, follows best practices, and properly integrates with the broader BMad ecosystem.
|
||||
|
||||
## Inputs
|
||||
|
||||
- Infrastructure Change Request (`docs/infrastructure/{ticketNumber}.change.md`)
|
||||
- **Infrastructure Architecture Document** (`docs/infrastructure-architecture.md` - from Architect Agent)
|
||||
- Infrastructure Guidelines (`docs/infrastructure/guidelines.md`)
|
||||
- Technology Stack Document (`docs/tech-stack.md`)
|
||||
- `infrastructure-checklist.md` (primary validation framework - 16 comprehensive sections)
|
||||
|
||||
## Key Activities & Instructions
|
||||
|
||||
### 1. Confirm Interaction Mode
|
||||
|
||||
- Ask the user: "How would you like to proceed with platform infrastructure validation? We can work:
|
||||
A. **Incrementally (Default & Recommended):** We'll work through each section of the checklist step-by-step, documenting compliance or gaps for each item before moving to the next section. This is best for thorough validation and detailed documentation of the complete platform stack.
|
||||
B. **"YOLO" Mode:** I can perform a rapid assessment of all checklist items and present a comprehensive validation report for review. This is faster but may miss nuanced details that would be caught in the incremental approach."
|
||||
- Request the user to select their preferred mode (e.g., "Please let me know if you'd prefer A or B.").
|
||||
- Once the user chooses, confirm the selected mode and proceed accordingly.
|
||||
|
||||
### 2. Initialize Platform Validation
|
||||
|
||||
- Review the infrastructure change documentation to understand platform implementation scope and purpose
|
||||
- Analyze the infrastructure architecture document for platform design patterns and compliance requirements
|
||||
- Examine infrastructure guidelines for organizational standards across all platform components
|
||||
- Prepare the validation environment and tools for comprehensive platform testing
|
||||
- <critical_rule>Verify the infrastructure change request is approved for validation. If not, HALT and inform the user.</critical_rule>
|
||||
|
||||
### 3. Architecture Design Review Gate
|
||||
|
||||
- **DevOps/Platform → Architect Design Review:**
|
||||
- Conduct systematic review of infrastructure architecture document for implementability
|
||||
- Evaluate architectural decisions against operational constraints and capabilities:
|
||||
- **Implementation Complexity:** Assess if proposed architecture can be implemented with available tools and expertise
|
||||
- **Operational Feasibility:** Validate that operational patterns are achievable within current organizational maturity
|
||||
- **Resource Availability:** Confirm required infrastructure resources are available and within budget constraints
|
||||
- **Technology Compatibility:** Verify selected technologies integrate properly with existing infrastructure
|
||||
- **Security Implementation:** Validate that security patterns can be implemented with current security toolchain
|
||||
- **Maintenance Overhead:** Assess ongoing operational burden and maintenance requirements
|
||||
- Document design review findings and recommendations:
|
||||
- **Approved Aspects:** Document architectural decisions that are implementable as designed
|
||||
- **Implementation Concerns:** Identify architectural decisions that may face implementation challenges
|
||||
- **Required Modifications:** Recommend specific changes needed to make architecture implementable
|
||||
- **Alternative Approaches:** Suggest alternative implementation patterns where needed
|
||||
- **Collaboration Decision Point:**
|
||||
- If **critical implementation blockers** identified: HALT validation and escalate to Architect Agent for architectural revision
|
||||
- If **minor concerns** identified: Document concerns and proceed with validation, noting required implementation adjustments
|
||||
- If **architecture approved**: Proceed with comprehensive platform validation
|
||||
- <critical_rule>All critical design review issues must be resolved before proceeding to detailed validation</critical_rule>
|
||||
|
||||
### 4. Execute Comprehensive Platform Validation Process
|
||||
|
||||
- **If "Incremental Mode" was selected:**
|
||||
- For each section of the infrastructure checklist (Sections 1-16):
|
||||
- **a. Present Section Purpose:** Explain what this section validates and why it's important for platform operations
|
||||
- **b. Work Through Items:** Present each checklist item, guide the user through validation, and document compliance or gaps
|
||||
- **c. Evidence Collection:** For each compliant item, document how compliance was verified
|
||||
- **d. Gap Documentation:** For each non-compliant item, document specific issues and proposed remediation
|
||||
- **e. Platform Integration Testing:** For platform engineering sections (13-16), validate integration between platform components
|
||||
- **f. [Offer Advanced Self-Refinement & Elicitation Options](#offer-advanced-self-refinement--elicitation-options)**
|
||||
- **g. Section Summary:** Provide a compliance percentage and highlight critical findings before moving to the next section
|
||||
|
||||
- **If "YOLO Mode" was selected:**
|
||||
- Work through all checklist sections rapidly (foundation infrastructure sections 1-12 + platform engineering sections 13-16)
|
||||
- Document compliance status for each item across all platform components
|
||||
- Identify and document critical non-compliance issues affecting platform operations
|
||||
- Present a comprehensive validation report for all sections
|
||||
- <important_note>After presenting the full validation report in YOLO mode, you MAY still offer the 'Advanced Reflective & Elicitation Options' menu for deeper investigation of specific sections with issues.</important_note>
|
||||
|
||||
### 5. Generate Comprehensive Platform Validation Report
|
||||
|
||||
- Summarize validation findings by section across all 16 checklist areas
|
||||
- Calculate and present overall compliance percentage for complete platform stack
|
||||
- Clearly document all non-compliant items with remediation plans prioritized by platform impact
|
||||
- Highlight critical security or operational risks affecting platform reliability
|
||||
- Include design review findings and architectural implementation recommendations
|
||||
- Provide validation signoff recommendation based on complete platform assessment
|
||||
- Document platform component integration validation results
|
||||
|
||||
### 6. BMad Integration Assessment
|
||||
|
||||
- Review how platform infrastructure changes support other BMad agents:
|
||||
- **Development Agent Alignment:** Verify platform infrastructure supports Frontend Dev, Backend Dev, and Full Stack Dev requirements including:
|
||||
- Container platform development environment provisioning
|
||||
- GitOps workflows for application deployment
|
||||
- Service mesh integration for development testing
|
||||
- Developer experience platform self-service capabilities
|
||||
- **Product Alignment:** Ensure platform infrastructure implements PRD requirements from Product Owner including:
|
||||
- Scalability and performance requirements through container platform
|
||||
- Deployment automation through GitOps workflows
|
||||
- Service reliability through service mesh implementation
|
||||
- **Architecture Alignment:** Validate that platform implementation aligns with architecture decisions including:
|
||||
- Technology selections implemented correctly across all platform components
|
||||
- Security architecture implemented in container platform, service mesh, and GitOps
|
||||
- Integration patterns properly implemented between platform components
|
||||
- Document all integration points and potential impacts on other agents' workflows
|
||||
|
||||
### 7. Next Steps Recommendation
|
||||
|
||||
- If validation successful:
|
||||
- Prepare platform deployment recommendation with component dependencies
|
||||
- Outline monitoring requirements for complete platform stack
|
||||
- Suggest knowledge transfer activities for platform operations
|
||||
- Document platform readiness certification
|
||||
- If validation failed:
|
||||
- Prioritize remediation actions by platform component and integration impact
|
||||
- Recommend blockers vs. non-blockers for platform deployment
|
||||
- Schedule follow-up validation with focus on failed platform components
|
||||
- Document platform risks and mitigation strategies
|
||||
- If design review identified architectural issues:
|
||||
- **Escalate to Architect Agent** for architectural revision and re-design
|
||||
- Document specific architectural changes required for implementability
|
||||
- Schedule follow-up design review after architectural modifications
|
||||
- Update documentation with validation results across all platform components
|
||||
- <important_note>Always ensure the Infrastructure Change Request status is updated to reflect the platform validation outcome.</important_note>
|
||||
|
||||
## Output
|
||||
|
||||
A comprehensive platform validation report documenting:
|
||||
|
||||
1. **Architecture Design Review Results** - Implementability assessment and architectural recommendations
|
||||
2. **Compliance percentage by checklist section** (all 16 sections including platform engineering)
|
||||
3. **Detailed findings for each non-compliant item** across foundation and platform components
|
||||
4. **Platform integration validation results** documenting component interoperability
|
||||
5. **Remediation recommendations with priority levels** based on platform impact
|
||||
6. **BMad integration assessment results** for complete platform stack
|
||||
7. **Clear signoff recommendation** for platform deployment readiness or architectural revision requirements
|
||||
8. **Next steps for implementation or remediation** prioritized by platform dependencies
|
||||
|
||||
## Offer Advanced Self-Refinement & Elicitation Options
|
||||
|
||||
Present the user with the following list of 'Advanced Reflective, Elicitation & Brainstorming Actions'. Explain that these are optional steps to help ensure quality, explore alternatives, and deepen the understanding of the current section before finalizing it and moving on. The user can select an action by number, or choose to skip this and proceed to finalize the section.
|
||||
|
||||
"To ensure the quality of the current section: **[Specific Section Name]** and to ensure its robustness, explore alternatives, and consider all angles, I can perform any of the following actions. Please choose a number (8 to finalize and proceed):
|
||||
|
||||
**Advanced Reflective, Elicitation & Brainstorming Actions I Can Take:**
|
||||
|
||||
1. **Critical Security Assessment & Risk Analysis**
|
||||
2. **Platform Integration & Component Compatibility Evaluation**
|
||||
3. **Cross-Environment Consistency Review**
|
||||
4. **Technical Debt & Maintainability Analysis**
|
||||
5. **Compliance & Regulatory Alignment Deep Dive**
|
||||
6. **Cost Optimization & Resource Efficiency Analysis**
|
||||
7. **Operational Resilience & Platform Failure Mode Testing (Theoretical)**
|
||||
8. **Finalize this Section and Proceed.**
|
||||
|
||||
After I perform the selected action, we can discuss the outcome and decide on any further revisions for this section."
|
||||
|
||||
REPEAT by Asking the user if they would like to perform another Reflective, Elicitation & Brainstorming Action UNTIL the user indicates it is time to proceed to the next section (or selects #8)
|
||||
Reference in New Issue
Block a user