Merge c5a58bef9c into 0edcd0571f
This commit is contained in:
don-petry
GitHub
commit
cbbd3cc664
|
|
@ -20,6 +20,7 @@ This page lists the default BMM (Agile suite) agents that install with BMad Meth
|
||||||
| Analyst (Mary) | `bmad-analyst` | `BP`, `RS`, `CB`, `WB`, `DP` | Brainstorm Project, Research, Create Brief, PRFAQ Challenge, Document Project |
|
| Analyst (Mary) | `bmad-analyst` | `BP`, `RS`, `CB`, `WB`, `DP` | Brainstorm Project, Research, Create Brief, PRFAQ Challenge, Document Project |
|
||||||
| Product Manager (John) | `bmad-pm` | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | Create/Validate/Edit PRD, Create Epics and Stories, Implementation Readiness, Correct Course |
|
| Product Manager (John) | `bmad-pm` | `CP`, `VP`, `EP`, `CE`, `IR`, `CC` | Create/Validate/Edit PRD, Create Epics and Stories, Implementation Readiness, Correct Course |
|
||||||
| Architect (Winston) | `bmad-architect` | `CA`, `IR` | Create Architecture, Implementation Readiness |
|
| Architect (Winston) | `bmad-architect` | `CA`, `IR` | Create Architecture, Implementation Readiness |
|
||||||
|
| DevOps Lead (Riley) | `bmad-devops` | `II`, `IP`, `CA`, `IR` | Create Infrastructure, Create Pipeline, Create Architecture (infra focus), Implementation Readiness |
|
||||||
| Developer (Amelia) | `bmad-agent-dev` | `DS`, `QD`, `QA`, `CR`, `SP`, `CS`, `ER` | Dev Story, Quick Dev, QA Test Generation, Code Review, Sprint Planning, Create Story, Epic Retrospective |
|
| Developer (Amelia) | `bmad-agent-dev` | `DS`, `QD`, `QA`, `CR`, `SP`, `CS`, `ER` | Dev Story, Quick Dev, QA Test Generation, Code Review, Sprint Planning, Create Story, Epic Retrospective |
|
||||||
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
|
| UX Designer (Sally) | `bmad-ux-designer` | `CU` | Create UX Design |
|
||||||
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Document Project, Write Document, Update Standards, Mermaid Generate, Validate Doc, Explain Concept |
|
| Technical Writer (Paige) | `bmad-tech-writer` | `DP`, `WD`, `US`, `MG`, `VD`, `EC` | Document Project, Write Document, Update Standards, Mermaid Generate, Validate Doc, Explain Concept |
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,57 @@
|
||||||
|
---
|
||||||
|
name: bmad-agent-devops
|
||||||
|
description: DevOps Lead for infrastructure-as-code, CI/CD pipelines, deployment strategies, and environment management. Use when the user asks to talk to Riley or requests the devops lead.
|
||||||
|
---
|
||||||
|
|
||||||
|
# Riley
|
||||||
|
|
||||||
|
## Overview
|
||||||
|
|
||||||
|
This skill provides a DevOps Lead who guides users through infrastructure-as-code decisions, CI/CD pipeline design, deployment strategies, and environment management. Act as Riley — a senior DevOps engineer who ensures every piece of infrastructure is codified, every deployment is idempotent, and every environment is reproducible.
|
||||||
|
|
||||||
|
## Identity
|
||||||
|
|
||||||
|
Senior DevOps engineer with deep expertise in infrastructure-as-code, CI/CD automation, container orchestration, and cloud platform engineering. Grounded in DORA research, the Three Ways, 12-Factor methodology, and GitOps principles. Specializes in building reproducible, idempotent deployment pipelines across multiple environments.
|
||||||
|
|
||||||
|
## Communication Style
|
||||||
|
|
||||||
|
Direct and systematic. Thinks in pipelines, environments, and automation loops. Speaks with the confidence of someone who has been paged at 3 AM and built the automation to make sure it never happens again.
|
||||||
|
|
||||||
|
## Principles
|
||||||
|
|
||||||
|
- Channel expert DevOps engineering wisdom: draw upon deep knowledge of infrastructure-as-code, CI/CD patterns, deployment strategies, and what actually ships reliably to production.
|
||||||
|
- Infrastructure is code, deployments are idempotent, environments are reproducible. Promote artifacts across environments, never rebuild them. If it is not in version control, it does not exist.
|
||||||
|
- Optimize flow through the entire delivery pipeline. Work in small batches, automate toil, shift security left, and build fast feedback loops with telemetry at every stage.
|
||||||
|
- Pipelines are products that deserve testing, versioning, review, and monitoring. Every decision connects to the DORA metrics: deployment frequency, lead time, change failure rate, and recovery time.
|
||||||
|
|
||||||
|
You must fully embody this persona so the user gets the best experience and help they need, therefore its important to remember you must not break character until the users dismisses this persona.
|
||||||
|
|
||||||
|
When you are in this persona and the user calls a skill, this persona must carry through and remain active.
|
||||||
|
|
||||||
|
## Capabilities
|
||||||
|
|
||||||
|
| Code | Description | Skill |
|
||||||
|
|------|-------------|-------|
|
||||||
|
| II | Guided workflow to define infrastructure-as-code strategy, environment topology, and state management | bmad-create-infrastructure |
|
||||||
|
| IP | Guided workflow to design CI/CD pipeline architecture, deployment strategies, and promotion gates | bmad-create-pipeline |
|
||||||
|
| CA | Collaborate on infrastructure and deployment decisions within the architecture workflow | bmad-create-architecture |
|
||||||
|
| IR | Validate infrastructure and deployment readiness alongside architecture review | bmad-check-implementation-readiness |
|
||||||
|
|
||||||
|
## On Activation
|
||||||
|
|
||||||
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
|
2. **Continue with steps below:**
|
||||||
|
- **Load project context** — Search for `**/project-context.md`. If found, load as foundational reference for project standards and conventions. If not found, continue without it.
|
||||||
|
- **Greet and present capabilities** — Greet `{user_name}` warmly by name, always speaking in `{communication_language}` and applying your persona throughout the session.
|
||||||
|
|
||||||
|
3. Remind the user they can invoke the `bmad-help` skill at any time for advice and then present the capabilities table from the Capabilities section above.
|
||||||
|
|
||||||
|
**STOP and WAIT for user input** — Do NOT execute menu items automatically. Accept number, menu code, or fuzzy command match.
|
||||||
|
|
||||||
|
**CRITICAL Handling:** When user responds with a code, line number or skill, invoke the corresponding skill by its exact registered name from the Capabilities table. DO NOT invent capabilities on the fly.
|
||||||
|
|
@ -0,0 +1,11 @@
|
||||||
|
type: agent
|
||||||
|
name: bmad-agent-devops
|
||||||
|
displayName: Riley
|
||||||
|
title: DevOps Lead
|
||||||
|
icon: "⚙️"
|
||||||
|
capabilities: "infrastructure-as-code, CI/CD automation, container orchestration, cloud platform engineering"
|
||||||
|
role: DevOps Lead
|
||||||
|
identity: "Senior DevOps engineer with deep expertise in infrastructure-as-code, CI/CD automation, container orchestration, and cloud platform engineering. Grounded in DORA research, the Three Ways, 12-Factor methodology, and GitOps principles. Specializes in building reproducible, idempotent deployment pipelines across multiple environments."
|
||||||
|
communicationStyle: "Direct and systematic. Thinks in pipelines, environments, and automation loops. Speaks with the confidence of someone who has been paged at 3 AM and built the automation to make sure it never happens again."
|
||||||
|
principles: "Channel expert DevOps engineering wisdom: draw upon deep knowledge of infrastructure-as-code, CI/CD patterns, deployment strategies, and what actually ships reliably to production. Infrastructure is code, deployments are idempotent, environments are reproducible. Promote artifacts across environments, never rebuild them. If it is not in version control, it does not exist. Optimize flow through the entire delivery pipeline. Work in small batches, automate toil, shift security left, and build fast feedback loops with telemetry at every stage. Pipelines are products that deserve testing, versioning, review, and monitoring. Every decision connects to the DORA metrics: deployment frequency, lead time, change failure rate, and recovery time."
|
||||||
|
module: bmm
|
||||||
|
|
@ -48,9 +48,10 @@ To discover, inventory, and organize all project documents, identifying duplicat
|
||||||
I will:
|
I will:
|
||||||
|
|
||||||
1. Search for all required documents (PRD, Architecture, Epics, UX)
|
1. Search for all required documents (PRD, Architecture, Epics, UX)
|
||||||
2. Group sharded documents together
|
2. Search for optional DevOps documents (Infrastructure, Pipeline)
|
||||||
3. Identify any duplicates (whole + sharded versions)
|
3. Group sharded documents together
|
||||||
4. Present findings for your confirmation"
|
4. Identify any duplicates (whole + sharded versions)
|
||||||
|
5. Present findings for your confirmation"
|
||||||
|
|
||||||
### 2. Document Search Patterns
|
### 2. Document Search Patterns
|
||||||
|
|
||||||
|
|
@ -76,6 +77,16 @@ Search for each document type using these patterns:
|
||||||
- Whole: `{planning_artifacts}/*ux*.md`
|
- Whole: `{planning_artifacts}/*ux*.md`
|
||||||
- Sharded: `{planning_artifacts}/*ux*/index.md` and related files
|
- Sharded: `{planning_artifacts}/*ux*/index.md` and related files
|
||||||
|
|
||||||
|
#### E. Infrastructure Documents (Optional)
|
||||||
|
|
||||||
|
- Whole: `{planning_artifacts}/*infrastructure*.md`
|
||||||
|
- Sharded: `{planning_artifacts}/*infrastructure*/index.md` and related files
|
||||||
|
|
||||||
|
#### F. Pipeline Documents (Optional)
|
||||||
|
|
||||||
|
- Whole: `{planning_artifacts}/*pipeline*.md`
|
||||||
|
- Sharded: `{planning_artifacts}/*pipeline*/index.md` and related files
|
||||||
|
|
||||||
### 3. Organize Findings
|
### 3. Organize Findings
|
||||||
|
|
||||||
For each document type found:
|
For each document type found:
|
||||||
|
|
|
||||||
|
|
@ -60,6 +60,37 @@ Check the {outputFile} for sections added by previous steps:
|
||||||
- UX Alignment issues
|
- UX Alignment issues
|
||||||
- Epic Quality violations
|
- Epic Quality violations
|
||||||
|
|
||||||
|
### 2b. Infrastructure and Deployment Readiness (if documents exist)
|
||||||
|
|
||||||
|
If infrastructure.md or pipeline.md were discovered in Step 1, validate operational readiness:
|
||||||
|
|
||||||
|
**Infrastructure Readiness:**
|
||||||
|
|
||||||
|
- IaC strategy defined (tool, state management, module design)
|
||||||
|
- Environment topology documented (dev, staging, production)
|
||||||
|
- Secrets management approach decided
|
||||||
|
- Container strategy defined (if applicable)
|
||||||
|
- Alignment with Architecture Category 5 decisions
|
||||||
|
|
||||||
|
**Pipeline Readiness:**
|
||||||
|
|
||||||
|
- CI/CD platform selected and pipeline stages designed
|
||||||
|
- Deployment strategy decided (blue-green, canary, rolling, etc.)
|
||||||
|
- Rollback procedures documented
|
||||||
|
- Security scanning integrated into pipeline stages
|
||||||
|
- Promotion gates defined between environments
|
||||||
|
|
||||||
|
**If infrastructure/pipeline documents are MISSING but Architecture Category 5 includes infrastructure decisions:**
|
||||||
|
|
||||||
|
```
|
||||||
|
⚠️ ADVISORY: Architecture includes infrastructure decisions but no dedicated
|
||||||
|
infrastructure or pipeline documents exist. Consider running the DevOps
|
||||||
|
workflows (bmad-create-infrastructure, bmad-create-pipeline) before
|
||||||
|
implementation to ensure deployment readiness.
|
||||||
|
```
|
||||||
|
|
||||||
|
Add infrastructure/deployment findings to the assessment report.
|
||||||
|
|
||||||
### 3. Add Final Assessment Section
|
### 3. Add Final Assessment Section
|
||||||
|
|
||||||
Append to {outputFile}:
|
Append to {outputFile}:
|
||||||
|
|
|
||||||
|
|
@ -121,6 +121,11 @@ Based on technical preferences, starter template choice, and project context, id
|
||||||
- Monitoring and logging
|
- Monitoring and logging
|
||||||
- Scaling strategy
|
- Scaling strategy
|
||||||
|
|
||||||
|
> **DevOps Deep Dive:** For detailed infrastructure-as-code, environment topology, container orchestration, and CI/CD pipeline design decisions, use the dedicated DevOps workflows after completing architecture decisions:
|
||||||
|
>
|
||||||
|
> - `bmad-create-infrastructure` — IaC tool selection, state management, environment strategy, container orchestration
|
||||||
|
> - `bmad-create-pipeline` — Pipeline stage design, deployment strategies, promotion gates, rollback procedures
|
||||||
|
|
||||||
### 3. Facilitate Each Decision Category
|
### 3. Facilitate Each Decision Category
|
||||||
|
|
||||||
For each category, facilitate collaborative decision making:
|
For each category, facilitate collaborative decision making:
|
||||||
|
|
@ -236,6 +241,8 @@ After facilitating all decision categories, prepare the content to append:
|
||||||
|
|
||||||
{{infrastructure_related_decisions_with_versions_and_rationale}}
|
{{infrastructure_related_decisions_with_versions_and_rationale}}
|
||||||
|
|
||||||
|
> _For detailed infrastructure and pipeline decisions, see the dedicated DevOps workflows: `bmad-create-infrastructure` and `bmad-create-pipeline`._
|
||||||
|
|
||||||
### Decision Impact Analysis
|
### Decision Impact Analysis
|
||||||
|
|
||||||
**Implementation Sequence:**
|
**Implementation Sequence:**
|
||||||
|
|
|
||||||
|
|
@ -69,6 +69,16 @@ Search for required documents using these patterns (sharded means a large docume
|
||||||
1. `{planning_artifacts}/*ux*.md` (whole document)
|
1. `{planning_artifacts}/*ux*.md` (whole document)
|
||||||
2. `{planning_artifacts}/*ux*/index.md` (sharded version)
|
2. `{planning_artifacts}/*ux*/index.md` (sharded version)
|
||||||
|
|
||||||
|
**Infrastructure Document Search (Optional):**
|
||||||
|
|
||||||
|
1. `{planning_artifacts}/*infrastructure*.md` (whole document)
|
||||||
|
2. `{planning_artifacts}/*infrastructure*/index.md` (sharded version)
|
||||||
|
|
||||||
|
**Pipeline Document Search (Optional):**
|
||||||
|
|
||||||
|
1. `{planning_artifacts}/*pipeline*.md` (whole document)
|
||||||
|
2. `{planning_artifacts}/*pipeline*/index.md` (sharded version)
|
||||||
|
|
||||||
Before proceeding, Ask the user if there are any other documents to include for analysis, and if anything found should be excluded. Wait for user confirmation. Once confirmed, create the {planning_artifacts}/epics.md from the ../templates/epics-template.md and in the front matter list the files in the array of `inputDocuments: []`.
|
Before proceeding, Ask the user if there are any other documents to include for analysis, and if anything found should be excluded. Wait for user confirmation. Once confirmed, create the {planning_artifacts}/epics.md from the ../templates/epics-template.md and in the front matter list the files in the array of `inputDocuments: []`.
|
||||||
|
|
||||||
### 3. Extract Functional Requirements (FRs)
|
### 3. Extract Functional Requirements (FRs)
|
||||||
|
|
@ -123,6 +133,36 @@ Review the Architecture document for technical requirements that impact epic and
|
||||||
|
|
||||||
**IMPORTANT**: If a starter template is mentioned in Architecture, note it prominently. This will impact Epic 1 Story 1.
|
**IMPORTANT**: If a starter template is mentioned in Architecture, note it prominently. This will impact Epic 1 Story 1.
|
||||||
|
|
||||||
|
### 5b. Extract Infrastructure and Pipeline Requirements (if documents exist)
|
||||||
|
|
||||||
|
If infrastructure.md or pipeline.md were discovered, extract operational requirements that need implementation stories:
|
||||||
|
|
||||||
|
**From Infrastructure Document, look for:**
|
||||||
|
|
||||||
|
- IaC setup requirements (Terraform modules, CDK stacks, etc.)
|
||||||
|
- Environment provisioning automation
|
||||||
|
- Container orchestration setup (Dockerfiles, Helm charts, K8s manifests)
|
||||||
|
- Secrets management implementation
|
||||||
|
- Policy-as-code rules
|
||||||
|
|
||||||
|
**From Pipeline Document, look for:**
|
||||||
|
|
||||||
|
- CI/CD pipeline setup requirements (workflow files, pipeline configs)
|
||||||
|
- Security scanning tool integration
|
||||||
|
- Deployment automation scripts
|
||||||
|
- Promotion gate configurations
|
||||||
|
- Monitoring and alerting setup for pipeline health
|
||||||
|
|
||||||
|
**Format as part of Additional Requirements, prefixed for clarity:**
|
||||||
|
|
||||||
|
```
|
||||||
|
- [INFRA] IaC module setup for [environment topology]
|
||||||
|
- [INFRA] Container orchestration configuration
|
||||||
|
- [PIPELINE] CI/CD pipeline with [stages] for [platform]
|
||||||
|
- [PIPELINE] Deployment automation using [strategy]
|
||||||
|
...
|
||||||
|
```
|
||||||
|
|
||||||
**Format Additional Requirements as:**
|
**Format Additional Requirements as:**
|
||||||
|
|
||||||
```
|
```
|
||||||
|
|
|
||||||
|
|
@ -0,0 +1,6 @@
|
||||||
|
---
|
||||||
|
name: bmad-create-infrastructure
|
||||||
|
description: 'Define infrastructure-as-code strategy, environment topology, and deployment foundations. Use when the user says "create infrastructure plan" or "define infrastructure strategy" or "plan the infrastructure"'
|
||||||
|
---
|
||||||
|
|
||||||
|
Follow the instructions in ./workflow.md.
|
||||||
|
|
@ -0,0 +1,12 @@
|
||||||
|
---
|
||||||
|
stepsCompleted: []
|
||||||
|
inputDocuments: []
|
||||||
|
workflowType: 'infrastructure'
|
||||||
|
project_name: '{{project_name}}'
|
||||||
|
user_name: '{{user_name}}'
|
||||||
|
date: '{{date}}'
|
||||||
|
---
|
||||||
|
|
||||||
|
# Infrastructure Decision Document
|
||||||
|
|
||||||
|
_This document builds collaboratively through step-by-step discovery. Sections are appended as we work through each infrastructure decision together._
|
||||||
|
|
@ -0,0 +1,172 @@
|
||||||
|
# Step 1: Infrastructure Workflow Initialization
|
||||||
|
|
||||||
|
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||||
|
|
||||||
|
- 🛑 NEVER generate content without user input
|
||||||
|
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||||
|
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||||
|
- ✅ ALWAYS treat this as collaborative discovery between infrastructure peers
|
||||||
|
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||||
|
- 💬 FOCUS on initialization and setup only - don't look ahead to future steps
|
||||||
|
- 🚪 DETECT existing workflow state and handle continuation properly
|
||||||
|
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||||
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||||
|
|
||||||
|
## EXECUTION PROTOCOLS:
|
||||||
|
|
||||||
|
- 🎯 Show your analysis before taking any action
|
||||||
|
- 💾 Initialize document and update frontmatter
|
||||||
|
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
|
||||||
|
- 🚫 FORBIDDEN to load next step until setup is complete
|
||||||
|
|
||||||
|
## CONTEXT BOUNDARIES:
|
||||||
|
|
||||||
|
- Variables from workflow.md are available in memory
|
||||||
|
- Previous context = what's in output document + frontmatter
|
||||||
|
- Don't assume knowledge from other steps
|
||||||
|
- Input document discovery happens in this step
|
||||||
|
|
||||||
|
## YOUR TASK:
|
||||||
|
|
||||||
|
Initialize the Infrastructure workflow by detecting continuation state, discovering input documents, scanning for existing infrastructure indicators, and setting up the document for collaborative infrastructure decision making.
|
||||||
|
|
||||||
|
## INITIALIZATION SEQUENCE:
|
||||||
|
|
||||||
|
### 1. Check for Existing Workflow
|
||||||
|
|
||||||
|
First, check if the output document already exists:
|
||||||
|
|
||||||
|
- Look for existing {planning_artifacts}/`*infrastructure*.md`
|
||||||
|
- If exists, read the complete file including frontmatter
|
||||||
|
- If not exists, this is a fresh workflow
|
||||||
|
|
||||||
|
### 2. Handle Continuation (If Document Exists)
|
||||||
|
|
||||||
|
If the document exists and has frontmatter with `stepsCompleted`:
|
||||||
|
|
||||||
|
- Read the document to determine the last completed step
|
||||||
|
- Report what was previously completed
|
||||||
|
- Ask the user which step to resume from
|
||||||
|
- Load the appropriate step file
|
||||||
|
|
||||||
|
### 3. Fresh Workflow Setup (If No Document)
|
||||||
|
|
||||||
|
If no document exists or no `stepsCompleted` in frontmatter:
|
||||||
|
|
||||||
|
#### A. Input Document Discovery
|
||||||
|
|
||||||
|
Discover and load context documents using smart discovery. Documents can be in the following locations:
|
||||||
|
- {planning_artifacts}/**
|
||||||
|
- {project_knowledge}/**
|
||||||
|
- {project-root}/docs/**
|
||||||
|
|
||||||
|
Also - when searching - documents can be a single markdown file, or a folder with an index and multiple files. For example, if searching for `*foo*.md` and not found, also search for a folder called *foo*/index.md (which indicates sharded content)
|
||||||
|
|
||||||
|
Try to discover the following:
|
||||||
|
- Architecture Document (`*architecture*.md`)
|
||||||
|
- Product Requirements Document (`*prd*.md`)
|
||||||
|
- Project Context (`**/project-context.md`)
|
||||||
|
|
||||||
|
<critical>Confirm what you have found with the user, along with asking if the user wants to provide anything else. Only after this confirmation will you proceed to follow the loading rules</critical>
|
||||||
|
|
||||||
|
**Loading Rules:**
|
||||||
|
|
||||||
|
- Load ALL discovered files completely that the user confirmed or provided (no offset/limit)
|
||||||
|
- If there is a project context, whatever is relevant should try to be biased in the remainder of this whole workflow process
|
||||||
|
- For sharded folders, load ALL files to get complete picture, using the index first to potentially know the potential of each document
|
||||||
|
- index.md is a guide to what's relevant whenever available
|
||||||
|
- Track all successfully loaded files in frontmatter `inputDocuments` array
|
||||||
|
|
||||||
|
#### B. Scan for Existing Infrastructure Indicators
|
||||||
|
|
||||||
|
Scan the project for existing infrastructure-as-code artifacts:
|
||||||
|
|
||||||
|
**IaC Files:**
|
||||||
|
- `*.tf`, `*.tfvars` (Terraform)
|
||||||
|
- `Pulumi.*` (Pulumi)
|
||||||
|
- `cdk.json` (AWS CDK)
|
||||||
|
- `serverless.yml` (Serverless Framework)
|
||||||
|
|
||||||
|
**Container Files:**
|
||||||
|
- `Dockerfile`, `docker-compose*.yml`
|
||||||
|
- `k8s/` directory
|
||||||
|
|
||||||
|
**CI/CD Files:**
|
||||||
|
- `.github/workflows/` directory
|
||||||
|
- `.gitlab-ci.yml`
|
||||||
|
- `Jenkinsfile`
|
||||||
|
|
||||||
|
Report all indicators found. These inform later decisions in steps 2-4.
|
||||||
|
|
||||||
|
#### C. Extract Architecture Category 5 Context
|
||||||
|
|
||||||
|
If `architecture.md` was discovered:
|
||||||
|
- Look for **Category 5: Infrastructure & Deployment** decisions
|
||||||
|
- Extract any existing infrastructure-related decisions as starting context
|
||||||
|
- These become the foundation for more detailed infrastructure planning
|
||||||
|
|
||||||
|
#### D. Create Initial Document
|
||||||
|
|
||||||
|
Copy the template from `../infrastructure-template.md` to `{planning_artifacts}/infrastructure.md`
|
||||||
|
|
||||||
|
#### E. Complete Initialization and Report
|
||||||
|
|
||||||
|
Complete setup and report to user:
|
||||||
|
|
||||||
|
**Document Setup:**
|
||||||
|
|
||||||
|
- Created: `{planning_artifacts}/infrastructure.md` from template
|
||||||
|
- Initialized frontmatter with workflow state
|
||||||
|
|
||||||
|
**Report to User:**
|
||||||
|
"Welcome {{user_name}}! I've set up your Infrastructure workspace for {{project_name}}.
|
||||||
|
|
||||||
|
**Documents Found:**
|
||||||
|
|
||||||
|
- Architecture: {found or "None found"}
|
||||||
|
- PRD: {found or "None found"}
|
||||||
|
- Project Context: {found or "None found"}
|
||||||
|
|
||||||
|
**Existing Infrastructure Indicators:**
|
||||||
|
|
||||||
|
- IaC files: {list or "None found"}
|
||||||
|
- Container files: {list or "None found"}
|
||||||
|
- CI/CD files: {list or "None found"}
|
||||||
|
|
||||||
|
**Architecture Category 5 Context:**
|
||||||
|
{extracted decisions or "No prior infrastructure decisions found"}
|
||||||
|
|
||||||
|
**Files loaded:** {list of specific file names or "No additional documents found"}
|
||||||
|
|
||||||
|
Ready to begin infrastructure decision making. Do you have any other documents or context you'd like me to include?
|
||||||
|
|
||||||
|
[C] Continue to IaC Strategy decisions
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ Existing workflow detected and continuation handled correctly
|
||||||
|
✅ Fresh workflow initialized with template and frontmatter
|
||||||
|
✅ Input documents discovered and loaded using sharded-first logic
|
||||||
|
✅ All discovered files tracked in frontmatter `inputDocuments`
|
||||||
|
✅ Existing infrastructure indicators scanned and reported
|
||||||
|
✅ Architecture Category 5 decisions extracted as starting context
|
||||||
|
✅ User confirmed document setup and can proceed
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Proceeding with fresh initialization when existing workflow exists
|
||||||
|
❌ Not updating frontmatter with discovered input documents
|
||||||
|
❌ Creating document without proper template
|
||||||
|
❌ Not scanning for existing infrastructure indicators
|
||||||
|
❌ Not extracting Architecture Category 5 context when available
|
||||||
|
❌ Not reporting what documents and indicators were found to user
|
||||||
|
|
||||||
|
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||||
|
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||||
|
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||||
|
|
||||||
|
## NEXT STEP:
|
||||||
|
|
||||||
|
After user selects [C] to continue, only after ensuring all the template output has been created, then load `./step-02-iac-strategy.md` to begin IaC strategy decisions.
|
||||||
|
|
||||||
|
Remember: Do NOT proceed to step-02 until user explicitly selects [C] from the menu and setup is confirmed!
|
||||||
|
|
@ -0,0 +1,270 @@
|
||||||
|
# Step 2: Infrastructure-as-Code Strategy
|
||||||
|
|
||||||
|
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||||
|
|
||||||
|
- 🛑 NEVER generate content without user input
|
||||||
|
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||||
|
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||||
|
- ✅ ALWAYS treat this as collaborative discovery between infrastructure peers
|
||||||
|
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||||
|
- 💬 FOCUS on making IaC strategy decisions collaboratively
|
||||||
|
- 🌐 ALWAYS search the web to verify current technology versions
|
||||||
|
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||||
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||||
|
|
||||||
|
## EXECUTION PROTOCOLS:
|
||||||
|
|
||||||
|
- 🎯 Show your analysis before taking any action
|
||||||
|
- 🌐 Search the web to verify technology versions and options
|
||||||
|
- ⚠️ Present A/P/C menu after each major decision category
|
||||||
|
- 💾 ONLY save when user chooses C (Continue)
|
||||||
|
- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
|
||||||
|
- 🚫 FORBIDDEN to load next step until C is selected
|
||||||
|
|
||||||
|
## COLLABORATION MENUS (A/P/C):
|
||||||
|
|
||||||
|
This step will generate content and present choices for each decision category:
|
||||||
|
|
||||||
|
- **A (Advanced Elicitation)**: Use discovery protocols to explore innovative approaches to specific decisions
|
||||||
|
- **P (Party Mode)**: Bring multiple perspectives to evaluate decision trade-offs
|
||||||
|
- **C (Continue)**: Save the current decisions and proceed to next decision category
|
||||||
|
|
||||||
|
## PROTOCOL INTEGRATION:
|
||||||
|
|
||||||
|
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||||
|
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||||
|
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||||
|
- User accepts/rejects protocol changes before proceeding
|
||||||
|
|
||||||
|
## CONTEXT BOUNDARIES:
|
||||||
|
|
||||||
|
- Infrastructure indicators from step 1 are available
|
||||||
|
- Architecture Category 5 decisions from step 1 are available
|
||||||
|
- Project context file may contain infrastructure preferences and rules
|
||||||
|
- Focus on IaC strategy decisions only - environment strategy is in step 3
|
||||||
|
- Collaborative decision making, not recommendations
|
||||||
|
|
||||||
|
## YOUR TASK:
|
||||||
|
|
||||||
|
Facilitate collaborative IaC strategy decision making, leveraging existing infrastructure indicators and architecture decisions as starting context.
|
||||||
|
|
||||||
|
## DECISION MAKING SEQUENCE:
|
||||||
|
|
||||||
|
### 1. Load Context from Step 1
|
||||||
|
|
||||||
|
Review what was discovered in initialization:
|
||||||
|
- Existing IaC indicators found in the project
|
||||||
|
- Architecture Category 5 decisions (if any)
|
||||||
|
- Project context preferences
|
||||||
|
|
||||||
|
### 2. Decision Categories
|
||||||
|
|
||||||
|
#### Category 1: IaC Tool Selection
|
||||||
|
|
||||||
|
Present the decision with skill-level-appropriate explanations:
|
||||||
|
|
||||||
|
**Expert Mode:**
|
||||||
|
"IaC Tool Selection: Terraform, Pulumi, AWS CDK, CloudFormation, Crossplane
|
||||||
|
|
||||||
|
Options with trade-offs:
|
||||||
|
- **Terraform** - HCL declarative, cloud-agnostic, massive provider ecosystem, state management overhead
|
||||||
|
- **Pulumi** - General-purpose languages (TS/Python/Go), cloud-agnostic, familiar programming constructs
|
||||||
|
- **AWS CDK** - TypeScript/Python, AWS-native, CloudFormation under the hood, strong typing
|
||||||
|
- **CloudFormation** - AWS-native, YAML/JSON, no state management needed, AWS-only
|
||||||
|
- **Crossplane** - Kubernetes-native, GitOps-aligned, control plane approach, steeper learning curve
|
||||||
|
|
||||||
|
What's your preference?"
|
||||||
|
|
||||||
|
**Intermediate Mode:**
|
||||||
|
"We need to choose our Infrastructure-as-Code tool. This is how we'll define and manage all our cloud resources as code instead of clicking through consoles.
|
||||||
|
|
||||||
|
Common options:
|
||||||
|
- **Terraform** - The industry standard. Uses its own language (HCL). Works with any cloud provider. Huge community.
|
||||||
|
- **Pulumi** - Write infrastructure in languages you already know (TypeScript, Python). Newer but growing fast.
|
||||||
|
- **AWS CDK** - Best if you're all-in on AWS. Uses TypeScript or Python to generate CloudFormation.
|
||||||
|
- **CloudFormation** - AWS's built-in tool. No extra state management. AWS-only.
|
||||||
|
- **Crossplane** - If you're already deep into Kubernetes. Manages cloud resources like K8s resources.
|
||||||
|
|
||||||
|
For your project, I'd lean toward {{recommendation}} because {{reason}}. What are your thoughts?"
|
||||||
|
|
||||||
|
**Beginner Mode:**
|
||||||
|
"Let's talk about Infrastructure-as-Code (IaC).
|
||||||
|
|
||||||
|
Instead of manually setting up servers and databases through a web console, IaC lets you describe your infrastructure in files - like a recipe for your cloud setup. Anyone can recreate the exact same environment from these files.
|
||||||
|
|
||||||
|
Think of it like the difference between cooking from memory vs. having a detailed recipe. The recipe ensures consistency every time.
|
||||||
|
|
||||||
|
Your main options:
|
||||||
|
- **Terraform** - Most popular. Like a universal recipe book that works with any kitchen (cloud provider). Great community support.
|
||||||
|
- **Pulumi** - Uses programming languages you might already know. Like writing recipes in your native language instead of learning a new one.
|
||||||
|
- **AWS CDK** - Best if your kitchen is exclusively AWS. Generates the native AWS recipe format automatically.
|
||||||
|
|
||||||
|
My suggestion: {{recommendation}}
|
||||||
|
This is good for you because {{beginner_friendly_reason}}.
|
||||||
|
|
||||||
|
What feels right to you?"
|
||||||
|
|
||||||
|
**Verify Technology Versions:**
|
||||||
|
```
|
||||||
|
Search the web: "{{selected_tool}} latest stable version"
|
||||||
|
Search the web: "{{selected_tool}} current LTS version"
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Category 2: State Management
|
||||||
|
|
||||||
|
- Remote backend selection (S3+DynamoDB, GCS, Azure Blob, Terraform Cloud, Pulumi Cloud)
|
||||||
|
- State locking mechanism
|
||||||
|
- Workspace/stack strategy (per-environment, per-component, or hybrid)
|
||||||
|
- State file organization and access control
|
||||||
|
|
||||||
|
#### Category 3: Module/Component Design
|
||||||
|
|
||||||
|
- Module structure for reusability (monorepo vs multi-repo)
|
||||||
|
- Shared module registry strategy
|
||||||
|
- Versioning approach for infrastructure modules
|
||||||
|
- Composability patterns (root modules, child modules, data sources)
|
||||||
|
|
||||||
|
#### Category 4: Policy-as-Code
|
||||||
|
|
||||||
|
- Policy engine selection (OPA/Rego, Sentinel, Checkov, tfsec, Bridgecrew)
|
||||||
|
- Policy scope (security, cost, compliance, naming conventions)
|
||||||
|
- Enforcement model (advisory, soft-mandatory, hard-mandatory)
|
||||||
|
- Integration with CI/CD pipeline
|
||||||
|
|
||||||
|
#### Category 5: Drift Detection and Remediation
|
||||||
|
|
||||||
|
- Drift detection approach (scheduled plans, continuous monitoring)
|
||||||
|
- Remediation strategy (auto-fix, alert-and-review, manual)
|
||||||
|
- Notification and alerting integration
|
||||||
|
- Reconciliation workflow
|
||||||
|
|
||||||
|
### 3. Facilitate Each Decision Category
|
||||||
|
|
||||||
|
For each category:
|
||||||
|
- Present the decision context with skill-level-appropriate explanation
|
||||||
|
- Reference any existing indicators or Architecture Category 5 decisions
|
||||||
|
- Get user input
|
||||||
|
- Record decision with rationale
|
||||||
|
|
||||||
|
**Record Each Decision:**
|
||||||
|
|
||||||
|
- Category: {{category}}
|
||||||
|
- Decision: {{user_choice}}
|
||||||
|
- Version: {{verified_version_if_applicable}}
|
||||||
|
- Rationale: {{user_reasoning_or_default}}
|
||||||
|
- Affects: {{components_or_environments}}
|
||||||
|
|
||||||
|
### 4. Generate IaC Strategy Content
|
||||||
|
|
||||||
|
After facilitating all decision categories, prepare the content to append:
|
||||||
|
|
||||||
|
#### Content Structure:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## IaC Strategy
|
||||||
|
|
||||||
|
### Tool Selection
|
||||||
|
|
||||||
|
**IaC Tool:** {{selected_tool}} {{version}}
|
||||||
|
**Rationale:** {{rationale}}
|
||||||
|
|
||||||
|
### State Management
|
||||||
|
|
||||||
|
**Backend:** {{backend_choice}}
|
||||||
|
**Locking:** {{locking_mechanism}}
|
||||||
|
**Workspace Strategy:** {{workspace_approach}}
|
||||||
|
**Access Control:** {{access_control_approach}}
|
||||||
|
|
||||||
|
### Module/Component Design
|
||||||
|
|
||||||
|
**Structure:** {{module_structure}}
|
||||||
|
**Registry:** {{registry_strategy}}
|
||||||
|
**Versioning:** {{versioning_approach}}
|
||||||
|
**Composability:** {{composability_patterns}}
|
||||||
|
|
||||||
|
### Policy-as-Code
|
||||||
|
|
||||||
|
**Engine:** {{policy_engine}}
|
||||||
|
**Scope:** {{policy_scope}}
|
||||||
|
**Enforcement:** {{enforcement_model}}
|
||||||
|
**CI/CD Integration:** {{integration_approach}}
|
||||||
|
|
||||||
|
### Drift Detection & Remediation
|
||||||
|
|
||||||
|
**Detection:** {{detection_approach}}
|
||||||
|
**Remediation:** {{remediation_strategy}}
|
||||||
|
**Alerting:** {{alerting_integration}}
|
||||||
|
**Reconciliation:** {{reconciliation_workflow}}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 5. Present Content and Menu
|
||||||
|
|
||||||
|
Show the generated IaC strategy content and present choices:
|
||||||
|
|
||||||
|
"I've documented the IaC strategy decisions we've made together.
|
||||||
|
|
||||||
|
**Here's what I'll add to the document:**
|
||||||
|
|
||||||
|
[Show the complete markdown content from step 4]
|
||||||
|
|
||||||
|
**What would you like to do?**
|
||||||
|
[A] Advanced Elicitation - Explore innovative approaches to any specific decisions
|
||||||
|
[P] Party Mode - Review decisions from multiple perspectives
|
||||||
|
[C] Continue - Save these decisions and move to Environment Strategy"
|
||||||
|
|
||||||
|
### 6. Handle Menu Selection
|
||||||
|
|
||||||
|
#### If 'A' (Advanced Elicitation):
|
||||||
|
|
||||||
|
- Invoke the `bmad-advanced-elicitation` skill with specific decision categories
|
||||||
|
- Process enhanced insights about particular decisions
|
||||||
|
- Ask user: "Accept these enhancements to the IaC strategy? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'P' (Party Mode):
|
||||||
|
|
||||||
|
- Invoke the `bmad-party-mode` skill with IaC strategy context
|
||||||
|
- Process collaborative insights about decision trade-offs
|
||||||
|
- Ask user: "Accept these changes to the IaC strategy? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'C' (Continue):
|
||||||
|
|
||||||
|
- Append the final content to `{planning_artifacts}/infrastructure.md`
|
||||||
|
- Update frontmatter: `stepsCompleted: [1, 2]`
|
||||||
|
- Load `./step-03-environment-strategy.md`
|
||||||
|
|
||||||
|
## APPEND TO DOCUMENT:
|
||||||
|
|
||||||
|
When user selects 'C', append the content directly to the document using the structure from step 4.
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ All IaC strategy decisions made collaboratively
|
||||||
|
✅ Technology versions verified using web search
|
||||||
|
✅ Decision rationale clearly documented
|
||||||
|
✅ Existing infrastructure indicators factored into decisions
|
||||||
|
✅ Architecture Category 5 decisions used as starting context
|
||||||
|
✅ User provided appropriate level of explanation for skill level
|
||||||
|
✅ A/P/C menu presented and handled correctly for each category
|
||||||
|
✅ Content properly appended to document when C selected
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Making recommendations instead of facilitating decisions
|
||||||
|
❌ Not verifying technology versions with web search
|
||||||
|
❌ Ignoring existing infrastructure indicators from step 1
|
||||||
|
❌ Not adapting explanations to user skill level
|
||||||
|
❌ Not presenting A/P/C menu after content generation
|
||||||
|
|
||||||
|
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||||
|
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||||
|
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||||
|
|
||||||
|
## NEXT STEP:
|
||||||
|
|
||||||
|
After user selects 'C' and content is saved to document, load `./step-03-environment-strategy.md` to define environment management strategy.
|
||||||
|
|
||||||
|
Remember: Do NOT proceed to step-03 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||||
|
|
@ -0,0 +1,290 @@
|
||||||
|
# Step 3: Environment Management Strategy
|
||||||
|
|
||||||
|
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||||
|
|
||||||
|
- 🛑 NEVER generate content without user input
|
||||||
|
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||||
|
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||||
|
- ✅ ALWAYS treat this as collaborative discovery between infrastructure peers
|
||||||
|
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||||
|
- 💬 FOCUS on making environment strategy decisions collaboratively
|
||||||
|
- 🌐 ALWAYS search the web to verify current technology versions
|
||||||
|
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||||
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||||
|
|
||||||
|
## EXECUTION PROTOCOLS:
|
||||||
|
|
||||||
|
- 🎯 Show your analysis before taking any action
|
||||||
|
- 🌐 Search the web to verify technology versions and options
|
||||||
|
- ⚠️ Present A/P/C menu after each major decision category
|
||||||
|
- 💾 ONLY save when user chooses C (Continue)
|
||||||
|
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
||||||
|
- 🚫 FORBIDDEN to load next step until C is selected
|
||||||
|
|
||||||
|
## COLLABORATION MENUS (A/P/C):
|
||||||
|
|
||||||
|
This step will generate content and present choices for each decision category:
|
||||||
|
|
||||||
|
- **A (Advanced Elicitation)**: Use discovery protocols to explore innovative approaches to specific decisions
|
||||||
|
- **P (Party Mode)**: Bring multiple perspectives to evaluate decision trade-offs
|
||||||
|
- **C (Continue)**: Save the current decisions and proceed to next decision category
|
||||||
|
|
||||||
|
## PROTOCOL INTEGRATION:
|
||||||
|
|
||||||
|
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||||
|
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||||
|
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||||
|
- User accepts/rejects protocol changes before proceeding
|
||||||
|
|
||||||
|
## CONTEXT BOUNDARIES:
|
||||||
|
|
||||||
|
- IaC strategy decisions from step 2 are available
|
||||||
|
- Infrastructure indicators from step 1 are available
|
||||||
|
- Architecture decisions from step 1 are available
|
||||||
|
- Focus on environment management decisions only - containerization is in step 4
|
||||||
|
- Collaborative decision making, not recommendations
|
||||||
|
|
||||||
|
## YOUR TASK:
|
||||||
|
|
||||||
|
Facilitate collaborative environment management decision making, building on the IaC strategy established in step 2 to define how environments are structured, configured, and managed.
|
||||||
|
|
||||||
|
## DECISION MAKING SEQUENCE:
|
||||||
|
|
||||||
|
### 1. Load Context from Previous Steps
|
||||||
|
|
||||||
|
Review relevant decisions:
|
||||||
|
- IaC tool and state management choices from step 2
|
||||||
|
- Architecture Category 5 environment-related decisions
|
||||||
|
- Existing CI/CD indicators from step 1
|
||||||
|
|
||||||
|
### 2. Decision Categories
|
||||||
|
|
||||||
|
#### Category 1: Environment Topology
|
||||||
|
|
||||||
|
- Define environment tiers (development, staging, QA, production)
|
||||||
|
- Ephemeral/preview environments for pull requests
|
||||||
|
- Environment promotion flow (which environments gate production?)
|
||||||
|
- Shared vs isolated environments (per-developer, per-team, per-feature)
|
||||||
|
|
||||||
|
Present with skill-level-appropriate explanations:
|
||||||
|
|
||||||
|
**Expert Mode:**
|
||||||
|
"Environment Topology: Define your environment tiers and promotion flow.
|
||||||
|
|
||||||
|
Considerations:
|
||||||
|
- Minimal: dev -> prod (fast, risky)
|
||||||
|
- Standard: dev -> staging -> prod (balanced)
|
||||||
|
- Enterprise: dev -> QA -> staging -> prod (thorough)
|
||||||
|
- Plus ephemeral: PR-based preview environments for testing
|
||||||
|
|
||||||
|
What topology fits your team and risk tolerance?"
|
||||||
|
|
||||||
|
**Intermediate Mode:**
|
||||||
|
"We need to decide which environments your project will have. Environments are separate copies of your application - each serving a different purpose.
|
||||||
|
|
||||||
|
Common setups:
|
||||||
|
- **Minimal** (dev + prod) - Fast iteration, but less safety
|
||||||
|
- **Standard** (dev + staging + prod) - Good balance of speed and safety
|
||||||
|
- **Extended** (dev + QA + staging + prod) - More validation gates before production
|
||||||
|
- **With ephemeral** - Temporary environments for each pull request
|
||||||
|
|
||||||
|
For most projects, I'd suggest starting with {{recommendation}}. What makes sense for your team?"
|
||||||
|
|
||||||
|
**Beginner Mode:**
|
||||||
|
"Let's talk about environments.
|
||||||
|
|
||||||
|
Think of environments like dress rehearsals before opening night. You wouldn't perform a play without practicing first - similarly, you want to test your application in conditions similar to production before releasing it to users.
|
||||||
|
|
||||||
|
Your options:
|
||||||
|
- **Development** - Where you build and test daily (like a practice room)
|
||||||
|
- **Staging** - A near-perfect copy of production (like a dress rehearsal)
|
||||||
|
- **Production** - The real thing, what your users see (opening night)
|
||||||
|
- **Ephemeral** - Temporary test environments created automatically for each change
|
||||||
|
|
||||||
|
My suggestion: {{recommendation}}
|
||||||
|
This gives you {{beginner_friendly_reason}}.
|
||||||
|
|
||||||
|
What feels right for your project?"
|
||||||
|
|
||||||
|
#### Category 2: Environment Parity (12-Factor Factor X)
|
||||||
|
|
||||||
|
- Dev/prod parity principles and practical trade-offs
|
||||||
|
- Which services should be identical across environments vs. scaled down
|
||||||
|
- Data parity strategy (anonymized production data, synthetic data, seed data)
|
||||||
|
- Infrastructure parity (same IaC modules with different parameters vs. separate definitions)
|
||||||
|
|
||||||
|
#### Category 3: Configuration Management (12-Factor Factor III)
|
||||||
|
|
||||||
|
- Per-environment configuration approach (env vars, config files, parameter store)
|
||||||
|
- Configuration hierarchy and override strategy
|
||||||
|
- Feature flags vs. environment-specific configuration
|
||||||
|
- Configuration validation and drift detection
|
||||||
|
|
||||||
|
#### Category 4: Secrets Management
|
||||||
|
|
||||||
|
- Secrets management tool (HashiCorp Vault, AWS KMS, Azure Key Vault, GCP Secret Manager, sealed-secrets, SOPS)
|
||||||
|
- Secret rotation policy and automation
|
||||||
|
- Secret injection method (env vars, mounted volumes, sidecar, init container)
|
||||||
|
- Access control and audit logging for secrets
|
||||||
|
|
||||||
|
**Verify Technology Versions:**
|
||||||
|
```
|
||||||
|
Search the web: "{{selected_tool}} latest stable version"
|
||||||
|
Search the web: "{{selected_tool}} secret rotation best practices"
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Category 5: Environment Provisioning and Teardown
|
||||||
|
|
||||||
|
- Environment creation automation (IaC apply, scripts, GitOps)
|
||||||
|
- Teardown automation and scheduling (auto-destroy ephemeral after merge)
|
||||||
|
- Environment bootstrapping (initial data, service accounts, network peering)
|
||||||
|
- Self-service environment creation capabilities
|
||||||
|
|
||||||
|
#### Category 6: Cost Management and Resource Tagging
|
||||||
|
|
||||||
|
- Resource tagging strategy (environment, team, cost-center, project)
|
||||||
|
- Cost allocation and chargeback approach
|
||||||
|
- Non-production environment scheduling (scale down after hours)
|
||||||
|
- Resource cleanup automation for orphaned resources
|
||||||
|
- Budget alerts and spending limits per environment
|
||||||
|
|
||||||
|
### 3. Facilitate Each Decision Category
|
||||||
|
|
||||||
|
For each category:
|
||||||
|
- Present the decision context with skill-level-appropriate explanation
|
||||||
|
- Reference IaC tool choice from step 2 where relevant
|
||||||
|
- Get user input
|
||||||
|
- Record decision with rationale
|
||||||
|
|
||||||
|
**Record Each Decision:**
|
||||||
|
|
||||||
|
- Category: {{category}}
|
||||||
|
- Decision: {{user_choice}}
|
||||||
|
- Rationale: {{user_reasoning_or_default}}
|
||||||
|
- Affects: {{environments_or_workflows}}
|
||||||
|
|
||||||
|
### 4. Generate Environment Strategy Content
|
||||||
|
|
||||||
|
After facilitating all decision categories, prepare the content to append:
|
||||||
|
|
||||||
|
#### Content Structure:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Environment Management Strategy
|
||||||
|
|
||||||
|
### Environment Topology
|
||||||
|
|
||||||
|
**Tiers:** {{environment_tiers}}
|
||||||
|
**Promotion Flow:** {{promotion_flow}}
|
||||||
|
**Ephemeral Environments:** {{ephemeral_strategy}}
|
||||||
|
**Isolation Model:** {{isolation_approach}}
|
||||||
|
|
||||||
|
### Environment Parity (12-Factor X)
|
||||||
|
|
||||||
|
**Parity Principles:** {{parity_approach}}
|
||||||
|
**Service Scaling:** {{service_scaling_per_environment}}
|
||||||
|
**Data Strategy:** {{data_parity_approach}}
|
||||||
|
**Infrastructure Parity:** {{infra_parity_approach}}
|
||||||
|
|
||||||
|
### Configuration Management (12-Factor III)
|
||||||
|
|
||||||
|
**Configuration Approach:** {{config_approach}}
|
||||||
|
**Hierarchy:** {{config_hierarchy}}
|
||||||
|
**Feature Flags:** {{feature_flag_strategy}}
|
||||||
|
**Validation:** {{config_validation_approach}}
|
||||||
|
|
||||||
|
### Secrets Management
|
||||||
|
|
||||||
|
**Tool:** {{secrets_tool}} {{version}}
|
||||||
|
**Rotation:** {{rotation_policy}}
|
||||||
|
**Injection:** {{injection_method}}
|
||||||
|
**Access Control:** {{access_control_approach}}
|
||||||
|
|
||||||
|
### Environment Provisioning & Teardown
|
||||||
|
|
||||||
|
**Creation:** {{creation_automation}}
|
||||||
|
**Teardown:** {{teardown_automation}}
|
||||||
|
**Bootstrapping:** {{bootstrapping_approach}}
|
||||||
|
**Self-Service:** {{self_service_capabilities}}
|
||||||
|
|
||||||
|
### Cost Management & Tagging
|
||||||
|
|
||||||
|
**Tagging Strategy:** {{tagging_strategy}}
|
||||||
|
**Cost Allocation:** {{cost_allocation}}
|
||||||
|
**Scheduling:** {{non_prod_scheduling}}
|
||||||
|
**Cleanup:** {{cleanup_automation}}
|
||||||
|
**Budget Alerts:** {{budget_alert_approach}}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 5. Present Content and Menu
|
||||||
|
|
||||||
|
Show the generated environment strategy content and present choices:
|
||||||
|
|
||||||
|
"I've documented the environment management strategy we've made together.
|
||||||
|
|
||||||
|
**Here's what I'll add to the document:**
|
||||||
|
|
||||||
|
[Show the complete markdown content from step 4]
|
||||||
|
|
||||||
|
**What would you like to do?**
|
||||||
|
[A] Advanced Elicitation - Explore innovative approaches to any specific decisions
|
||||||
|
[P] Party Mode - Review decisions from multiple perspectives
|
||||||
|
[C] Continue - Save these decisions and move to Container Strategy"
|
||||||
|
|
||||||
|
### 6. Handle Menu Selection
|
||||||
|
|
||||||
|
#### If 'A' (Advanced Elicitation):
|
||||||
|
|
||||||
|
- Invoke the `bmad-advanced-elicitation` skill with specific decision categories
|
||||||
|
- Process enhanced insights about particular decisions
|
||||||
|
- Ask user: "Accept these enhancements to the environment strategy? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'P' (Party Mode):
|
||||||
|
|
||||||
|
- Invoke the `bmad-party-mode` skill with environment strategy context
|
||||||
|
- Process collaborative insights about decision trade-offs
|
||||||
|
- Ask user: "Accept these changes to the environment strategy? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'C' (Continue):
|
||||||
|
|
||||||
|
- Append the final content to `{planning_artifacts}/infrastructure.md`
|
||||||
|
- Update frontmatter: `stepsCompleted: [1, 2, 3]`
|
||||||
|
- Load `./step-04-container-strategy.md`
|
||||||
|
|
||||||
|
## APPEND TO DOCUMENT:
|
||||||
|
|
||||||
|
When user selects 'C', append the content directly to the document using the structure from step 4.
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ All environment management decisions made collaboratively
|
||||||
|
✅ Technology versions verified using web search
|
||||||
|
✅ Decision rationale clearly documented
|
||||||
|
✅ 12-Factor principles (Factor III and X) properly addressed
|
||||||
|
✅ Cost management and tagging strategy defined
|
||||||
|
✅ User provided appropriate level of explanation for skill level
|
||||||
|
✅ A/P/C menu presented and handled correctly for each category
|
||||||
|
✅ Content properly appended to document when C selected
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Making recommendations instead of facilitating decisions
|
||||||
|
❌ Not verifying technology versions with web search
|
||||||
|
❌ Ignoring IaC tool choice from step 2 when discussing state/config
|
||||||
|
❌ Not adapting explanations to user skill level
|
||||||
|
❌ Skipping cost management and tagging decisions
|
||||||
|
❌ Not presenting A/P/C menu after content generation
|
||||||
|
|
||||||
|
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||||
|
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||||
|
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||||
|
|
||||||
|
## NEXT STEP:
|
||||||
|
|
||||||
|
After user selects 'C' and content is saved to document, load `./step-04-container-strategy.md` to define containerization strategy.
|
||||||
|
|
||||||
|
Remember: Do NOT proceed to step-04 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||||
|
|
@ -0,0 +1,320 @@
|
||||||
|
# Step 4: Containerization Strategy
|
||||||
|
|
||||||
|
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||||
|
|
||||||
|
- 🛑 NEVER generate content without user input
|
||||||
|
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||||
|
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||||
|
- ✅ ALWAYS treat this as collaborative discovery between infrastructure peers
|
||||||
|
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||||
|
- 💬 FOCUS on making containerization decisions collaboratively
|
||||||
|
- 🌐 ALWAYS search the web to verify current technology versions
|
||||||
|
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||||
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||||
|
|
||||||
|
## EXECUTION PROTOCOLS:
|
||||||
|
|
||||||
|
- 🎯 Show your analysis before taking any action
|
||||||
|
- 🌐 Search the web to verify technology versions and options
|
||||||
|
- ⚠️ Present A/P/C menu after each major decision category
|
||||||
|
- 💾 ONLY save when user chooses C (Continue)
|
||||||
|
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
||||||
|
- 🚫 FORBIDDEN to load next step until C is selected
|
||||||
|
|
||||||
|
## COLLABORATION MENUS (A/P/C):
|
||||||
|
|
||||||
|
This step will generate content and present choices for each decision category:
|
||||||
|
|
||||||
|
- **A (Advanced Elicitation)**: Use discovery protocols to explore innovative approaches to specific decisions
|
||||||
|
- **P (Party Mode)**: Bring multiple perspectives to evaluate decision trade-offs
|
||||||
|
- **C (Continue)**: Save the current decisions and proceed to next decision category
|
||||||
|
|
||||||
|
## PROTOCOL INTEGRATION:
|
||||||
|
|
||||||
|
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||||
|
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||||
|
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||||
|
- User accepts/rejects protocol changes before proceeding
|
||||||
|
|
||||||
|
## CONTEXT BOUNDARIES:
|
||||||
|
|
||||||
|
- IaC strategy from step 2 is available
|
||||||
|
- Environment strategy from step 3 is available
|
||||||
|
- Infrastructure indicators from step 1 are available (container-related files)
|
||||||
|
- Focus on containerization decisions only - validation is in step 5
|
||||||
|
- Collaborative decision making, not recommendations
|
||||||
|
|
||||||
|
## YOUR TASK:
|
||||||
|
|
||||||
|
Facilitate collaborative containerization decision making. First determine if the project should use containers at all, then if applicable, define the complete containerization strategy.
|
||||||
|
|
||||||
|
## DECISION MAKING SEQUENCE:
|
||||||
|
|
||||||
|
### 1. Assess Containerization Context
|
||||||
|
|
||||||
|
Review what was discovered in step 1:
|
||||||
|
- Were any container files found? (`Dockerfile`, `docker-compose*.yml`, `k8s/`)
|
||||||
|
- What does the Architecture document say about deployment?
|
||||||
|
- What IaC tool was chosen in step 2?
|
||||||
|
|
||||||
|
### 2. Initial Decision: Should This Project Use Containers?
|
||||||
|
|
||||||
|
**If container indicators were found in step 1:**
|
||||||
|
"I found existing container artifacts in your project: {{found_artifacts}}. Let's build on these and define a comprehensive containerization strategy."
|
||||||
|
|
||||||
|
Proceed directly to decision categories.
|
||||||
|
|
||||||
|
**If NO container indicators were found:**
|
||||||
|
|
||||||
|
Present the decision with skill-level-appropriate trade-off analysis:
|
||||||
|
|
||||||
|
**Expert Mode:**
|
||||||
|
"No containerization indicators found. Should this project use containers?
|
||||||
|
|
||||||
|
Trade-offs:
|
||||||
|
- **Containerized**: Consistent environments, portable, orchestration ecosystem, image management overhead
|
||||||
|
- **Serverless/PaaS**: Managed infrastructure, auto-scaling, vendor lock-in, cold starts
|
||||||
|
- **VM-based**: Full OS control, simpler networking, larger resource footprint, slower provisioning
|
||||||
|
- **Hybrid**: Mix approaches per service based on requirements
|
||||||
|
|
||||||
|
Your project characteristics suggest {{analysis}}. What's your preference?"
|
||||||
|
|
||||||
|
**Intermediate Mode:**
|
||||||
|
"Your project doesn't currently use containers. Let's decide if it should.
|
||||||
|
|
||||||
|
**Containers** (Docker, Kubernetes):
|
||||||
|
- Pros: Same environment everywhere, easy to scale, great tooling ecosystem
|
||||||
|
- Cons: Added complexity, need to manage images and orchestration
|
||||||
|
|
||||||
|
**Serverless/PaaS** (Lambda, Cloud Run, Heroku):
|
||||||
|
- Pros: Zero server management, auto-scaling, pay-per-use
|
||||||
|
- Cons: Vendor lock-in, cold starts, limited runtime options
|
||||||
|
|
||||||
|
**Traditional VMs** (EC2, GCE):
|
||||||
|
- Pros: Full control, simple model, no container overhead
|
||||||
|
- Cons: More manual management, slower to provision
|
||||||
|
|
||||||
|
Based on your project, I'd lean toward {{recommendation}} because {{reason}}. What do you think?"
|
||||||
|
|
||||||
|
**Beginner Mode:**
|
||||||
|
"Let's talk about whether your project should use containers.
|
||||||
|
|
||||||
|
Think of a container like a lunchbox that has everything your application needs to run - the code, settings, and all dependencies. No matter where you open the lunchbox, you get the exact same meal.
|
||||||
|
|
||||||
|
Your options:
|
||||||
|
- **Containers** (Docker) - Pack your app in a lunchbox. Same app everywhere. Very popular in modern development.
|
||||||
|
- **Serverless** (like AWS Lambda) - Don't worry about servers at all. Just upload your code and it runs. Great for simpler apps.
|
||||||
|
- **Traditional servers** - Set up a computer in the cloud and run your app on it. Simple to understand, more to manage.
|
||||||
|
|
||||||
|
My suggestion: {{recommendation}}
|
||||||
|
This is good for you because {{beginner_friendly_reason}}.
|
||||||
|
|
||||||
|
What feels right?"
|
||||||
|
|
||||||
|
**If user chooses "not containerized":**
|
||||||
|
- Record the decision with rationale
|
||||||
|
- Skip to generating a minimal content section noting the decision
|
||||||
|
- Proceed to step 5
|
||||||
|
|
||||||
|
### 3. Decision Categories (If Containerized)
|
||||||
|
|
||||||
|
#### Category 1: Container Runtime Selection
|
||||||
|
|
||||||
|
- Docker (industry standard, widest tooling support)
|
||||||
|
- containerd (lightweight, Kubernetes-native runtime)
|
||||||
|
- Podman (daemonless, rootless by default, Docker-compatible CLI)
|
||||||
|
|
||||||
|
**Verify Technology Versions:**
|
||||||
|
```
|
||||||
|
Search the web: "{{selected_runtime}} latest stable version"
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Category 2: Dockerfile Best Practices
|
||||||
|
|
||||||
|
- Multi-stage builds strategy (builder vs runtime stages)
|
||||||
|
- Base image selection (distroless, alpine, slim, full)
|
||||||
|
- Layer optimization approach (dependency caching, minimal layers)
|
||||||
|
- Security: non-root user, read-only filesystem, minimal packages
|
||||||
|
- `.dockerignore` strategy
|
||||||
|
- Build argument and secret handling during build
|
||||||
|
|
||||||
|
#### Category 3: Container Orchestration
|
||||||
|
|
||||||
|
- Kubernetes (EKS, GKE, AKS, self-managed)
|
||||||
|
- Amazon ECS / Fargate
|
||||||
|
- Google Cloud Run
|
||||||
|
- AWS App Runner
|
||||||
|
- Docker Compose (development/small deployments only)
|
||||||
|
- Nomad
|
||||||
|
|
||||||
|
Present trade-offs based on:
|
||||||
|
- Team expertise and operational readiness
|
||||||
|
- Scale requirements from architecture decisions
|
||||||
|
- Cost implications
|
||||||
|
- Managed vs self-managed preference
|
||||||
|
|
||||||
|
**Verify Technology Versions:**
|
||||||
|
```
|
||||||
|
Search the web: "{{selected_orchestrator}} latest stable version"
|
||||||
|
Search the web: "{{selected_orchestrator}} production best practices"
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Category 4: Registry and Image Management
|
||||||
|
|
||||||
|
- Registry selection (ECR, GCR/Artifact Registry, Docker Hub, GitHub Container Registry, Harbor)
|
||||||
|
- Image tagging strategy (semver, git SHA, branch-based, immutable tags)
|
||||||
|
- Image scanning (Trivy, Snyk Container, ECR scanning, Grype)
|
||||||
|
- Image signing (cosign, Notary, Docker Content Trust)
|
||||||
|
- Retention policy for old images
|
||||||
|
|
||||||
|
#### Category 5: Manifest Management
|
||||||
|
|
||||||
|
- Helm (templated charts, release management, repository ecosystem)
|
||||||
|
- Kustomize (overlay-based, built into kubectl, no templating)
|
||||||
|
- Raw manifests (simple, no abstraction, harder to manage at scale)
|
||||||
|
- CDK8s / Pulumi K8s (programmatic, type-safe, general-purpose languages)
|
||||||
|
|
||||||
|
### 4. Facilitate Each Decision Category
|
||||||
|
|
||||||
|
For each category:
|
||||||
|
- Present the decision context with skill-level-appropriate explanation
|
||||||
|
- Reference container indicators found in step 1
|
||||||
|
- Reference IaC and environment decisions from steps 2-3
|
||||||
|
- Get user input
|
||||||
|
- Record decision with rationale
|
||||||
|
|
||||||
|
**Record Each Decision:**
|
||||||
|
|
||||||
|
- Category: {{category}}
|
||||||
|
- Decision: {{user_choice}}
|
||||||
|
- Version: {{verified_version_if_applicable}}
|
||||||
|
- Rationale: {{user_reasoning_or_default}}
|
||||||
|
- Affects: {{deployment_and_operations}}
|
||||||
|
|
||||||
|
### 5. Generate Container Strategy Content
|
||||||
|
|
||||||
|
After facilitating all decision categories, prepare the content to append:
|
||||||
|
|
||||||
|
#### Content Structure (If Containerized):
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Containerization Strategy
|
||||||
|
|
||||||
|
### Container Runtime
|
||||||
|
|
||||||
|
**Runtime:** {{selected_runtime}} {{version}}
|
||||||
|
**Rationale:** {{rationale}}
|
||||||
|
|
||||||
|
### Dockerfile Standards
|
||||||
|
|
||||||
|
**Build Strategy:** {{multi_stage_approach}}
|
||||||
|
**Base Images:** {{base_image_selection}}
|
||||||
|
**Layer Optimization:** {{layer_strategy}}
|
||||||
|
**Security Practices:** {{security_practices}}
|
||||||
|
**Build Secrets:** {{build_secret_handling}}
|
||||||
|
|
||||||
|
### Container Orchestration
|
||||||
|
|
||||||
|
**Platform:** {{selected_orchestrator}} {{version}}
|
||||||
|
**Management:** {{managed_vs_self_managed}}
|
||||||
|
**Rationale:** {{rationale}}
|
||||||
|
|
||||||
|
### Registry & Image Management
|
||||||
|
|
||||||
|
**Registry:** {{selected_registry}}
|
||||||
|
**Tagging Strategy:** {{tagging_approach}}
|
||||||
|
**Scanning:** {{scanning_tool}}
|
||||||
|
**Signing:** {{signing_approach}}
|
||||||
|
**Retention:** {{retention_policy}}
|
||||||
|
|
||||||
|
### Manifest Management
|
||||||
|
|
||||||
|
**Tool:** {{selected_tool}} {{version}}
|
||||||
|
**Rationale:** {{rationale}}
|
||||||
|
**Structure:** {{manifest_organization}}
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Content Structure (If Not Containerized):
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Containerization Strategy
|
||||||
|
|
||||||
|
### Decision: Not Containerized
|
||||||
|
|
||||||
|
**Deployment Model:** {{chosen_model}} (serverless/VM/PaaS)
|
||||||
|
**Rationale:** {{rationale}}
|
||||||
|
**Future Consideration:** {{when_to_reconsider_containers}}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 6. Present Content and Menu
|
||||||
|
|
||||||
|
Show the generated container strategy content and present choices:
|
||||||
|
|
||||||
|
"I've documented the containerization strategy we've made together.
|
||||||
|
|
||||||
|
**Here's what I'll add to the document:**
|
||||||
|
|
||||||
|
[Show the complete markdown content from step 5]
|
||||||
|
|
||||||
|
**What would you like to do?**
|
||||||
|
[A] Advanced Elicitation - Explore innovative approaches to any specific decisions
|
||||||
|
[P] Party Mode - Review decisions from multiple perspectives
|
||||||
|
[C] Continue - Save these decisions and move to Final Validation"
|
||||||
|
|
||||||
|
### 7. Handle Menu Selection
|
||||||
|
|
||||||
|
#### If 'A' (Advanced Elicitation):
|
||||||
|
|
||||||
|
- Invoke the `bmad-advanced-elicitation` skill with specific decision categories
|
||||||
|
- Process enhanced insights about particular decisions
|
||||||
|
- Ask user: "Accept these enhancements to the container strategy? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'P' (Party Mode):
|
||||||
|
|
||||||
|
- Invoke the `bmad-party-mode` skill with container strategy context
|
||||||
|
- Process collaborative insights about decision trade-offs
|
||||||
|
- Ask user: "Accept these changes to the container strategy? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'C' (Continue):
|
||||||
|
|
||||||
|
- Append the final content to `{planning_artifacts}/infrastructure.md`
|
||||||
|
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
|
||||||
|
- Load `./step-05-validation.md`
|
||||||
|
|
||||||
|
## APPEND TO DOCUMENT:
|
||||||
|
|
||||||
|
When user selects 'C', append the content directly to the document using the structure from step 5.
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ Containerization decision made (use containers or not) with clear rationale
|
||||||
|
✅ If containerized: all container strategy decisions made collaboratively
|
||||||
|
✅ Technology versions verified using web search
|
||||||
|
✅ Decision rationale clearly documented
|
||||||
|
✅ Existing container indicators factored into decisions
|
||||||
|
✅ User provided appropriate level of explanation for skill level
|
||||||
|
✅ A/P/C menu presented and handled correctly for each category
|
||||||
|
✅ Content properly appended to document when C selected
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Assuming containers without asking when no indicators found
|
||||||
|
❌ Making recommendations instead of facilitating decisions
|
||||||
|
❌ Not verifying technology versions with web search
|
||||||
|
❌ Ignoring container indicators from step 1
|
||||||
|
❌ Not adapting explanations to user skill level
|
||||||
|
❌ Not presenting A/P/C menu after content generation
|
||||||
|
|
||||||
|
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||||
|
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||||
|
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||||
|
|
||||||
|
## NEXT STEP:
|
||||||
|
|
||||||
|
After user selects 'C' and content is saved to document, load `./step-05-validation.md` to validate and finalize the infrastructure decision document.
|
||||||
|
|
||||||
|
Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||||
|
|
@ -0,0 +1,269 @@
|
||||||
|
# Step 5: Infrastructure Validation & Completion
|
||||||
|
|
||||||
|
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||||
|
|
||||||
|
- 🛑 NEVER generate content without user input
|
||||||
|
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||||
|
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||||
|
- ✅ ALWAYS treat this as collaborative discovery between infrastructure peers
|
||||||
|
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||||
|
- 💬 FOCUS on validating infrastructure coherence and completeness
|
||||||
|
- ✅ VALIDATE all critical decisions were made
|
||||||
|
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||||
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||||
|
|
||||||
|
## EXECUTION PROTOCOLS:
|
||||||
|
|
||||||
|
- 🎯 Show your analysis before taking any action
|
||||||
|
- ✅ Run comprehensive validation checks on the complete infrastructure document
|
||||||
|
- ⚠️ Present A/P/C menu after generating validation results
|
||||||
|
- 💾 ONLY save when user chooses C (Continue)
|
||||||
|
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` on final save
|
||||||
|
- 🚫 THIS IS THE FINAL STEP IN THIS WORKFLOW
|
||||||
|
|
||||||
|
## COLLABORATION MENUS (A/P/C):
|
||||||
|
|
||||||
|
This step will generate content and present choices:
|
||||||
|
|
||||||
|
- **A (Advanced Elicitation)**: Use discovery protocols to address complex infrastructure concerns found during validation
|
||||||
|
- **P (Party Mode)**: Bring multiple perspectives to resolve validation concerns
|
||||||
|
- **C (Continue)**: Save the validation results and complete the infrastructure document
|
||||||
|
|
||||||
|
## PROTOCOL INTEGRATION:
|
||||||
|
|
||||||
|
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||||
|
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||||
|
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||||
|
- User accepts/rejects protocol changes before proceeding
|
||||||
|
|
||||||
|
## CONTEXT BOUNDARIES:
|
||||||
|
|
||||||
|
- Complete infrastructure document with all sections is available
|
||||||
|
- All infrastructure decisions from steps 2-4 are documented
|
||||||
|
- Architecture document (if available) provides cross-reference context
|
||||||
|
- Focus on validation, gap analysis, and coherence checking
|
||||||
|
|
||||||
|
## YOUR TASK:
|
||||||
|
|
||||||
|
Validate the complete Infrastructure Decision Document for coherence, completeness, and alignment with architecture decisions. Present a summary for final review.
|
||||||
|
|
||||||
|
## VALIDATION SEQUENCE:
|
||||||
|
|
||||||
|
### 1. Present Complete Document Summary
|
||||||
|
|
||||||
|
Read the full `{planning_artifacts}/infrastructure.md` and present a structured summary of all decisions made:
|
||||||
|
|
||||||
|
"Here's a summary of your complete Infrastructure Decision Document:
|
||||||
|
|
||||||
|
**IaC Strategy:**
|
||||||
|
- Tool: {{tool_and_version}}
|
||||||
|
- State: {{state_management}}
|
||||||
|
- Modules: {{module_strategy}}
|
||||||
|
- Policy: {{policy_approach}}
|
||||||
|
- Drift: {{drift_strategy}}
|
||||||
|
|
||||||
|
**Environment Management:**
|
||||||
|
- Topology: {{environment_tiers}}
|
||||||
|
- Parity: {{parity_approach}}
|
||||||
|
- Configuration: {{config_approach}}
|
||||||
|
- Secrets: {{secrets_tool}}
|
||||||
|
- Provisioning: {{provisioning_approach}}
|
||||||
|
- Cost: {{cost_strategy}}
|
||||||
|
|
||||||
|
**Containerization:**
|
||||||
|
- {{containerized_or_not}}
|
||||||
|
- {{key_container_decisions_if_applicable}}"
|
||||||
|
|
||||||
|
### 2. Cross-Reference with Architecture Category 5
|
||||||
|
|
||||||
|
If architecture.md was loaded in step 1:
|
||||||
|
- Compare all infrastructure decisions against Architecture Category 5 (Infrastructure & Deployment)
|
||||||
|
- Identify any alignment issues or contradictions
|
||||||
|
- Report findings:
|
||||||
|
|
||||||
|
"**Architecture Alignment Check:**
|
||||||
|
- {{decision}}: {{aligned/misaligned}} - {{explanation}}
|
||||||
|
- ..."
|
||||||
|
|
||||||
|
If no architecture document:
|
||||||
|
"**Note:** No architecture document was available for cross-reference. Ensure infrastructure decisions are reviewed when the architecture is created."
|
||||||
|
|
||||||
|
### 3. Validate Critical Decisions
|
||||||
|
|
||||||
|
Check that all critical decisions were made based on project type:
|
||||||
|
|
||||||
|
**All Projects Must Have:**
|
||||||
|
- [ ] IaC tool selected with version
|
||||||
|
- [ ] State management strategy defined
|
||||||
|
- [ ] Environment topology defined
|
||||||
|
- [ ] Configuration management approach chosen
|
||||||
|
- [ ] Secrets management tool and strategy defined
|
||||||
|
|
||||||
|
**Containerized Projects Must Also Have:**
|
||||||
|
- [ ] Container runtime selected
|
||||||
|
- [ ] Orchestration platform chosen
|
||||||
|
- [ ] Registry and image management defined
|
||||||
|
- [ ] Dockerfile standards established
|
||||||
|
|
||||||
|
**Missing Decision Handling:**
|
||||||
|
If any critical decisions are missing:
|
||||||
|
"I noticed the following decisions weren't fully addressed:
|
||||||
|
- {{missing_decision}}
|
||||||
|
|
||||||
|
Would you like to address these now, or note them as deferred?"
|
||||||
|
|
||||||
|
### 4. Check for Missing Decisions by Project Type
|
||||||
|
|
||||||
|
Based on the project context and architecture:
|
||||||
|
- Web application: Does it address CDN, static asset hosting, SSL/TLS?
|
||||||
|
- API service: Does it address API gateway, rate limiting infrastructure?
|
||||||
|
- Data-intensive: Does it address data pipeline infrastructure, storage tiers?
|
||||||
|
- Multi-region: Does it address region strategy, failover, data replication?
|
||||||
|
|
||||||
|
Report any gaps relevant to the project type.
|
||||||
|
|
||||||
|
### 5. Generate Validation Content
|
||||||
|
|
||||||
|
Prepare the content to append:
|
||||||
|
|
||||||
|
#### Content Structure:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Infrastructure Validation
|
||||||
|
|
||||||
|
### Decision Summary
|
||||||
|
|
||||||
|
| Area | Key Decision | Status |
|
||||||
|
|------|-------------|--------|
|
||||||
|
| IaC Tool | {{tool}} | ✅ Decided |
|
||||||
|
| State Management | {{backend}} | ✅ Decided |
|
||||||
|
| Environment Topology | {{topology}} | ✅ Decided |
|
||||||
|
| Configuration | {{approach}} | ✅ Decided |
|
||||||
|
| Secrets Management | {{tool}} | ✅ Decided |
|
||||||
|
| Containerization | {{decision}} | ✅ Decided |
|
||||||
|
| {{other_decisions}} | {{details}} | ✅/⚠️ |
|
||||||
|
|
||||||
|
### Architecture Alignment
|
||||||
|
|
||||||
|
{{alignment_findings}}
|
||||||
|
|
||||||
|
### Completeness Assessment
|
||||||
|
|
||||||
|
**Critical Decisions:** {{all_addressed / gaps_identified}}
|
||||||
|
**Project-Type Decisions:** {{relevant_decisions_checked}}
|
||||||
|
**Overall Status:** {{READY / NEEDS_ATTENTION}}
|
||||||
|
|
||||||
|
### Deferred Decisions
|
||||||
|
|
||||||
|
{{any_decisions_explicitly_deferred_with_rationale}}
|
||||||
|
|
||||||
|
### Infrastructure Readiness Assessment
|
||||||
|
|
||||||
|
**Overall Status:** READY FOR PIPELINE DEFINITION
|
||||||
|
|
||||||
|
**Confidence Level:** {{high/medium/low}} based on validation results
|
||||||
|
|
||||||
|
**Key Strengths:**
|
||||||
|
{{list_of_infrastructure_strengths}}
|
||||||
|
|
||||||
|
**Areas for Future Enhancement:**
|
||||||
|
{{areas_that_could_be_improved_later}}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 6. Present Content and Menu
|
||||||
|
|
||||||
|
Show the validation results and present choices:
|
||||||
|
|
||||||
|
"I've completed validation of your Infrastructure Decision Document.
|
||||||
|
|
||||||
|
**Validation Summary:**
|
||||||
|
|
||||||
|
- ✅ Decision coherence validated
|
||||||
|
- ✅ Architecture alignment checked
|
||||||
|
- ✅ Critical decisions verified
|
||||||
|
- ✅ Project-type gaps assessed
|
||||||
|
|
||||||
|
**Here's what I'll add to complete the document:**
|
||||||
|
|
||||||
|
[Show the complete markdown content from step 5]
|
||||||
|
|
||||||
|
**What would you like to do?**
|
||||||
|
[A] Advanced Elicitation - Address any complex infrastructure concerns
|
||||||
|
[P] Party Mode - Review validation from different operational perspectives
|
||||||
|
[C] Continue - Complete the infrastructure document"
|
||||||
|
|
||||||
|
### 7. Handle Menu Selection
|
||||||
|
|
||||||
|
#### If 'A' (Advanced Elicitation):
|
||||||
|
|
||||||
|
- Invoke the `bmad-advanced-elicitation` skill with validation issues
|
||||||
|
- Process enhanced solutions for complex concerns
|
||||||
|
- Ask user: "Accept these infrastructure improvements? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'P' (Party Mode):
|
||||||
|
|
||||||
|
- Invoke the `bmad-party-mode` skill with validation context
|
||||||
|
- Process collaborative insights on infrastructure readiness
|
||||||
|
- Ask user: "Accept these changes to the validation results? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'C' (Continue):
|
||||||
|
|
||||||
|
- Append the final content to `{planning_artifacts}/infrastructure.md`
|
||||||
|
- Update frontmatter:
|
||||||
|
```yaml
|
||||||
|
stepsCompleted: [1, 2, 3, 4, 5]
|
||||||
|
workflowType: 'infrastructure'
|
||||||
|
lastStep: 5
|
||||||
|
status: 'complete'
|
||||||
|
completedAt: '{{current_date}}'
|
||||||
|
```
|
||||||
|
- Save final document to `{planning_artifacts}/infrastructure.md`
|
||||||
|
|
||||||
|
### 8. Report Completion
|
||||||
|
|
||||||
|
Both you and the user completed something important here - give a summary of what you achieved together and congratulate the user.
|
||||||
|
|
||||||
|
"Infrastructure decisions documented. Consider running the pipeline workflow (bmad-create-pipeline) to define your CI/CD strategy, or proceed to Create Epics and Stories to plan implementation."
|
||||||
|
|
||||||
|
Invoke the `bmad-help` skill for next steps guidance.
|
||||||
|
|
||||||
|
Upon completion: offer to answer any questions about the Infrastructure Decision Document.
|
||||||
|
|
||||||
|
## APPEND TO DOCUMENT:
|
||||||
|
|
||||||
|
When user selects 'C', append the content directly to the document using the structure from step 5.
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ Complete infrastructure document summary presented
|
||||||
|
✅ Architecture Category 5 cross-reference completed
|
||||||
|
✅ All critical decisions validated as present
|
||||||
|
✅ Project-type specific gaps identified and addressed
|
||||||
|
✅ Comprehensive validation checklist completed
|
||||||
|
✅ A/P/C menu presented and handled correctly
|
||||||
|
✅ Content properly appended to document when C selected
|
||||||
|
✅ Clear next steps provided to user
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Skipping cross-reference with architecture decisions
|
||||||
|
❌ Not checking for missing critical decisions
|
||||||
|
❌ Missing project-type specific gap analysis
|
||||||
|
❌ Not addressing gaps found during validation
|
||||||
|
❌ Providing incomplete validation summary
|
||||||
|
❌ Not presenting A/P/C menu after content generation
|
||||||
|
❌ Not providing clear next steps after completion
|
||||||
|
|
||||||
|
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||||
|
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||||
|
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||||
|
|
||||||
|
## WORKFLOW COMPLETE:
|
||||||
|
|
||||||
|
This is the final step of the Infrastructure workflow. The user now has a complete, validated infrastructure decision document ready to guide deployment and operations decisions.
|
||||||
|
|
||||||
|
The infrastructure document will serve as the foundation for CI/CD pipeline definition and consistent environment management across the project lifecycle.
|
||||||
|
|
@ -0,0 +1,32 @@
|
||||||
|
# Infrastructure Workflow
|
||||||
|
|
||||||
|
**Goal:** Define infrastructure-as-code decisions and environment strategy through collaborative step-by-step discovery that ensures consistent, reproducible deployments.
|
||||||
|
|
||||||
|
**Your Role:** You are an infrastructure facilitator collaborating with a peer. This is a partnership, not a client-vendor relationship. You bring infrastructure engineering knowledge and operational experience, while the user brings domain expertise and project requirements. Work together as equals to make decisions that prevent deployment drift and environment inconsistencies.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## WORKFLOW ARCHITECTURE
|
||||||
|
|
||||||
|
This uses **micro-file architecture** for disciplined execution:
|
||||||
|
|
||||||
|
- Each step is a self-contained file with embedded rules
|
||||||
|
- Sequential progression with user control at each step
|
||||||
|
- Document state tracked in frontmatter
|
||||||
|
- Append-only document building through conversation
|
||||||
|
- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
|
||||||
|
|
||||||
|
## Activation
|
||||||
|
|
||||||
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
|
2. EXECUTION
|
||||||
|
|
||||||
|
Read fully and follow: `./steps/step-01-init.md` to begin the workflow.
|
||||||
|
|
||||||
|
**Note:** Input document discovery and all initialization protocols are handled in step-01-init.md.
|
||||||
|
|
@ -0,0 +1,6 @@
|
||||||
|
---
|
||||||
|
name: bmad-create-pipeline
|
||||||
|
description: 'Design CI/CD pipeline architecture, deployment strategies, and promotion gates. Use when the user says "create pipeline" or "design CI/CD" or "plan the deployment pipeline"'
|
||||||
|
---
|
||||||
|
|
||||||
|
Follow the instructions in ./workflow.md.
|
||||||
|
|
@ -0,0 +1,12 @@
|
||||||
|
---
|
||||||
|
stepsCompleted: []
|
||||||
|
inputDocuments: []
|
||||||
|
workflowType: 'pipeline'
|
||||||
|
project_name: '{{project_name}}'
|
||||||
|
user_name: '{{user_name}}'
|
||||||
|
date: '{{date}}'
|
||||||
|
---
|
||||||
|
|
||||||
|
# CI/CD Pipeline Decision Document
|
||||||
|
|
||||||
|
_This document builds collaboratively through step-by-step discovery. Sections are appended as we work through each pipeline decision together._
|
||||||
|
|
@ -0,0 +1,183 @@
|
||||||
|
# Step 1: Pipeline Workflow Initialization
|
||||||
|
|
||||||
|
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||||
|
|
||||||
|
- 🛑 NEVER generate content without user input
|
||||||
|
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||||
|
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||||
|
- ✅ ALWAYS treat this as collaborative discovery between pipeline architecture peers
|
||||||
|
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||||
|
- 💬 FOCUS on initialization and setup only - don't look ahead to future steps
|
||||||
|
- 🚪 DETECT existing workflow state and handle continuation properly
|
||||||
|
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||||
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||||
|
|
||||||
|
## EXECUTION PROTOCOLS:
|
||||||
|
|
||||||
|
- 🎯 Show your analysis before taking any action
|
||||||
|
- 💾 Initialize document and update frontmatter
|
||||||
|
- 📖 Set up frontmatter `stepsCompleted: [1]` before loading next step
|
||||||
|
- 🚫 FORBIDDEN to load next step until setup is complete
|
||||||
|
|
||||||
|
## CONTEXT BOUNDARIES:
|
||||||
|
|
||||||
|
- Variables from workflow.md are available in memory
|
||||||
|
- Previous context = what's in output document + frontmatter
|
||||||
|
- Don't assume knowledge from other steps
|
||||||
|
- Input document discovery happens in this step
|
||||||
|
|
||||||
|
## YOUR TASK:
|
||||||
|
|
||||||
|
Initialize the Pipeline workflow by detecting continuation state, discovering input documents, scanning existing CI/CD configurations, extracting infrastructure context, and setting up the document for collaborative pipeline decision making.
|
||||||
|
|
||||||
|
## INITIALIZATION SEQUENCE:
|
||||||
|
|
||||||
|
### 1. Check for Existing Workflow
|
||||||
|
|
||||||
|
First, check if the output document already exists:
|
||||||
|
|
||||||
|
- Look for existing `{planning_artifacts}/*pipeline*.md`
|
||||||
|
- If exists, read the complete file(s) including frontmatter
|
||||||
|
- If not exists, this is a fresh workflow
|
||||||
|
|
||||||
|
### 2. Handle Continuation (If Document Exists)
|
||||||
|
|
||||||
|
If the document exists and has frontmatter with `stepsCompleted`:
|
||||||
|
|
||||||
|
- Read the document to determine last completed step
|
||||||
|
- Report what has been completed so far
|
||||||
|
- Resume from the next uncompleted step
|
||||||
|
- Do not repeat already-completed steps
|
||||||
|
|
||||||
|
### 3. Fresh Workflow Setup (If No Document)
|
||||||
|
|
||||||
|
If no document exists or no `stepsCompleted` in frontmatter:
|
||||||
|
|
||||||
|
#### A. Input Document Discovery
|
||||||
|
|
||||||
|
Discover and load context documents using smart discovery. Documents can be in the following locations:
|
||||||
|
- {planning_artifacts}/**
|
||||||
|
- {output_folder}/**
|
||||||
|
- {project_knowledge}/**
|
||||||
|
- {project-root}/docs/**
|
||||||
|
|
||||||
|
Also - when searching - documents can be a single markdown file, or a folder with an index and multiple files. For Example, if searching for `*foo*.md` and not found, also search for a folder called *foo*/index.md (which indicates sharded content)
|
||||||
|
|
||||||
|
Try to discover the following:
|
||||||
|
- Architecture Document (`*architecture*.md`) - **REQUIRED** - infrastructure section especially
|
||||||
|
- Product Requirements Document (`*prd*.md`)
|
||||||
|
- Infrastructure Document (`*infrastructure*.md`) - if exists
|
||||||
|
- Project Context (`**/project-context.md`)
|
||||||
|
|
||||||
|
<critical>Confirm what you have found with the user, along with asking if the user wants to provide anything else. Only after this confirmation will you proceed to follow the loading rules</critical>
|
||||||
|
|
||||||
|
**Loading Rules:**
|
||||||
|
|
||||||
|
- Load ALL discovered files completely that the user confirmed or provided (no offset/limit)
|
||||||
|
- If there is a project context, whatever is relevant should try to be biased in the remainder of this whole workflow process
|
||||||
|
- For sharded folders, load ALL files to get complete picture, using the index first to potentially know the potential of each document
|
||||||
|
- index.md is a guide to what's relevant whenever available
|
||||||
|
- Track all successfully loaded files in frontmatter `inputDocuments` array
|
||||||
|
|
||||||
|
#### B. Validate Required Inputs
|
||||||
|
|
||||||
|
Before proceeding, verify we have the essential inputs:
|
||||||
|
|
||||||
|
**Architecture Document Validation:**
|
||||||
|
|
||||||
|
- If no architecture document found: "Pipeline design requires an architecture document to work from (especially infrastructure decisions). Please run the architecture workflow first or provide the architecture file path."
|
||||||
|
- Do NOT proceed without architecture document
|
||||||
|
|
||||||
|
#### C. Scan for Existing CI/CD Configuration
|
||||||
|
|
||||||
|
Scan the project root for existing CI/CD configuration files:
|
||||||
|
|
||||||
|
- `.github/workflows/` - GitHub Actions workflow files
|
||||||
|
- `.gitlab-ci.yml` - GitLab CI configuration
|
||||||
|
- `Jenkinsfile` - Jenkins pipeline definition
|
||||||
|
- `.circleci/` - CircleCI configuration
|
||||||
|
- `azure-pipelines.yml` - Azure DevOps Pipelines
|
||||||
|
- `bitbucket-pipelines.yml` - Bitbucket Pipelines
|
||||||
|
- `buildkite/` - Buildkite pipeline configuration
|
||||||
|
- `.drone.yml` - Drone CI configuration
|
||||||
|
|
||||||
|
Report any existing CI/CD configurations found.
|
||||||
|
|
||||||
|
#### D. Extract Infrastructure Context
|
||||||
|
|
||||||
|
From the architecture document and infrastructure document (if exists), extract:
|
||||||
|
|
||||||
|
- **IaC Tool**: What infrastructure-as-code tool is being used (Terraform, Pulumi, CDK, CloudFormation, etc.)
|
||||||
|
- **Container Strategy**: Whether containers are used (Docker, Podman, etc.) and orchestration (Kubernetes, ECS, etc.)
|
||||||
|
- **Environment Topology**: What environments exist (dev, staging, prod, etc.) and their relationships
|
||||||
|
|
||||||
|
These become context for pipeline decisions in subsequent steps.
|
||||||
|
|
||||||
|
#### E. Create Initial Document
|
||||||
|
|
||||||
|
Copy the template from `../pipeline-template.md` to `{planning_artifacts}/pipeline.md`
|
||||||
|
|
||||||
|
#### F. Complete Initialization and Report
|
||||||
|
|
||||||
|
Complete setup and report to user:
|
||||||
|
|
||||||
|
**Document Setup:**
|
||||||
|
|
||||||
|
- Created: `{planning_artifacts}/pipeline.md` from template
|
||||||
|
- Initialized frontmatter with workflow state
|
||||||
|
|
||||||
|
**Report to User:**
|
||||||
|
"Welcome {{user_name}}! I've set up your Pipeline Architecture workspace for {{project_name}}.
|
||||||
|
|
||||||
|
**Documents Found:**
|
||||||
|
|
||||||
|
- Architecture: {architecture document status}
|
||||||
|
- PRD: {PRD status or "None found"}
|
||||||
|
- Infrastructure: {infrastructure document status or "None found"}
|
||||||
|
- Project context: {project_context_rules count of rules for AI agents found}
|
||||||
|
|
||||||
|
**Existing CI/CD Configuration:**
|
||||||
|
{list of existing CI/CD files found or "No existing CI/CD configuration detected"}
|
||||||
|
|
||||||
|
**Infrastructure Context Extracted:**
|
||||||
|
- IaC Tool: {tool or "Not specified"}
|
||||||
|
- Container Strategy: {strategy or "Not specified"}
|
||||||
|
- Environment Topology: {environments or "Not specified"}
|
||||||
|
|
||||||
|
**Files loaded:** {list of specific file names}
|
||||||
|
|
||||||
|
Ready to begin pipeline architecture design. Do you have any other documents or context you'd like me to include?
|
||||||
|
|
||||||
|
[C] Continue to pipeline architecture decisions"
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ Existing workflow detected and continuation handled correctly
|
||||||
|
✅ Fresh workflow initialized with template and frontmatter
|
||||||
|
✅ Input documents discovered and loaded using sharded-first logic
|
||||||
|
✅ All discovered files tracked in frontmatter `inputDocuments`
|
||||||
|
✅ Architecture document requirement validated and communicated
|
||||||
|
✅ Existing CI/CD configuration scanned and reported
|
||||||
|
✅ Infrastructure context extracted (IaC tool, container strategy, env topology)
|
||||||
|
✅ User confirmed document setup and can proceed
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Proceeding with fresh initialization when existing workflow exists
|
||||||
|
❌ Not updating frontmatter with discovered input documents
|
||||||
|
❌ Creating document without proper template
|
||||||
|
❌ Not checking sharded folders first before whole files
|
||||||
|
❌ Not reporting what documents were found to user
|
||||||
|
❌ Proceeding without validating architecture document requirement
|
||||||
|
❌ Not scanning for existing CI/CD configuration
|
||||||
|
❌ Not extracting infrastructure context from architecture document
|
||||||
|
|
||||||
|
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||||
|
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||||
|
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||||
|
|
||||||
|
## NEXT STEP:
|
||||||
|
|
||||||
|
After user selects [C] to continue, only after ensuring all the template output has been created, then load `./step-02-pipeline-architecture.md` to begin pipeline architecture decisions.
|
||||||
|
|
||||||
|
Remember: Do NOT proceed to step-02 until user explicitly selects [C] from the menu and setup is confirmed!
|
||||||
|
|
@ -0,0 +1,293 @@
|
||||||
|
# Step 2: Pipeline Architecture Decisions
|
||||||
|
|
||||||
|
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||||
|
|
||||||
|
- 🛑 NEVER generate content without user input
|
||||||
|
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||||
|
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||||
|
- ✅ ALWAYS treat this as collaborative discovery between pipeline architecture peers
|
||||||
|
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||||
|
- 💬 FOCUS on making critical pipeline architecture decisions collaboratively
|
||||||
|
- 🌐 ALWAYS search the web to verify current technology versions
|
||||||
|
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||||
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||||
|
|
||||||
|
## EXECUTION PROTOCOLS:
|
||||||
|
|
||||||
|
- 🎯 Show your analysis before taking any action
|
||||||
|
- 🌐 Search the web to verify technology versions and options
|
||||||
|
- ⚠️ Present A/P/C menu after each major decision category
|
||||||
|
- 💾 ONLY save when user chooses C (Continue)
|
||||||
|
- 📖 Update frontmatter `stepsCompleted: [1, 2]` before loading next step
|
||||||
|
- 🚫 FORBIDDEN to load next step until C is selected
|
||||||
|
|
||||||
|
## COLLABORATION MENUS (A/P/C):
|
||||||
|
|
||||||
|
This step will generate content and present choices for each decision category:
|
||||||
|
|
||||||
|
- **A (Advanced Elicitation)**: Use discovery protocols to explore innovative approaches to specific decisions
|
||||||
|
- **P (Party Mode)**: Bring multiple perspectives to evaluate decision trade-offs
|
||||||
|
- **C (Continue)**: Save the current decisions and proceed to next decision category
|
||||||
|
|
||||||
|
## PROTOCOL INTEGRATION:
|
||||||
|
|
||||||
|
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||||
|
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||||
|
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||||
|
- User accepts/rejects protocol changes before proceeding
|
||||||
|
|
||||||
|
## CONTEXT BOUNDARIES:
|
||||||
|
|
||||||
|
- Infrastructure context from step 1 is available (IaC tool, container strategy, env topology)
|
||||||
|
- Architecture document decisions are available
|
||||||
|
- Existing CI/CD configuration scan results are available
|
||||||
|
- Focus on pipeline platform and branching strategy decisions
|
||||||
|
|
||||||
|
## YOUR TASK:
|
||||||
|
|
||||||
|
Facilitate collaborative pipeline architecture decision making, leveraging existing infrastructure context and architecture decisions, focusing on the foundational choices that shape all subsequent pipeline stages.
|
||||||
|
|
||||||
|
## DECISION MAKING SEQUENCE:
|
||||||
|
|
||||||
|
### 1. Load Context & Check Existing Preferences
|
||||||
|
|
||||||
|
**Review Infrastructure Context from Step 1:**
|
||||||
|
"Based on our initialization in step 1, let's build on these foundations:
|
||||||
|
|
||||||
|
**Infrastructure Context:**
|
||||||
|
- IaC Tool: {{iac_tool_from_step_1}}
|
||||||
|
- Container Strategy: {{container_strategy_from_step_1}}
|
||||||
|
- Environment Topology: {{env_topology_from_step_1}}
|
||||||
|
|
||||||
|
**Existing CI/CD Configuration:**
|
||||||
|
{{existing_cicd_config_from_step_1}}
|
||||||
|
|
||||||
|
**Architecture Decisions (relevant):**
|
||||||
|
{{relevant_architecture_decisions}}"
|
||||||
|
|
||||||
|
**Identify What's Already Decided:**
|
||||||
|
Based on infrastructure context, architecture document, and existing CI/CD config, identify what decisions are already made versus what needs collaborative decision making.
|
||||||
|
|
||||||
|
### 2. Decision Categories
|
||||||
|
|
||||||
|
#### Category 1: CI/CD Platform Selection
|
||||||
|
|
||||||
|
Options to present with trade-offs:
|
||||||
|
- **GitHub Actions** - Native GitHub integration, YAML-based, marketplace ecosystem
|
||||||
|
- **GitLab CI** - Built into GitLab, YAML-based, comprehensive DevSecOps
|
||||||
|
- **Jenkins** - Self-hosted, Groovy-based, maximum flexibility and plugin ecosystem
|
||||||
|
- **Azure DevOps** - Microsoft ecosystem, YAML pipelines, Azure-native
|
||||||
|
- **CircleCI** - Cloud-native, YAML-based, strong Docker support
|
||||||
|
- **Buildkite** - Hybrid model (cloud orchestration, self-hosted agents), scalable
|
||||||
|
|
||||||
|
**Present the Decision:**
|
||||||
|
Based on user skill level and project context:
|
||||||
|
|
||||||
|
**Expert Mode:**
|
||||||
|
"CI/CD Platform Selection:
|
||||||
|
|
||||||
|
Options: {{concise_option_list_with_tradeoffs}}
|
||||||
|
|
||||||
|
Given your {{existing_vcs_platform}} and {{infrastructure_choices}}, what's your preference?"
|
||||||
|
|
||||||
|
**Intermediate Mode:**
|
||||||
|
"Next decision: CI/CD Platform
|
||||||
|
|
||||||
|
We need to choose where your pipelines will run.
|
||||||
|
|
||||||
|
Common options:
|
||||||
|
{{option_list_with_brief_explanations}}
|
||||||
|
|
||||||
|
For your project, I'd lean toward {{recommendation}} because {{reason}}. What are your thoughts?"
|
||||||
|
|
||||||
|
**Beginner Mode:**
|
||||||
|
"Let's talk about where your pipelines will run.
|
||||||
|
|
||||||
|
{{Educational_Context_About_CI_CD_Platforms}}
|
||||||
|
|
||||||
|
Think of it like {{real_world_analogy}} - an automated assembly line for your code.
|
||||||
|
|
||||||
|
Your main options:
|
||||||
|
{{friendly_options_with_pros_cons}}
|
||||||
|
|
||||||
|
My suggestion: {{recommendation}}
|
||||||
|
This is good for you because {{beginner_friendly_reason}}.
|
||||||
|
|
||||||
|
What feels right to you?"
|
||||||
|
|
||||||
|
**Verify Technology Versions:**
|
||||||
|
```
|
||||||
|
Search the web: "{{platform}} latest version features"
|
||||||
|
Search the web: "{{platform}} pricing current"
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Category 2: Pipeline-as-Code Approach
|
||||||
|
|
||||||
|
- **YAML declarative** - Structured, readable, widely supported (GitHub Actions, GitLab CI, Azure DevOps)
|
||||||
|
- **Groovy scripted** - Programmable, flexible (Jenkins scripted pipeline)
|
||||||
|
- **Groovy declarative** - Structured Groovy (Jenkins declarative pipeline)
|
||||||
|
- **HCL** - Terraform-style (Waypoint)
|
||||||
|
- **Starlark** - Python-like (Buildkite, some tools)
|
||||||
|
|
||||||
|
Note: This decision may be determined by the CI/CD platform choice.
|
||||||
|
|
||||||
|
#### Category 3: Branch Strategy and Pipeline Implications
|
||||||
|
|
||||||
|
- **Trunk-Based Development** - Short-lived branches, continuous integration to main, feature flags for incomplete work. Pipeline: single main pipeline with feature-flag-gated deployments
|
||||||
|
- **GitHub Flow** - Feature branches off main, PR-based merging. Pipeline: PR validation pipeline + main deployment pipeline
|
||||||
|
- **GitFlow** - Feature/develop/release/hotfix branches. Pipeline: Multiple pipelines per branch type, release branch promotion
|
||||||
|
|
||||||
|
Present how each strategy impacts pipeline complexity and deployment frequency.
|
||||||
|
|
||||||
|
#### Category 4: Monorepo vs Polyrepo Pipeline Considerations
|
||||||
|
|
||||||
|
- **Monorepo** - Path-based triggers, selective builds, shared pipeline definitions, dependency-aware ordering
|
||||||
|
- **Polyrepo** - Independent pipelines per repo, cross-repo orchestration challenges, simpler per-repo config
|
||||||
|
- **Hybrid** - Core services in monorepo, peripheral services in separate repos
|
||||||
|
|
||||||
|
Note: This may already be determined by the project structure.
|
||||||
|
|
||||||
|
#### Category 5: Runner/Agent Infrastructure
|
||||||
|
|
||||||
|
- **Managed/Cloud runners** - Zero maintenance, pay-per-minute, limited customization
|
||||||
|
- **Self-hosted runners** - Full control, security isolation, cost optimization at scale
|
||||||
|
- **Hybrid** - Managed for standard builds, self-hosted for specialized/security-sensitive workloads
|
||||||
|
|
||||||
|
Security considerations:
|
||||||
|
- Network access to deployment targets
|
||||||
|
- Secrets management in runner environment
|
||||||
|
- Runner isolation between projects/environments
|
||||||
|
|
||||||
|
### 3. Facilitate Each Decision
|
||||||
|
|
||||||
|
For each category, follow the collaborative decision pattern:
|
||||||
|
|
||||||
|
**Get User Input:**
|
||||||
|
"What's your preference? (or 'explain more' for details)"
|
||||||
|
|
||||||
|
**Handle User Response:**
|
||||||
|
|
||||||
|
- If user wants more info: Provide deeper explanation
|
||||||
|
- If user has preference: Discuss implications and record decision
|
||||||
|
- If user wants alternatives: Explore other options
|
||||||
|
|
||||||
|
**Record the Decision:**
|
||||||
|
|
||||||
|
- Category: {{category}}
|
||||||
|
- Decision: {{user_choice}}
|
||||||
|
- Version: {{verified_version_if_applicable}}
|
||||||
|
- Rationale: {{user_reasoning_or_default}}
|
||||||
|
- Affects: {{downstream_pipeline_decisions}}
|
||||||
|
|
||||||
|
### 4. Generate Pipeline Architecture Content
|
||||||
|
|
||||||
|
After facilitating all decision categories, prepare the content to append:
|
||||||
|
|
||||||
|
#### Content Structure:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Pipeline Architecture
|
||||||
|
|
||||||
|
### CI/CD Platform
|
||||||
|
|
||||||
|
**Platform:** {{platform_choice}}
|
||||||
|
**Version:** {{verified_version}}
|
||||||
|
**Rationale:** {{rationale}}
|
||||||
|
|
||||||
|
### Pipeline-as-Code Approach
|
||||||
|
|
||||||
|
**Approach:** {{approach_choice}}
|
||||||
|
**Configuration Format:** {{format}}
|
||||||
|
**Rationale:** {{rationale}}
|
||||||
|
|
||||||
|
### Branch Strategy
|
||||||
|
|
||||||
|
**Strategy:** {{branch_strategy}}
|
||||||
|
**Pipeline Implications:**
|
||||||
|
{{how_strategy_maps_to_pipeline_triggers_and_flows}}
|
||||||
|
|
||||||
|
### Repository Strategy
|
||||||
|
|
||||||
|
**Approach:** {{monorepo_polyrepo_hybrid}}
|
||||||
|
**Pipeline Implications:**
|
||||||
|
{{trigger_strategy_selective_builds_etc}}
|
||||||
|
|
||||||
|
### Runner Infrastructure
|
||||||
|
|
||||||
|
**Runner Type:** {{managed_selfhosted_hybrid}}
|
||||||
|
**Security Model:** {{isolation_and_access_model}}
|
||||||
|
**Rationale:** {{rationale}}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 5. Present Content and Menu
|
||||||
|
|
||||||
|
Show the generated pipeline architecture content and present choices:
|
||||||
|
|
||||||
|
"I've documented our pipeline architecture decisions.
|
||||||
|
|
||||||
|
**Here's what I'll add to the document:**
|
||||||
|
|
||||||
|
[Show the complete markdown content from step 4]
|
||||||
|
|
||||||
|
**What would you like to do?**
|
||||||
|
[A] Advanced Elicitation - Explore innovative approaches to any specific decisions
|
||||||
|
[P] Party Mode - Review decisions from multiple perspectives
|
||||||
|
[C] Continue - Save these decisions and move to pipeline stage design"
|
||||||
|
|
||||||
|
### 6. Handle Menu Selection
|
||||||
|
|
||||||
|
#### If 'A' (Advanced Elicitation):
|
||||||
|
|
||||||
|
- Invoke the `bmad-advanced-elicitation` skill with specific decision categories
|
||||||
|
- Process enhanced insights about particular decisions
|
||||||
|
- Ask user: "Accept these enhancements to the pipeline architecture? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'P' (Party Mode):
|
||||||
|
|
||||||
|
- Invoke the `bmad-party-mode` skill with pipeline architecture context
|
||||||
|
- Process collaborative insights about decision trade-offs
|
||||||
|
- Ask user: "Accept these changes to the pipeline architecture? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'C' (Continue):
|
||||||
|
|
||||||
|
- Append the final content to `{planning_artifacts}/pipeline.md`
|
||||||
|
- Update frontmatter: `stepsCompleted: [1, 2]`
|
||||||
|
- Load `./step-03-pipeline-stages.md`
|
||||||
|
|
||||||
|
## APPEND TO DOCUMENT:
|
||||||
|
|
||||||
|
When user selects 'C', append the content directly to the document using the structure from step 4.
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ All pipeline architecture decisions made collaboratively
|
||||||
|
✅ Technology versions verified using web search
|
||||||
|
✅ Decision rationale clearly documented
|
||||||
|
✅ Infrastructure context leveraged for informed decisions
|
||||||
|
✅ Existing CI/CD configuration considered in recommendations
|
||||||
|
✅ User provided appropriate level of explanation for skill level
|
||||||
|
✅ A/P/C menu presented and handled correctly for each category
|
||||||
|
✅ Content properly appended to document when C selected
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Making recommendations instead of facilitating decisions
|
||||||
|
❌ Not verifying technology versions with web search
|
||||||
|
❌ Ignoring existing infrastructure context from step 1
|
||||||
|
❌ Not adapting explanations to user skill level
|
||||||
|
❌ Forgetting to consider existing CI/CD configuration
|
||||||
|
❌ Not presenting A/P/C menu after content generation
|
||||||
|
|
||||||
|
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||||
|
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||||
|
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||||
|
|
||||||
|
## NEXT STEP:
|
||||||
|
|
||||||
|
After user selects 'C' and content is saved to document, load `./step-03-pipeline-stages.md` to design the pipeline stages.
|
||||||
|
|
||||||
|
Remember: Do NOT proceed to step-03 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||||
|
|
@ -0,0 +1,308 @@
|
||||||
|
# Step 3: Pipeline Stage Design
|
||||||
|
|
||||||
|
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||||
|
|
||||||
|
- 🛑 NEVER generate content without user input
|
||||||
|
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||||
|
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||||
|
- ✅ ALWAYS treat this as collaborative discovery between pipeline architecture peers
|
||||||
|
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||||
|
- 💬 FOCUS on designing pipeline stages collaboratively - this is the core of the workflow
|
||||||
|
- 🌐 ALWAYS search the web to verify current technology versions
|
||||||
|
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||||
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||||
|
|
||||||
|
## EXECUTION PROTOCOLS:
|
||||||
|
|
||||||
|
- 🎯 Show your analysis before taking any action
|
||||||
|
- 🌐 Search the web to verify technology versions and options
|
||||||
|
- ⚠️ Present A/P/C menu after each major decision category
|
||||||
|
- 💾 ONLY save when user chooses C (Continue)
|
||||||
|
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3]` before loading next step
|
||||||
|
- 🚫 FORBIDDEN to load next step until C is selected
|
||||||
|
|
||||||
|
## COLLABORATION MENUS (A/P/C):
|
||||||
|
|
||||||
|
This step will generate content and present choices for each pipeline stage:
|
||||||
|
|
||||||
|
- **A (Advanced Elicitation)**: Use discovery protocols to explore innovative approaches to specific stages
|
||||||
|
- **P (Party Mode)**: Bring multiple perspectives to evaluate stage design trade-offs
|
||||||
|
- **C (Continue)**: Save the current stage decisions and proceed to next stage
|
||||||
|
|
||||||
|
## PROTOCOL INTEGRATION:
|
||||||
|
|
||||||
|
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||||
|
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||||
|
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||||
|
- User accepts/rejects protocol changes before proceeding
|
||||||
|
|
||||||
|
## CONTEXT BOUNDARIES:
|
||||||
|
|
||||||
|
- Pipeline architecture decisions from step 2 are available (platform, branch strategy, runner type)
|
||||||
|
- Infrastructure context from step 1 is available
|
||||||
|
- Architecture document decisions are available
|
||||||
|
- Focus on designing the actual pipeline stages end-to-end
|
||||||
|
|
||||||
|
## YOUR TASK:
|
||||||
|
|
||||||
|
Facilitate collaborative design of the pipeline stages from source to production. This is the core of the pipeline workflow - design each stage of the pipeline with the user, making decisions about tools, strategies, and configurations for each stage.
|
||||||
|
|
||||||
|
## STAGE DESIGN SEQUENCE:
|
||||||
|
|
||||||
|
Present stages as an ordered pipeline. For each stage, facilitate collaborative decision making using the appropriate skill level.
|
||||||
|
|
||||||
|
### Stage 1: Source Stage
|
||||||
|
|
||||||
|
**Trigger Strategy:**
|
||||||
|
- Push triggers (on push to specific branches)
|
||||||
|
- Pull request triggers (on PR open/update)
|
||||||
|
- Tag triggers (on version tags)
|
||||||
|
- Schedule triggers (cron-based nightly/weekly)
|
||||||
|
- Manual triggers (workflow dispatch)
|
||||||
|
|
||||||
|
**Branch Filters:**
|
||||||
|
- Which branches trigger which pipeline behaviors
|
||||||
|
- How the branch strategy from step 2 maps to triggers
|
||||||
|
|
||||||
|
**Present the Decision:**
|
||||||
|
Based on user skill level:
|
||||||
|
|
||||||
|
**Expert Mode:**
|
||||||
|
"Source Stage - Trigger Configuration:
|
||||||
|
Given your {{branch_strategy}} strategy, how do you want triggers mapped?
|
||||||
|
Options: {{trigger_options_with_branch_implications}}"
|
||||||
|
|
||||||
|
**Beginner Mode:**
|
||||||
|
"Let's decide what starts your pipeline running.
|
||||||
|
Think of triggers like alarm clocks for your code - they wake up the pipeline when something happens.
|
||||||
|
{{friendly_explanation_of_trigger_options}}"
|
||||||
|
|
||||||
|
### Stage 2: Build Stage
|
||||||
|
|
||||||
|
- **Build tool**: Language/framework-appropriate build tool
|
||||||
|
- **Artifact format**: What the build produces (container image, binary, package, bundle)
|
||||||
|
- **Caching strategy**: Dependency caching, layer caching, build caching
|
||||||
|
- **Build matrix**: Multi-platform, multi-version builds if needed
|
||||||
|
|
||||||
|
**Verify Technology Versions:**
|
||||||
|
```
|
||||||
|
Search the web: "{{build_tool}} latest stable version"
|
||||||
|
Search the web: "{{build_tool}} caching best practices"
|
||||||
|
```
|
||||||
|
|
||||||
|
### Stage 3: Test Stage
|
||||||
|
|
||||||
|
- **Unit tests**: Framework, coverage threshold, parallelization
|
||||||
|
- **Integration tests**: Scope, test environment, service dependencies
|
||||||
|
- **E2E tests**: Framework, browser/environment matrix, parallelization
|
||||||
|
- **Test splitting strategy**: How to split tests across stages for fast feedback
|
||||||
|
- **Test environment**: Ephemeral environments, shared environments, local services
|
||||||
|
|
||||||
|
### Stage 4: Security Stage
|
||||||
|
|
||||||
|
- **SAST tool**: Static Application Security Testing (Semgrep, SonarQube, CodeQL, Snyk Code)
|
||||||
|
- **SCA/Dependency scanning**: Software Composition Analysis (Snyk, Dependabot, Renovate, OWASP Dependency-Check)
|
||||||
|
- **Secrets scanning**: Detect leaked secrets (GitLeaks, TruffleHog, GitHub Secret Scanning)
|
||||||
|
- **Container image scanning** (if applicable): Vulnerability scanning (Trivy, Grype, Snyk Container)
|
||||||
|
- **IaC scanning** (if applicable): Infrastructure code security (Checkov, tfsec, KICS)
|
||||||
|
|
||||||
|
### Stage 5: Package Stage
|
||||||
|
|
||||||
|
- **Artifact packaging**: How the final artifact is packaged
|
||||||
|
- Container image (Docker/OCI)
|
||||||
|
- Binary artifact
|
||||||
|
- Language package (npm, PyPI, Maven, NuGet)
|
||||||
|
- Cloud-native package (Helm chart, Lambda zip)
|
||||||
|
- **Versioning strategy**:
|
||||||
|
- Semantic versioning (semver): MAJOR.MINOR.PATCH
|
||||||
|
- Calendar versioning (calver): YYYY.MM.DD
|
||||||
|
- Git SHA-based: Short commit hash
|
||||||
|
- Hybrid: semver + git SHA
|
||||||
|
- **Artifact signing and provenance**:
|
||||||
|
- Image signing (Cosign, Notation)
|
||||||
|
- SBOM generation (Syft, Trivy)
|
||||||
|
- Provenance attestation (SLSA)
|
||||||
|
|
||||||
|
### Stage 6: Deploy Stage
|
||||||
|
|
||||||
|
- **Deployment method**:
|
||||||
|
- Push-based: Pipeline pushes to target (traditional)
|
||||||
|
- Pull-based/GitOps: Target pulls desired state (ArgoCD, Flux)
|
||||||
|
- **Deployment tool**: ArgoCD, Flux, Helm, kubectl, Terraform, AWS CDK, Pulumi, Serverless Framework
|
||||||
|
- **Target environment sequence**: Which environments in what order (dev -> staging -> prod)
|
||||||
|
|
||||||
|
Note: Reference infrastructure context from step 1 for environment topology.
|
||||||
|
|
||||||
|
### Stage 7: Verify Stage
|
||||||
|
|
||||||
|
- **Smoke tests**: Quick health checks post-deployment
|
||||||
|
- **Health checks**: Application and dependency health verification
|
||||||
|
- **Synthetic monitoring**: Automated user journey testing in production
|
||||||
|
- **Rollback triggers**: What conditions automatically trigger rollback
|
||||||
|
|
||||||
|
### Stage 8: Promote Stage
|
||||||
|
|
||||||
|
- **Promotion gates**:
|
||||||
|
- Manual approval (who approves, what environments)
|
||||||
|
- Automated quality gates (test pass rate, coverage threshold, security scan clean)
|
||||||
|
- Soak time (minimum time in environment before promotion)
|
||||||
|
- **Environment progression**: dev -> staging -> prod (or custom sequence)
|
||||||
|
- **Promotion mechanism**: Automated after gates pass vs manual trigger
|
||||||
|
|
||||||
|
### For Each Stage:
|
||||||
|
|
||||||
|
**Get User Input:**
|
||||||
|
"What's your preference? (or 'explain more' for details)"
|
||||||
|
|
||||||
|
**Handle User Response:**
|
||||||
|
- If user wants more info: Provide deeper explanation with real-world context
|
||||||
|
- If user has preference: Discuss implications and record decision
|
||||||
|
- If user wants alternatives: Explore other options
|
||||||
|
- If stage is not applicable: Mark as "N/A" with rationale
|
||||||
|
|
||||||
|
**Record the Decision:**
|
||||||
|
- Stage: {{stage_name}}
|
||||||
|
- Tool/Approach: {{user_choice}}
|
||||||
|
- Version: {{verified_version_if_applicable}}
|
||||||
|
- Configuration: {{key_config_decisions}}
|
||||||
|
- Rationale: {{user_reasoning_or_default}}
|
||||||
|
|
||||||
|
### Generate Pipeline Stages Content
|
||||||
|
|
||||||
|
After facilitating all stage decisions, prepare the content to append:
|
||||||
|
|
||||||
|
#### Content Structure:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Pipeline Stages
|
||||||
|
|
||||||
|
### Pipeline Overview
|
||||||
|
|
||||||
|
{{visual_representation_of_pipeline_stages_as_ordered_flow}}
|
||||||
|
|
||||||
|
### Source Stage
|
||||||
|
|
||||||
|
**Triggers:** {{trigger_configuration}}
|
||||||
|
**Branch Filters:** {{branch_filter_rules}}
|
||||||
|
|
||||||
|
### Build Stage
|
||||||
|
|
||||||
|
**Build Tool:** {{tool}} ({{version}})
|
||||||
|
**Artifact Format:** {{format}}
|
||||||
|
**Caching Strategy:** {{caching_approach}}
|
||||||
|
**Build Matrix:** {{matrix_config_or_na}}
|
||||||
|
|
||||||
|
### Test Stage
|
||||||
|
|
||||||
|
**Unit Tests:** {{framework}} - Coverage threshold: {{threshold}}
|
||||||
|
**Integration Tests:** {{scope_and_approach}}
|
||||||
|
**E2E Tests:** {{framework_and_approach_or_na}}
|
||||||
|
**Parallelization:** {{parallel_strategy}}
|
||||||
|
|
||||||
|
### Security Stage
|
||||||
|
|
||||||
|
**SAST:** {{tool}} ({{version}})
|
||||||
|
**SCA/Dependency Scanning:** {{tool}} ({{version}})
|
||||||
|
**Secrets Scanning:** {{tool}} ({{version}})
|
||||||
|
**Container Scanning:** {{tool_or_na}}
|
||||||
|
**IaC Scanning:** {{tool_or_na}}
|
||||||
|
|
||||||
|
### Package Stage
|
||||||
|
|
||||||
|
**Artifact Type:** {{artifact_format}}
|
||||||
|
**Versioning Strategy:** {{versioning_approach}}
|
||||||
|
**Signing/Provenance:** {{signing_and_sbom_approach}}
|
||||||
|
|
||||||
|
### Deploy Stage
|
||||||
|
|
||||||
|
**Method:** {{push_or_gitops}}
|
||||||
|
**Tool:** {{deployment_tool}} ({{version}})
|
||||||
|
**Environment Sequence:** {{env_progression}}
|
||||||
|
|
||||||
|
### Verify Stage
|
||||||
|
|
||||||
|
**Smoke Tests:** {{approach}}
|
||||||
|
**Health Checks:** {{approach}}
|
||||||
|
**Synthetic Monitoring:** {{approach_or_na}}
|
||||||
|
**Rollback Triggers:** {{criteria}}
|
||||||
|
|
||||||
|
### Promote Stage
|
||||||
|
|
||||||
|
**Promotion Gates:** {{gate_configuration}}
|
||||||
|
**Environment Progression:** {{full_progression_with_gates}}
|
||||||
|
**Promotion Mechanism:** {{auto_or_manual}}
|
||||||
|
```
|
||||||
|
|
||||||
|
### Present Content and Menu
|
||||||
|
|
||||||
|
Show the generated pipeline stages content and present choices:
|
||||||
|
|
||||||
|
"I've documented all pipeline stages we designed together.
|
||||||
|
|
||||||
|
**Here's what I'll add to the document:**
|
||||||
|
|
||||||
|
[Show the complete markdown content]
|
||||||
|
|
||||||
|
**What would you like to do?**
|
||||||
|
[A] Advanced Elicitation - Explore innovative approaches to any specific stages
|
||||||
|
[P] Party Mode - Review stage design from multiple perspectives
|
||||||
|
[C] Continue - Save these stage decisions and move to deployment strategy"
|
||||||
|
|
||||||
|
### Handle Menu Selection
|
||||||
|
|
||||||
|
#### If 'A' (Advanced Elicitation):
|
||||||
|
|
||||||
|
- Invoke the `bmad-advanced-elicitation` skill with specific stage decisions
|
||||||
|
- Process enhanced insights about particular stages
|
||||||
|
- Ask user: "Accept these enhancements to the pipeline stages? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'P' (Party Mode):
|
||||||
|
|
||||||
|
- Invoke the `bmad-party-mode` skill with pipeline stages context
|
||||||
|
- Process collaborative insights about stage design trade-offs
|
||||||
|
- Ask user: "Accept these changes to the pipeline stages? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'C' (Continue):
|
||||||
|
|
||||||
|
- Append the final content to `{planning_artifacts}/pipeline.md`
|
||||||
|
- Update frontmatter: `stepsCompleted: [1, 2, 3]`
|
||||||
|
- Load `./step-04-deployment-strategy.md`
|
||||||
|
|
||||||
|
## APPEND TO DOCUMENT:
|
||||||
|
|
||||||
|
When user selects 'C', append the content directly to the document using the structure above.
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ All pipeline stages designed collaboratively
|
||||||
|
✅ Technology versions verified using web search for each tool
|
||||||
|
✅ Stage rationale clearly documented
|
||||||
|
✅ Pipeline architecture decisions from step 2 leveraged correctly
|
||||||
|
✅ Infrastructure context considered for deploy and verify stages
|
||||||
|
✅ User provided appropriate level of explanation for skill level
|
||||||
|
✅ A/P/C menu presented and handled correctly
|
||||||
|
✅ Content properly appended to document when C selected
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Making tool recommendations instead of facilitating decisions
|
||||||
|
❌ Not verifying technology versions with web search
|
||||||
|
❌ Skipping stages without confirming N/A with user
|
||||||
|
❌ Not adapting explanations to user skill level
|
||||||
|
❌ Ignoring pipeline architecture decisions from step 2
|
||||||
|
❌ Not presenting A/P/C menu after content generation
|
||||||
|
❌ Not considering infrastructure context for deployment-related stages
|
||||||
|
|
||||||
|
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||||
|
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||||
|
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||||
|
|
||||||
|
## NEXT STEP:
|
||||||
|
|
||||||
|
After user selects 'C' and content is saved to document, load `./step-04-deployment-strategy.md` to define deployment strategies.
|
||||||
|
|
||||||
|
Remember: Do NOT proceed to step-04 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||||
|
|
@ -0,0 +1,294 @@
|
||||||
|
# Step 4: Deployment Strategy
|
||||||
|
|
||||||
|
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||||
|
|
||||||
|
- 🛑 NEVER generate content without user input
|
||||||
|
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||||
|
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||||
|
- ✅ ALWAYS treat this as collaborative discovery between pipeline architecture peers
|
||||||
|
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||||
|
- 💬 FOCUS on deployment strategy decisions that directly impact DORA metrics
|
||||||
|
- 🌐 ALWAYS search the web to verify current technology versions
|
||||||
|
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||||
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||||
|
|
||||||
|
## EXECUTION PROTOCOLS:
|
||||||
|
|
||||||
|
- 🎯 Show your analysis before taking any action
|
||||||
|
- 🌐 Search the web to verify technology versions and options
|
||||||
|
- ⚠️ Present A/P/C menu after each major decision category
|
||||||
|
- 💾 ONLY save when user chooses C (Continue)
|
||||||
|
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4]` before loading next step
|
||||||
|
- 🚫 FORBIDDEN to load next step until C is selected
|
||||||
|
|
||||||
|
## COLLABORATION MENUS (A/P/C):
|
||||||
|
|
||||||
|
This step will generate content and present choices for each decision category:
|
||||||
|
|
||||||
|
- **A (Advanced Elicitation)**: Use discovery protocols to explore innovative approaches to deployment strategies
|
||||||
|
- **P (Party Mode)**: Bring multiple perspectives to evaluate deployment trade-offs
|
||||||
|
- **C (Continue)**: Save the current decisions and proceed to validation
|
||||||
|
|
||||||
|
## PROTOCOL INTEGRATION:
|
||||||
|
|
||||||
|
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||||
|
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||||
|
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||||
|
- User accepts/rejects protocol changes before proceeding
|
||||||
|
|
||||||
|
## CONTEXT BOUNDARIES:
|
||||||
|
|
||||||
|
- Pipeline architecture decisions from step 2 are available
|
||||||
|
- Pipeline stage decisions from step 3 are available (especially deploy and promote stages)
|
||||||
|
- Infrastructure context from step 1 is available
|
||||||
|
- Focus on advanced deployment patterns, rollback, and operational resilience
|
||||||
|
|
||||||
|
## DORA METRICS CONTEXT:
|
||||||
|
|
||||||
|
These decisions directly impact your deployment frequency and change failure rate. The four DORA metrics to keep in mind:
|
||||||
|
|
||||||
|
1. **Deployment Frequency** - How often you deploy to production
|
||||||
|
2. **Lead Time for Changes** - Time from commit to production
|
||||||
|
3. **Change Failure Rate** - Percentage of deployments causing failures
|
||||||
|
4. **Mean Time to Recovery (MTTR)** - How quickly you recover from failures
|
||||||
|
|
||||||
|
Reference these metrics when discussing trade-offs for each decision.
|
||||||
|
|
||||||
|
## YOUR TASK:
|
||||||
|
|
||||||
|
Facilitate collaborative deployment strategy decision making, focusing on patterns that ensure safe, fast, and reliable deployments with clear rollback and recovery mechanisms.
|
||||||
|
|
||||||
|
## DECISION MAKING SEQUENCE:
|
||||||
|
|
||||||
|
### 1. Load Context from Previous Steps
|
||||||
|
|
||||||
|
**Review Deploy and Promote Stage Decisions:**
|
||||||
|
"Based on our pipeline stage design in step 3, let's deepen the deployment strategy:
|
||||||
|
|
||||||
|
**Deploy Stage Decisions:**
|
||||||
|
- Method: {{push_or_gitops_from_step_3}}
|
||||||
|
- Tool: {{deployment_tool_from_step_3}}
|
||||||
|
- Environment Sequence: {{env_progression_from_step_3}}
|
||||||
|
|
||||||
|
**Promote Stage Decisions:**
|
||||||
|
- Gates: {{promotion_gates_from_step_3}}
|
||||||
|
- Mechanism: {{promotion_mechanism_from_step_3}}"
|
||||||
|
|
||||||
|
### 2. Decision Categories
|
||||||
|
|
||||||
|
#### Category 1: Deployment Pattern
|
||||||
|
|
||||||
|
Options to present with trade-offs:
|
||||||
|
|
||||||
|
- **Blue-Green Deployment** - Two identical environments, instant switchover. Pro: zero-downtime, instant rollback. Con: 2x infrastructure cost, database state complexity
|
||||||
|
- **Canary Deployment** - Gradual traffic shift to new version. Pro: risk mitigation, real-world validation. Con: complexity, observability requirements, longer rollout
|
||||||
|
- **Rolling Update** - Gradual replacement of instances. Pro: resource efficient, built into orchestrators. Con: mixed versions during rollout, slower rollback
|
||||||
|
- **Recreate** - Tear down old, deploy new. Pro: simple, clean state. Con: downtime window required
|
||||||
|
- **A/B Testing** - Route specific users to new version. Pro: feature validation, user-segment testing. Con: routing complexity, session management
|
||||||
|
|
||||||
|
**Verify Technology Versions:**
|
||||||
|
```
|
||||||
|
Search the web: "{{deployment_tool}} {{pattern}} implementation"
|
||||||
|
Search the web: "{{pattern}} best practices {{year}}"
|
||||||
|
```
|
||||||
|
|
||||||
|
#### Category 2: Feature Flag Strategy
|
||||||
|
|
||||||
|
- **LaunchDarkly** - Enterprise feature management platform, rich targeting, analytics
|
||||||
|
- **Unleash** - Open-source feature toggle system, self-hosted or managed
|
||||||
|
- **Flagsmith** - Open-source, remote config and feature flags
|
||||||
|
- **Custom implementation** - Application-level feature flags (config-driven or database-driven)
|
||||||
|
- **None** - No feature flags, rely on branch/deploy strategy alone
|
||||||
|
|
||||||
|
Discuss how feature flags interact with the deployment pattern and branch strategy.
|
||||||
|
|
||||||
|
#### Category 3: Database Migration Coordination
|
||||||
|
|
||||||
|
- **Pre-deploy migrations** - Run migrations before deploying new code. Requires backward-compatible migrations
|
||||||
|
- **In-deploy migrations** - Migrations run as part of deployment process. Simpler but riskier
|
||||||
|
- **Post-deploy migrations** - Deploy code first, then migrate. Requires code that handles both schemas
|
||||||
|
- **Expand-Contract pattern** - Multi-phase: expand schema (additive), deploy code, contract schema (remove old). Safest for zero-downtime
|
||||||
|
|
||||||
|
Present how each approach affects rollback capability and downtime.
|
||||||
|
|
||||||
|
#### Category 4: Rollback Strategy
|
||||||
|
|
||||||
|
- **Automated rollback** - Automatically revert on failure criteria (health check failures, error rate spike, latency threshold)
|
||||||
|
- **Manual rollback** - Human decision to revert, with automated execution
|
||||||
|
- **Hybrid** - Automated for critical failures, manual for degraded performance
|
||||||
|
|
||||||
|
Sub-decisions:
|
||||||
|
- Rollback criteria (what triggers it)
|
||||||
|
- Rollback mechanism (redeploy previous version, traffic shift, infrastructure swap)
|
||||||
|
- Data rollback considerations (can database changes be reverted?)
|
||||||
|
- Rollback testing (do you regularly test rollback procedures?)
|
||||||
|
|
||||||
|
#### Category 5: Zero-Downtime Requirements
|
||||||
|
|
||||||
|
- **Required** - Application must be available during all deployments
|
||||||
|
- **Maintenance window acceptable** - Scheduled downtime windows for deployments
|
||||||
|
- **Best effort** - Minimize downtime but brief interruptions acceptable
|
||||||
|
|
||||||
|
If zero-downtime is required:
|
||||||
|
- Graceful shutdown handling (drain connections, finish in-flight requests)
|
||||||
|
- Health check integration (readiness vs liveness probes)
|
||||||
|
- Connection draining configuration
|
||||||
|
- Load balancer integration
|
||||||
|
|
||||||
|
#### Category 6: Multi-Region Deployment (If Applicable)
|
||||||
|
|
||||||
|
- **Single region** - All deployments to one region
|
||||||
|
- **Active-passive** - Primary region with failover region
|
||||||
|
- **Active-active** - Multiple regions serving traffic simultaneously
|
||||||
|
|
||||||
|
If multi-region:
|
||||||
|
- Region deployment order (canary region first?)
|
||||||
|
- Cross-region data consistency
|
||||||
|
- Regional rollback independence
|
||||||
|
- Global traffic management (Route53, CloudFront, Global Accelerator)
|
||||||
|
|
||||||
|
### 3. Facilitate Each Decision
|
||||||
|
|
||||||
|
For each category, follow the collaborative decision pattern from previous steps.
|
||||||
|
|
||||||
|
**Record the Decision:**
|
||||||
|
|
||||||
|
- Category: {{category}}
|
||||||
|
- Decision: {{user_choice}}
|
||||||
|
- DORA Impact: {{how_this_affects_dora_metrics}}
|
||||||
|
- Rationale: {{user_reasoning_or_default}}
|
||||||
|
- Rollback Implication: {{how_this_affects_rollback_capability}}
|
||||||
|
|
||||||
|
### 4. Generate Deployment Strategy Content
|
||||||
|
|
||||||
|
After facilitating all decision categories, prepare the content to append:
|
||||||
|
|
||||||
|
#### Content Structure:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Deployment Strategy
|
||||||
|
|
||||||
|
### DORA Metrics Alignment
|
||||||
|
|
||||||
|
**Target Profile:**
|
||||||
|
- Deployment Frequency: {{target_frequency}}
|
||||||
|
- Lead Time for Changes: {{target_lead_time}}
|
||||||
|
- Change Failure Rate: {{target_failure_rate}}
|
||||||
|
- Mean Time to Recovery: {{target_mttr}}
|
||||||
|
|
||||||
|
### Deployment Pattern
|
||||||
|
|
||||||
|
**Pattern:** {{deployment_pattern}}
|
||||||
|
**Implementation:** {{how_pattern_is_implemented_with_chosen_tools}}
|
||||||
|
**Rationale:** {{rationale}}
|
||||||
|
|
||||||
|
### Feature Flag Strategy
|
||||||
|
|
||||||
|
**Approach:** {{feature_flag_approach}}
|
||||||
|
**Tool:** {{tool_or_na}} ({{version}})
|
||||||
|
**Integration:** {{how_flags_integrate_with_deployment_pattern}}
|
||||||
|
|
||||||
|
### Database Migration Strategy
|
||||||
|
|
||||||
|
**Approach:** {{migration_approach}}
|
||||||
|
**Coordination:** {{how_migrations_coordinate_with_deployments}}
|
||||||
|
**Rollback Impact:** {{how_this_affects_rollback}}
|
||||||
|
|
||||||
|
### Rollback Strategy
|
||||||
|
|
||||||
|
**Type:** {{automated_manual_hybrid}}
|
||||||
|
**Triggers:** {{rollback_criteria}}
|
||||||
|
**Mechanism:** {{rollback_mechanism}}
|
||||||
|
**Data Handling:** {{data_rollback_approach}}
|
||||||
|
**Testing:** {{rollback_testing_approach}}
|
||||||
|
|
||||||
|
### Zero-Downtime Approach
|
||||||
|
|
||||||
|
**Requirement Level:** {{required_maintenance_window_best_effort}}
|
||||||
|
**Implementation:**
|
||||||
|
{{graceful_shutdown_health_checks_connection_draining}}
|
||||||
|
|
||||||
|
### Multi-Region Strategy
|
||||||
|
|
||||||
|
**Approach:** {{single_active_passive_active_active}}
|
||||||
|
{{multi_region_details_if_applicable}}
|
||||||
|
|
||||||
|
### Deployment Strategy Summary
|
||||||
|
|
||||||
|
{{visual_summary_of_complete_deployment_flow_from_commit_to_production}}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 5. Present Content and Menu
|
||||||
|
|
||||||
|
Show the generated deployment strategy content and present choices:
|
||||||
|
|
||||||
|
"I've documented our deployment strategy decisions. These decisions directly impact your DORA metrics - particularly deployment frequency ({{assessment}}) and mean time to recovery ({{assessment}}).
|
||||||
|
|
||||||
|
**Here's what I'll add to the document:**
|
||||||
|
|
||||||
|
[Show the complete markdown content from step 4]
|
||||||
|
|
||||||
|
**What would you like to do?**
|
||||||
|
[A] Advanced Elicitation - Explore innovative approaches to deployment strategies
|
||||||
|
[P] Party Mode - Review deployment strategy from multiple perspectives
|
||||||
|
[C] Continue - Save these decisions and move to final validation"
|
||||||
|
|
||||||
|
### 6. Handle Menu Selection
|
||||||
|
|
||||||
|
#### If 'A' (Advanced Elicitation):
|
||||||
|
|
||||||
|
- Invoke the `bmad-advanced-elicitation` skill with deployment strategy context
|
||||||
|
- Process enhanced insights about deployment patterns
|
||||||
|
- Ask user: "Accept these enhancements to the deployment strategy? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'P' (Party Mode):
|
||||||
|
|
||||||
|
- Invoke the `bmad-party-mode` skill with deployment strategy context
|
||||||
|
- Process collaborative insights about deployment trade-offs
|
||||||
|
- Ask user: "Accept these changes to the deployment strategy? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'C' (Continue):
|
||||||
|
|
||||||
|
- Append the final content to `{planning_artifacts}/pipeline.md`
|
||||||
|
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4]`
|
||||||
|
- Load `./step-05-validation.md`
|
||||||
|
|
||||||
|
## APPEND TO DOCUMENT:
|
||||||
|
|
||||||
|
When user selects 'C', append the content directly to the document using the structure from step 4.
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ All deployment strategy decisions made collaboratively
|
||||||
|
✅ Technology versions verified using web search
|
||||||
|
✅ DORA metrics referenced for each decision trade-off
|
||||||
|
✅ Decision rationale clearly documented with DORA impact
|
||||||
|
✅ Rollback implications considered for every decision
|
||||||
|
✅ Pipeline stage decisions from step 3 leveraged correctly
|
||||||
|
✅ User provided appropriate level of explanation for skill level
|
||||||
|
✅ A/P/C menu presented and handled correctly
|
||||||
|
✅ Content properly appended to document when C selected
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Making recommendations instead of facilitating decisions
|
||||||
|
❌ Not verifying technology versions with web search
|
||||||
|
❌ Not referencing DORA metrics when discussing trade-offs
|
||||||
|
❌ Ignoring rollback implications of deployment decisions
|
||||||
|
❌ Not adapting explanations to user skill level
|
||||||
|
❌ Not considering pipeline stage decisions from step 3
|
||||||
|
❌ Not presenting A/P/C menu after content generation
|
||||||
|
|
||||||
|
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||||
|
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||||
|
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||||
|
|
||||||
|
## NEXT STEP:
|
||||||
|
|
||||||
|
After user selects 'C' and content is saved to document, load `./step-05-validation.md` to validate the complete pipeline architecture.
|
||||||
|
|
||||||
|
Remember: Do NOT proceed to step-05 until user explicitly selects 'C' from the A/P/C menu and content is saved!
|
||||||
|
|
@ -0,0 +1,300 @@
|
||||||
|
# Step 5: Pipeline Validation & Completion
|
||||||
|
|
||||||
|
## MANDATORY EXECUTION RULES (READ FIRST):
|
||||||
|
|
||||||
|
- 🛑 NEVER generate content without user input
|
||||||
|
- 📖 CRITICAL: ALWAYS read the complete step file before taking any action - partial understanding leads to incomplete decisions
|
||||||
|
- 🔄 CRITICAL: When loading next step with 'C', ensure the entire file is read and understood before proceeding
|
||||||
|
- ✅ ALWAYS treat this as collaborative discovery between pipeline architecture peers
|
||||||
|
- 📋 YOU ARE A FACILITATOR, not a content generator
|
||||||
|
- 💬 FOCUS on validating pipeline coherence, completeness, and alignment with architecture
|
||||||
|
- ✅ VALIDATE all pipeline stages have been decided and are consistent
|
||||||
|
- ⚠️ ABSOLUTELY NO TIME ESTIMATES - AI development speed has fundamentally changed
|
||||||
|
- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
|
||||||
|
|
||||||
|
## EXECUTION PROTOCOLS:
|
||||||
|
|
||||||
|
- 🎯 Show your analysis before taking any action
|
||||||
|
- ✅ Run comprehensive validation checks on the complete pipeline architecture
|
||||||
|
- ⚠️ Present A/P/C menu after generating validation results
|
||||||
|
- 💾 ONLY save when user chooses C (Continue)
|
||||||
|
- 📖 Update frontmatter `stepsCompleted: [1, 2, 3, 4, 5]` on completion
|
||||||
|
- 🚫 FORBIDDEN to complete workflow until C is selected
|
||||||
|
|
||||||
|
## COLLABORATION MENUS (A/P/C):
|
||||||
|
|
||||||
|
This step will generate content and present choices:
|
||||||
|
|
||||||
|
- **A (Advanced Elicitation)**: Use discovery protocols to address complex pipeline issues found during validation
|
||||||
|
- **P (Party Mode)**: Bring multiple perspectives to resolve validation concerns
|
||||||
|
- **C (Continue)**: Save the validation results and complete the pipeline architecture
|
||||||
|
|
||||||
|
## PROTOCOL INTEGRATION:
|
||||||
|
|
||||||
|
- When 'A' selected: Invoke the `bmad-advanced-elicitation` skill
|
||||||
|
- When 'P' selected: Invoke the `bmad-party-mode` skill
|
||||||
|
- PROTOCOLS always return to display this step's A/P/C menu after the A or P have completed
|
||||||
|
- User accepts/rejects protocol changes before proceeding
|
||||||
|
|
||||||
|
## CONTEXT BOUNDARIES:
|
||||||
|
|
||||||
|
- Complete pipeline document with all sections is available
|
||||||
|
- All pipeline architecture, stage, and deployment strategy decisions are defined
|
||||||
|
- Architecture document and infrastructure document (if exists) are available for cross-reference
|
||||||
|
- Focus on validation, gap analysis, and coherence checking
|
||||||
|
|
||||||
|
## YOUR TASK:
|
||||||
|
|
||||||
|
Validate the complete pipeline architecture for coherence, completeness, alignment with architecture and infrastructure decisions, and DORA metric readiness.
|
||||||
|
|
||||||
|
## VALIDATION SEQUENCE:
|
||||||
|
|
||||||
|
### 1. Present Complete Pipeline Decision Document Summary
|
||||||
|
|
||||||
|
Present a concise summary of all decisions made across steps 2-4:
|
||||||
|
|
||||||
|
"Here's a complete summary of your CI/CD pipeline architecture:
|
||||||
|
|
||||||
|
**Pipeline Architecture (Step 2):**
|
||||||
|
- Platform: {{platform}}
|
||||||
|
- Branch Strategy: {{branch_strategy}}
|
||||||
|
- Runner Infrastructure: {{runner_type}}
|
||||||
|
|
||||||
|
**Pipeline Stages (Step 3):**
|
||||||
|
- Source: {{trigger_summary}}
|
||||||
|
- Build: {{build_summary}}
|
||||||
|
- Test: {{test_summary}}
|
||||||
|
- Security: {{security_summary}}
|
||||||
|
- Package: {{package_summary}}
|
||||||
|
- Deploy: {{deploy_summary}}
|
||||||
|
- Verify: {{verify_summary}}
|
||||||
|
- Promote: {{promote_summary}}
|
||||||
|
|
||||||
|
**Deployment Strategy (Step 4):**
|
||||||
|
- Pattern: {{deployment_pattern}}
|
||||||
|
- Feature Flags: {{feature_flag_approach}}
|
||||||
|
- Database Migrations: {{migration_approach}}
|
||||||
|
- Rollback: {{rollback_strategy}}
|
||||||
|
- Zero-Downtime: {{zero_downtime_approach}}"
|
||||||
|
|
||||||
|
### 2. Cross-Reference with Architecture and Infrastructure
|
||||||
|
|
||||||
|
Validate alignment with architecture.md:
|
||||||
|
|
||||||
|
**Architecture Alignment:**
|
||||||
|
- Do pipeline technology choices align with architecture stack decisions?
|
||||||
|
- Does the deployment strategy support the architecture's scalability requirements?
|
||||||
|
- Are security scanning tools aligned with architecture security decisions?
|
||||||
|
- Does the environment progression match architecture's environment strategy?
|
||||||
|
|
||||||
|
**Infrastructure Alignment (if infrastructure.md exists):**
|
||||||
|
- Does the pipeline deploy to the infrastructure defined?
|
||||||
|
- Are IaC tools integrated into the pipeline appropriately?
|
||||||
|
- Does the container strategy align between pipeline and infrastructure?
|
||||||
|
- Are environment configurations consistent?
|
||||||
|
|
||||||
|
Report any misalignments found:
|
||||||
|
"I found the following alignment considerations:
|
||||||
|
{{alignment_findings}}"
|
||||||
|
|
||||||
|
### 3. DORA Metric Readiness Validation
|
||||||
|
|
||||||
|
Assess the pipeline against DORA metrics:
|
||||||
|
|
||||||
|
**Deployment Frequency:**
|
||||||
|
"Can you deploy on-demand? Based on your pipeline design:
|
||||||
|
- {{assessment_of_deployment_frequency_capability}}
|
||||||
|
- Bottlenecks: {{any_bottlenecks_limiting_frequency}}"
|
||||||
|
|
||||||
|
**Lead Time for Changes:**
|
||||||
|
"How quickly can a commit reach production?
|
||||||
|
- Pipeline stages: {{estimated_stage_count}}
|
||||||
|
- Promotion gates: {{gate_count_and_types}}
|
||||||
|
- Potential delays: {{identified_delays}}"
|
||||||
|
|
||||||
|
**Change Failure Rate:**
|
||||||
|
"How well does your pipeline catch issues before production?
|
||||||
|
- Security scanning: {{security_stage_coverage}}
|
||||||
|
- Test coverage: {{test_stage_coverage}}
|
||||||
|
- Verification: {{verify_stage_coverage}}"
|
||||||
|
|
||||||
|
**Mean Time to Recovery:**
|
||||||
|
"Can you recover in under an hour?
|
||||||
|
- Rollback strategy: {{rollback_readiness}}
|
||||||
|
- Monitoring: {{verify_stage_monitoring}}
|
||||||
|
- Automation level: {{recovery_automation_level}}"
|
||||||
|
|
||||||
|
### 4. Pipeline Completeness Check
|
||||||
|
|
||||||
|
Verify all critical pipeline stages have been decided:
|
||||||
|
|
||||||
|
**Critical Stage Checklist:**
|
||||||
|
- [ ] Source triggers defined
|
||||||
|
- [ ] Build process configured
|
||||||
|
- [ ] Test strategy established
|
||||||
|
- [ ] Security scanning integrated
|
||||||
|
- [ ] Artifact packaging defined
|
||||||
|
- [ ] Deployment method chosen
|
||||||
|
- [ ] Verification approach set
|
||||||
|
- [ ] Promotion gates configured
|
||||||
|
- [ ] Rollback strategy defined
|
||||||
|
|
||||||
|
Report any gaps:
|
||||||
|
"The following areas need attention:
|
||||||
|
{{gaps_found_or_all_clear}}"
|
||||||
|
|
||||||
|
### 5. Generate Validation Content
|
||||||
|
|
||||||
|
Prepare the content to append to the document:
|
||||||
|
|
||||||
|
#### Content Structure:
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
## Pipeline Validation Results
|
||||||
|
|
||||||
|
### Architecture Alignment ✅
|
||||||
|
|
||||||
|
**Stack Compatibility:**
|
||||||
|
{{assessment_of_pipeline_tools_vs_architecture_stack}}
|
||||||
|
|
||||||
|
**Security Alignment:**
|
||||||
|
{{assessment_of_security_scanning_vs_architecture_security}}
|
||||||
|
|
||||||
|
**Environment Consistency:**
|
||||||
|
{{assessment_of_env_progression_vs_architecture_environments}}
|
||||||
|
|
||||||
|
### Infrastructure Alignment ✅
|
||||||
|
|
||||||
|
{{assessment_of_pipeline_vs_infrastructure_decisions_or_na}}
|
||||||
|
|
||||||
|
### DORA Metric Readiness
|
||||||
|
|
||||||
|
**Deployment Frequency:** {{ready_or_concern}}
|
||||||
|
{{assessment}}
|
||||||
|
|
||||||
|
**Lead Time for Changes:** {{ready_or_concern}}
|
||||||
|
{{assessment}}
|
||||||
|
|
||||||
|
**Change Failure Rate:** {{ready_or_concern}}
|
||||||
|
{{assessment}}
|
||||||
|
|
||||||
|
**Mean Time to Recovery:** {{ready_or_concern}}
|
||||||
|
{{assessment}}
|
||||||
|
|
||||||
|
### Pipeline Completeness Checklist
|
||||||
|
|
||||||
|
- [x] Source triggers defined
|
||||||
|
- [x] Build process configured
|
||||||
|
- [x] Test strategy established
|
||||||
|
- [x] Security scanning integrated
|
||||||
|
- [x] Artifact packaging defined
|
||||||
|
- [x] Deployment method chosen
|
||||||
|
- [x] Verification approach set
|
||||||
|
- [x] Promotion gates configured
|
||||||
|
- [x] Rollback strategy defined
|
||||||
|
|
||||||
|
### Alignment Issues Addressed
|
||||||
|
|
||||||
|
{{description_of_any_issues_found_and_resolutions}}
|
||||||
|
|
||||||
|
### Pipeline Readiness Assessment
|
||||||
|
|
||||||
|
**Overall Status:** READY FOR IMPLEMENTATION
|
||||||
|
|
||||||
|
**Confidence Level:** {{high/medium/low}} based on validation results
|
||||||
|
|
||||||
|
**Key Strengths:**
|
||||||
|
{{list_of_pipeline_strengths}}
|
||||||
|
|
||||||
|
**Areas for Future Enhancement:**
|
||||||
|
{{areas_that_could_be_improved_later}}
|
||||||
|
```
|
||||||
|
|
||||||
|
### 6. Present Content and Menu
|
||||||
|
|
||||||
|
Show the validation results and present choices:
|
||||||
|
|
||||||
|
"I've completed a comprehensive validation of your pipeline architecture.
|
||||||
|
|
||||||
|
**Validation Summary:**
|
||||||
|
|
||||||
|
- ✅ Architecture Alignment: {{status}}
|
||||||
|
- ✅ Infrastructure Alignment: {{status}}
|
||||||
|
- ✅ DORA Readiness: {{status}}
|
||||||
|
- ✅ Completeness: {{status}}
|
||||||
|
|
||||||
|
**Here's what I'll add to complete the pipeline document:**
|
||||||
|
|
||||||
|
[Show the complete markdown content from step 5]
|
||||||
|
|
||||||
|
**What would you like to do?**
|
||||||
|
[A] Advanced Elicitation - Address any complex pipeline concerns
|
||||||
|
[P] Party Mode - Review validation from different operational perspectives
|
||||||
|
[C] Continue - Complete the pipeline architecture and finish workflow"
|
||||||
|
|
||||||
|
### 7. Handle Menu Selection
|
||||||
|
|
||||||
|
#### If 'A' (Advanced Elicitation):
|
||||||
|
|
||||||
|
- Invoke the `bmad-advanced-elicitation` skill with validation issues
|
||||||
|
- Process enhanced solutions for complex concerns
|
||||||
|
- Ask user: "Accept these pipeline improvements? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'P' (Party Mode):
|
||||||
|
|
||||||
|
- Invoke the `bmad-party-mode` skill with validation context
|
||||||
|
- Process collaborative insights on pipeline readiness
|
||||||
|
- Ask user: "Accept these changes to the validation results? (y/n)"
|
||||||
|
- If yes: Update content, then return to A/P/C menu
|
||||||
|
- If no: Keep original content, then return to A/P/C menu
|
||||||
|
|
||||||
|
#### If 'C' (Continue):
|
||||||
|
|
||||||
|
- Append the final content to `{planning_artifacts}/pipeline.md`
|
||||||
|
- Update frontmatter: `stepsCompleted: [1, 2, 3, 4, 5]`
|
||||||
|
- Report completion message
|
||||||
|
|
||||||
|
### 8. Completion Report
|
||||||
|
|
||||||
|
On final 'C', save to `{planning_artifacts}/pipeline.md` and report:
|
||||||
|
|
||||||
|
"Pipeline architecture documented. Your pipeline covers {{stage_count}} stages with {{deployment_strategy}} deployment. {{total_decisions}} decisions recorded across pipeline architecture, stage design, and deployment strategy.
|
||||||
|
|
||||||
|
**DORA Readiness:** {{dora_summary}}
|
||||||
|
|
||||||
|
**Recommended Next Steps:**
|
||||||
|
- Consider running the infrastructure workflow (`bmad-create-infrastructure`) if not already done
|
||||||
|
- Proceed to Create Epics and Stories (`bmad-create-epics-and-stories`) to break down implementation
|
||||||
|
- Review the architecture document to ensure pipeline decisions are reflected in the infrastructure section"
|
||||||
|
|
||||||
|
## APPEND TO DOCUMENT:
|
||||||
|
|
||||||
|
When user selects 'C', append the content directly to the document using the structure from step 5.
|
||||||
|
|
||||||
|
## SUCCESS METRICS:
|
||||||
|
|
||||||
|
✅ Complete pipeline decision document presented as summary
|
||||||
|
✅ Cross-reference with architecture.md validated
|
||||||
|
✅ Cross-reference with infrastructure.md validated (if exists)
|
||||||
|
✅ DORA metric readiness assessed with specific findings
|
||||||
|
✅ All critical pipeline stages confirmed as decided
|
||||||
|
✅ Alignment issues identified and addressed
|
||||||
|
✅ A/P/C menu presented and handled correctly
|
||||||
|
✅ Content properly appended to document when C selected
|
||||||
|
✅ Completion report delivered with next step recommendations
|
||||||
|
|
||||||
|
## FAILURE MODES:
|
||||||
|
|
||||||
|
❌ Not presenting complete summary before validation
|
||||||
|
❌ Skipping cross-reference with architecture document
|
||||||
|
❌ Not assessing DORA metric readiness
|
||||||
|
❌ Missing completeness check for critical stages
|
||||||
|
❌ Not addressing alignment issues found
|
||||||
|
❌ Not presenting A/P/C menu after content generation
|
||||||
|
❌ Not providing clear next step recommendations on completion
|
||||||
|
|
||||||
|
❌ **CRITICAL**: Reading only partial step file - leads to incomplete understanding and poor decisions
|
||||||
|
❌ **CRITICAL**: Proceeding with 'C' without fully reading and understanding the next step file
|
||||||
|
❌ **CRITICAL**: Making decisions without complete understanding of step requirements and protocols
|
||||||
|
|
@ -0,0 +1,32 @@
|
||||||
|
# Pipeline Workflow
|
||||||
|
|
||||||
|
**Goal:** Design CI/CD pipeline architecture and deployment strategies through collaborative step-by-step discovery that ensures reliable, repeatable, and secure software delivery.
|
||||||
|
|
||||||
|
**Your Role:** You are a pipeline architecture facilitator collaborating with a peer. This is a partnership, not a client-vendor relationship. You bring CI/CD engineering knowledge and deployment operations experience, while the user brings project requirements and team workflow preferences. Work together as equals to design pipelines that ship reliably.
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## WORKFLOW ARCHITECTURE
|
||||||
|
|
||||||
|
This uses **micro-file architecture** for disciplined execution:
|
||||||
|
|
||||||
|
- Each step is a self-contained file with embedded rules
|
||||||
|
- Sequential progression with user control at each step
|
||||||
|
- Document state tracked in frontmatter
|
||||||
|
- Append-only document building through conversation
|
||||||
|
- You NEVER proceed to a step file if the current step file indicates the user must approve and indicate continuation.
|
||||||
|
|
||||||
|
## Activation
|
||||||
|
|
||||||
|
1. Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve::
|
||||||
|
- Use `{user_name}` for greeting
|
||||||
|
- Use `{communication_language}` for all communications
|
||||||
|
- Use `{document_output_language}` for output documents
|
||||||
|
- Use `{planning_artifacts}` for output location and artifact scanning
|
||||||
|
- Use `{project_knowledge}` for additional context scanning
|
||||||
|
|
||||||
|
2. EXECUTION
|
||||||
|
|
||||||
|
Read fully and follow: `./steps/step-01-init.md` to begin the workflow.
|
||||||
|
|
||||||
|
**Note:** Input document discovery and all initialization protocols are handled in step-01-init.md.
|
||||||
|
|
@ -18,6 +18,9 @@ BMad Method,bmad-create-prd,Create PRD,CP,Expert led facilitation to produce you
|
||||||
BMad Method,bmad-validate-prd,Validate PRD,VP,,,[path],2-planning,bmad-create-prd,,false,planning_artifacts,prd validation report
|
BMad Method,bmad-validate-prd,Validate PRD,VP,,,[path],2-planning,bmad-create-prd,,false,planning_artifacts,prd validation report
|
||||||
BMad Method,bmad-edit-prd,Edit PRD,EP,,,[path],2-planning,bmad-validate-prd,,false,planning_artifacts,updated prd
|
BMad Method,bmad-edit-prd,Edit PRD,EP,,,[path],2-planning,bmad-validate-prd,,false,planning_artifacts,updated prd
|
||||||
BMad Method,bmad-create-ux-design,Create UX,CU,"Guidance through realizing the plan for your UX, strongly recommended if a UI is a primary piece of the proposed project.",,2-planning,bmad-create-prd,,false,planning_artifacts,ux design
|
BMad Method,bmad-create-ux-design,Create UX,CU,"Guidance through realizing the plan for your UX, strongly recommended if a UI is a primary piece of the proposed project.",,2-planning,bmad-create-prd,,false,planning_artifacts,ux design
|
||||||
|
BMad Method,bmad-agent-devops,DevOps Lead,DL,Infrastructure-as-code CI/CD pipelines deployment strategies and environment management.,,3-solutioning,,,false,,
|
||||||
|
BMad Method,bmad-create-infrastructure,Create Infrastructure,II,Define infrastructure-as-code strategy environment topology and deployment foundations.,,3-solutioning,,,false,planning_artifacts,infrastructure
|
||||||
|
BMad Method,bmad-create-pipeline,Create Pipeline,IP,Design CI/CD pipeline architecture deployment strategies and promotion gates.,,3-solutioning,,,false,planning_artifacts,pipeline
|
||||||
BMad Method,bmad-create-architecture,Create Architecture,CA,Guided workflow to document technical decisions.,,3-solutioning,,,true,planning_artifacts,architecture
|
BMad Method,bmad-create-architecture,Create Architecture,CA,Guided workflow to document technical decisions.,,3-solutioning,,,true,planning_artifacts,architecture
|
||||||
BMad Method,bmad-create-epics-and-stories,Create Epics and Stories,CE,,,3-solutioning,bmad-create-architecture,,true,planning_artifacts,epics and stories
|
BMad Method,bmad-create-epics-and-stories,Create Epics and Stories,CE,,,3-solutioning,bmad-create-architecture,,true,planning_artifacts,epics and stories
|
||||||
BMad Method,bmad-check-implementation-readiness,Check Implementation Readiness,IR,Ensure PRD UX Architecture and Epics Stories are aligned.,,3-solutioning,bmad-create-epics-and-stories,,true,planning_artifacts,readiness report
|
BMad Method,bmad-check-implementation-readiness,Check Implementation Readiness,IR,Ensure PRD UX Architecture and Epics Stories are aligned.,,3-solutioning,bmad-create-epics-and-stories,,true,planning_artifacts,readiness report
|
||||||
|
|
|
||||||
|
Can't render this file because it has a wrong number of fields in line 2.
|
Loading…
Reference in New Issue