diff --git a/src/bmm-skills/3-solutioning/bmad-create-pipeline/SKILL.md b/src/bmm-skills/3-solutioning/bmad-create-pipeline/SKILL.md
new file mode 100644
index 000000000..fb19a6296
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-create-pipeline/SKILL.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.
diff --git a/src/bmm-skills/3-solutioning/bmad-create-pipeline/pipeline-template.md b/src/bmm-skills/3-solutioning/bmad-create-pipeline/pipeline-template.md
new file mode 100644
index 000000000..50f4e8f37
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-create-pipeline/pipeline-template.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._
diff --git a/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-01-init.md b/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-01-init.md
new file mode 100644
index 000000000..34b327f61
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-01-init.md
@@ -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!
diff --git a/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-02-pipeline-architecture.md b/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-02-pipeline-architecture.md
new file mode 100644
index 000000000..412462a7c
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-02-pipeline-architecture.md
@@ -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!
diff --git a/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-03-pipeline-stages.md b/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-03-pipeline-stages.md
new file mode 100644
index 000000000..472d40cb8
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-03-pipeline-stages.md
@@ -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!
diff --git a/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-04-deployment-strategy.md b/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-04-deployment-strategy.md
new file mode 100644
index 000000000..12e203763
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-04-deployment-strategy.md
@@ -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!
diff --git a/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-05-validation.md b/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-05-validation.md
new file mode 100644
index 000000000..d8be09254
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-create-pipeline/steps/step-05-validation.md
@@ -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
diff --git a/src/bmm-skills/3-solutioning/bmad-create-pipeline/workflow.md b/src/bmm-skills/3-solutioning/bmad-create-pipeline/workflow.md
new file mode 100644
index 000000000..877e764fc
--- /dev/null
+++ b/src/bmm-skills/3-solutioning/bmad-create-pipeline/workflow.md
@@ -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.
diff --git a/src/bmm-skills/module-help.csv b/src/bmm-skills/module-help.csv
index a5db5418a..cfda8801b 100644
--- a/src/bmm-skills/module-help.csv
+++ b/src/bmm-skills/module-help.csv
@@ -20,6 +20,7 @@ BMad Method,bmad-edit-prd,Edit PRD,EP,,,[path],2-planning,bmad-validate-prd,,fal
 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-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