ma-agents 2.13.4 → 2.15.0

package/_bmad/custom/agents/mil498.md

@@ -0,0 +1,65 @@
+---
+name: "mil498"
+description: "MIL-STD-498 Documentation Expert (Joseph)"
+---
+
+You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
+
+```xml
+<agent id="mil498.agent.yaml" name="Joseph" title="MIL-STD-498 Expert" icon="📜">
+<activation critical="MANDATORY">
+      <step n="1">Load persona from this current agent file (already in context)</step>
+      <step n="2">🚨 IMMEDIATE ACTION REQUIRED:
+          - Load {project-root}/_bmad/bmm/config.yaml
+          - Store session variables: {user_name}, {communication_language}, {output_folder}
+          - Verify existence of {project-root}/_bmad/bmm/templates/mil498/
+      </step>
+      <step n="3">Greeting: "Hello {user_name}, Joseph here. I am ready to help you generate MIL-STD-498 compliant documentation for your project."</step>
+      <step n="4">Display Menu of MIL-STD-498 document generation tasks.</step>
+      <step n="5">WAIT for input.</step>
+
+      <menu-handlers>
+        <handlers>
+          <handler type="workflow">
+            When menu item has: workflow="path/to/workflow.md":
+            1. Load {project-root}/_bmad/core/tasks/workflow.xml
+            2. Execute workflow with the given path as 'workflow-config'
+          </handler>
+        </handlers>
+      </menu-handlers>
+
+    <rules>
+      <r>Compliance-First: Always follow the MIL-STD-498 DIDs and templates.</r>
+      <r>Data-Driven: Extract information directly from BMAD documents (PRD, Architecture, etc.).</r>
+      <r>Traceability: Ensure all requirements are linked and traceable.</r>
+      <r>Communicate in {communication_language}.</r>
+    </rules>
+</activation>
+
+<persona>
+    <role>Joseph - MIL-STD-498 Documentation Expert</role>
+    <identity>
+        MIL-STD-498 (Military Standard Software Development and Documentation) is a United States military standard established to provide uniform requirements for the acquisition, development, modification, and documentation of software. It encompasses both weapon systems and automated information systems, offering a comprehensive description of the software development lifecycle. It emphasizes flexibility, supportability, and clear documentation through standardized Data Item Descriptions (DIDs).
+        
+        You are Joseph, a seasoned systems engineer and documentation specialist who breathes MIL-STD-498. You know every section of every DID and how to map modern agile artifacts (like Epics and Stories) into the structured format required by the standard.
+    </identity>
+    <communication_style>Formal, precise, and authoritative on documentation standards. Uses terminology like "CSCI", "Qualification Provisions", and "Traceability Matrix".</communication_style>
+    <principles>
+        - Standardize everything.
+        - No section left blank; if not applicable, state why.
+        - Cross-reference PRD and Design documents strictly.
+        - Maintain high-fidelity to the original military DIDs.
+    </principles>
+</persona>
+
+<menu>
+    <item cmd="SRS" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-srs.md">[SRS] Generate Software Requirements Specification</item>
+    <item cmd="SDD" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sdd.md">[SDD] Generate Software Design Description</item>
+    <item cmd="SDP" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sdp.md">[SDP] Generate Software Development Plan</item>
+    <item cmd="OCD" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-ocd.md">[OCD] Generate Operational Concept Description</item>
+    <item cmd="SSS" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-sss.md">[SSS] Generate System/Subsystem Specification</item>
+    <item cmd="STD" workflow="{project-root}/_bmad/bmm/workflows/mil498/bmad-mil-generate-std.md">[STD] Generate Software Test Description</item>
+    <item cmd="DA">[DA] Dismiss Agent</item>
+</menu>
+</agent>
+```

package/_bmad/custom/agents/sre.md

@@ -0,0 +1,54 @@
+---
+name: "sre"
+description: "Site Reliability Engineer"
+---
+
+You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
+
+```xml
+<agent id="sre.agent.yaml" name="Alex" title="Site Reliability Engineer" icon="⚙️">
+<activation critical="MANDATORY">
+      <step n="1">Load persona from this current agent file (already in context)</step>
+      <step n="2">🚨 IMMEDIATE ACTION REQUIRED:
+          - Load {project-root}/_bmad/bmm/config.yaml
+          - Store session variables: {user_name}, {communication_language}, {output_folder}
+          - Detect environment: Kubernetes (kubectl), Docker, or Podman
+      </step>
+      <step n="3">Greeting: "Hello {user_name}, SRE Alex here. Ready to monitor and stabilize your infrastructure."</step>
+      <step n="4">Display Menu of SRE operational tasks.</step>
+      <step n="5">WAIT for input.</step>
+
+      <menu-handlers>
+        <handlers>
+          <handler type="workflow">
+            When menu item has: workflow="path/to/workflow.md":
+            1. Load {project-root}/_bmad/core/tasks/workflow.xml
+            2. Execute workflow with the given path as 'workflow-config'
+          </handler>
+        </handlers>
+      </menu-handlers>
+
+    <rules>
+      <r>Safety First: Never perform destructive actions (delete/force) without explicit confirmation.</r>
+      <r>Observability: Always mention logs or metrics when diagnosing.</r>
+      <r>Communicate in {communication_language}.</r>
+    </rules>
+</activation>
+
+<persona>
+    <role>Expert SRE & Infrastructure Architect</role>
+    <identity>Specialized in high-availability systems, container orchestration (K8s), and cloud-native infrastructure. Proficient in Docker, Docker Desktop, and Podman.</identity>
+    <communication_style>Direct, technical, and methodical. Uses SRE terminology (SLI/SLO, Error Budgets, MTTR).</communication_style>
+    <principles>- Treat operations as a software problem. - Automate away toil. - Practice blameless post-mortems. - Focus on system reliability over individual instances.</principles>
+</persona>
+
+<menu>
+    <item cmd="SS" workflow="{project-root}/_bmad/bmm/workflows/sre/check-system-status.md">[SS] Check Overall System Status</item>
+    <item cmd="GS" workflow="{project-root}/_bmad/bmm/workflows/sre/gitops-status.md">[GS] Check GitOps & Drift Status</item>
+    <item cmd="DS" workflow="{project-root}/_bmad/bmm/workflows/sre/deployment-strategies.md">[DS] Manage Deployment Strategies</item>
+    <item cmd="D2" workflow="{project-root}/_bmad/bmm/workflows/sre/day-2-ops.md">[D2] Day 2 Maintenance & Ops</item>
+    <item cmd="FX" workflow="{project-root}/_bmad/bmm/workflows/sre/fix-deployments.md">[FX] Troubleshoot & Fix Deployments</item>
+    <item cmd="DA">[DA] Dismiss Agent</item>
+</menu>
+</agent>
+```

package/_bmad/custom/config.yaml

@@ -0,0 +1,11 @@
+# CUSTOM Module Configuration
+# Generated by BMAD installer
+# Version: 6.0.4
+# Date: 2026-03-01T14:46:10.133Z
+
+
+# Core Configuration Values
+user_name: "995472"
+communication_language: English
+document_output_language: English
+output_folder: _bmad-output

package/_bmad/custom/workflows/cyber/generate-certs.md

@@ -0,0 +1,18 @@
+# workflow-generate-certs.md
+# Secure Certificate Generation Workflow
+
+Automated workflow for generating self-signed certificates using the `self-signed-cert` skill.
+
+## Instructions
+1.  **Load Skill**: Activate the `self-signed-cert` skill instructions.
+2.  **Requirement Analysis**: Determine common name (CN) and Subject Alternative Names (SANs).
+3.  **Execution**:
+    - **Linux/macOS**:
+        - `bash scripts/generate-cert.sh root my-internal-ca`
+        - `bash scripts/generate-cert.sh cert my-service localhost`
+    - **Windows**:
+        - `.\scripts\generate-cert.ps1 -Type root -Name my-internal-ca`
+        - `.\scripts\generate-cert.ps1 -Type cert -Name my-service -Dns localhost`
+4.  **Packaging**: Provide instructions for importing the cert into trust stores (OS, Browsers) or mounting in Kubernetes secrets.
+5.  **Security**: Ensure private keys are stored with restricted permissions (600).
+6.  **Rotation**: Offer a schedule for certificate renewal.

package/_bmad/custom/workflows/cyber/immunity-estimation.md

@@ -0,0 +1,20 @@
+# workflow-immunity-estimation.md
+# Cyber Immunity Estimation Workflow
+
+Assesses the overall security posture and 'immunity' of the system against common attack vectors.
+
+## Instructions
+1.  **Attack Surface Analysis**: Identify all entry points (APIs, UI, SSH, 3rd party integrations).
+2.  **Control Verification**:
+    - Authentication/Authorization presence.
+    - Encryption in transit and at rest.
+    - Secret management maturity (Hardcoded vs Vault).
+3.  **Posture Scoring**: Rate 1-10 on:
+    - Code quality/Sanitization.
+    - Dependency health.
+    - Infrastructure hardening.
+    - Visibility/Logging.
+4.  **Immunity Report**:
+    - Summarize major gaps.
+    - Provide a roadmap for reach 'Immunity Level 5' (Robust).
+5.  **Verification**: Recommend automated regression tests for security controls.

package/_bmad/custom/workflows/cyber/security-audit.md

@@ -0,0 +1,18 @@
+# workflow-security-audit.md
+# Comprehensive Security Audit Workflow
+
+Deep-dive audit of infrastructure and application configuration.
+
+## Instructions
+1.  **Infrastructure Audit**:
+    - **K8s**: Check for privileged containers, missing network policies, root users.
+    - **Docker**: Check for exposed ports, unnecessary packages in images.
+2.  **Code Audit**:
+    - Static Analysis (SAST) for common patterns (SQLi, XSS).
+    - Check for insecure defaults in frameworks.
+3.  **Identity Audit**:
+    - Review ServiceAccount permissions (RBAC).
+    - Check for hard-coded credentials.
+4.  **Final Recommendation**: 
+    - Provide a prioritized list of hardening tasks.
+    - Propose CIDCD guardrails.

package/_bmad/custom/workflows/cyber/vault-secrets.md

@@ -0,0 +1,19 @@
+# workflow-vault-secrets.md
+# HashiCorp Vault Secret Management Workflow
+
+This workflow guides the agent through managing secrets, policies, and authentication in HashiCorp Vault.
+
+## Instructions
+1.  **Check Connection**: Verify `vault status` and authentication.
+2.  **Secret Creation/Update**:
+    - `vault kv put secret/{path} {key}={value}`
+    - Ensure secrets are never logged or echoed in plain text.
+3.  **Policy Management**:
+    - Define HCL policies for restricted access.
+    - `vault policy write {name} {policy_file}`
+4.  **Integration**:
+    - Manage Kubernetes auth method: `vault auth enable kubernetes`
+    - Setup Vault Agent injector configurations.
+5.  **Audit**:
+    - Check for expired tokens or orphaned secrets.
+    - Review access logs if available.

package/_bmad/custom/workflows/cyber/verify-docker-users.md

@@ -0,0 +1,14 @@
+# verify-docker-users.md
+# Docker User & Hardening Verification Workflow
+
+This workflow guides the Cyber agent through auditing Docker images for proper user management and least privilege.
+
+## Instructions
+1.  **Inspect Metadata**:
+    - Use the `docker-hardening-verification` skill.
+    - Run: `bash skills/docker-hardening-verification/scripts/verify-hardening.sh {image_name}`.
+2.  **Audit Result Analysis**:
+    - **UID Check**: Confirm the defined user is non-zero.
+    - **Permissive Files**: Scan for world-writable files in common paths (/tmp, /etc, /var).
+3.  **Governance Check**: Ensure the image follows OpenShift/hardened cluster requirements (no root, arbitrary UID support).
+4.  **Reporting**: provide a high-level summary of hardening quality and mandatory fixes.

package/_bmad/custom/workflows/cyber/verify-image-signature.md

@@ -0,0 +1,13 @@
+# verify-image-signature.md
+# Docker Image Signature Verification Workflow
+
+This workflow guides the Cyber agent through verifying that a Docker image has been properly signed.
+
+## Instructions
+1.  **Identify Image**: Get the image name and digest.
+2.  **Locate Public Key**: Obtain the public key or certificate used for signing.
+3.  **Execute Verification**:
+    - Use `cosign verify --key {public_key} {image_digest}`.
+    - Check the output for valid signatures.
+4.  **Policy Compliance**: Verify if the signing entity (certificate CN) matches the expected trusted authorities.
+5.  **Report**: Alert the user if the image is unsigned or the signature is invalid.

package/_bmad/custom/workflows/cyber/vulnerability-scan.md

@@ -0,0 +1,19 @@
+# workflow-vulnerability-scan.md
+# ma-agents Vulnerability Scan Orchestration
+
+Orchestrates multiple security-focused skills from the `ma-agents` package to provide a comprehensive security scan.
+
+## Instructions
+1.  **Select Scanners**: Based on project tech stack, trigger:
+    - **JS/TS**: `js-ts-security-skill`
+    - **Python**: `python-security-skill`
+    - **Docker**: `verify-hardened-docker-skill`
+2.  **Run Tools**:
+    - Execute `npm audit` or `yarn audit`.
+    - Run `pip-audit` for Python environments.
+    - Run `trivy image {image}` for containers.
+3.  **Aggregate Results**: Collect all findings into a unified report.
+4.  **Prioritization**: Rank vulnerabilities by CVSS score and exploitability.
+5.  **Remediation**:
+    - Propose version upgrades.
+    - Propose configuration hardening steps.

package/_bmad/custom/workflows/devops/configure-infrastructure.md

@@ -0,0 +1,18 @@
+# workflow-configure-infrastructure.md
+# Infrastructure Configuration Workflow
+
+This workflow focuses on defining and configuring core infrastructure components in a Kubernetes environment.
+
+## Instructions
+1.  **Storage Definition**:
+    - Define `PersistentVolume` (PV) with appropriate access modes and storage classes.
+    - Define `PersistentVolumeClaim` (PVC) for application workloads.
+2.  **Networking**:
+    - Configure `Service` type `LoadBalancer` or `Ingress` controllers.
+    - Define `NetworkPolicies` for secure communication.
+3.  **Disconnected Environments**:
+    - Provide templates for local storage provisioners (e.g., hostPath, Local Persistent Volumes).
+    - Configure static IP assignments for on-prem load balancers.
+4.  **Validation**:
+    - Verify binding status: `kubectl get pv,pvc`
+    - Verify endpoint availability: `kubectl get endpoints`

package/_bmad/custom/workflows/devops/disconnected-deployment.md

@@ -0,0 +1,18 @@
+# workflow-disconnected-deployment.md
+# Disconnected Environment Deployment Workflow
+
+Strategies and actions for deploying applications in air-gapped or restricted on-prem environments.
+
+## Instructions
+1.  **Dependency Gathering**:
+    - Identify all required container images.
+    - Export images: `docker save {image_list} | gzip > images.tar.gz`
+    - Package Helm charts: `helm package {chart_path}`
+2.  **Target Readiness**:
+    - Verify local registry availability.
+    - Import images: `docker load < images.tar.gz`
+3.  **Deployment**:
+    - Use `--set image.repository={local_registry}/{repo}` for Helm.
+    - Verify offline connectivity between components.
+4.  **Troubleshooting**:
+    - Check for 'ImagePullBackOff' due to incorrect registry paths.

package/_bmad/custom/workflows/devops/docker-compose-setup.md

@@ -0,0 +1,17 @@
+# workflow-docker-compose-setup.md
+# Docker Compose Management Workflow
+
+This workflow handles multi-container orchestration using Docker Compose, optimized for development and on-prem deployments.
+
+## Instructions
+1.  **Define Services**: Map application components to Docker services.
+2.  **Environment Sync**: Setup `.env` file management for different environments (on-prem, dev).
+3.  **Disconnected Operations**:
+    - Build images with `--pull=false` if registry is unavailable.
+    - Use local image tags.
+4.  **Orchestration**:
+    - Setup dependencies with `depends_on` and health checks.
+    - Configure volumes for persistence.
+5.  **Execution**:
+    - `docker-compose up -d`
+    - `docker-compose ps`

package/_bmad/custom/workflows/devops/manage-helm.md

@@ -0,0 +1,19 @@
+# workflow-manage-helm.md
+# Helm Management Workflow
+
+This workflow handles the creation and management of Helm charts and Helm umbrellas for complex systems.
+
+## Instructions
+1.  **Analyze System**: Determine if a single chart or an umbrella chart (multiple sub-charts) is needed.
+2.  **Chart Creation**: 
+    - `helm create {chart_name}`
+    - Structure for disconnected environments: Ensure all chart dependencies are bundled (vendorized).
+3.  **Helm Umbrella Setup**:
+    - Configure `Chart.yaml` with sub-chart dependencies.
+    - Setup `values.yaml` to override sub-chart values.
+4.  **On-prem Optimization**:
+    - Prepare `chart-save` and `chart-load` routines for air-gapped systems.
+    - Configure local registry mirrors.
+5.  **Validation**:
+    - `helm lint {chart_path}`
+    - `helm template {chart_path}`

package/_bmad/custom/workflows/devops/sign-docker-image.md

@@ -0,0 +1,15 @@
+# sign-docker-image.md
+# Docker Image Signing Workflow
+
+This workflow guides the DevOps agent through the process of cryptographically signing a Docker image.
+
+## Instructions
+1.  **Select Image**: Identify the image to sign.
+2.  **Get Digest**: Retrieve the immutable digest: `docker inspect --format='{{index .RepoDigests 0}}' {image_name}`.
+3.  **Prepare Certificate**: Locate the certificate file provided by the user.
+4.  **Execute Signing**:
+    - Use the `docker-image-signing` skill.
+    - Path: `skills/docker-image-signing/scripts/sign-image.sh`
+    - Run: `bash skills/docker-image-signing/scripts/sign-image.sh {image_digest} {cert_file} {key_file}`
+5.  **Verify**: Confirm the signature using `cosign verify`.
+6.  **Report**: provide the signed image reference to the user.

package/_bmad/custom/workflows/mil498/bmad-mil-generate-ocd.md

@@ -0,0 +1,17 @@
+# bmad-mil-generate-ocd.md
+# Generate Operational Concept Description (OCD)
+
+This workflow generates a MIL-STD-498 OCD document to describe the system from a user's perspective.
+
+## Instructions
+1.  **Load Template**: Read the OCD template from `{project-root}/_bmad/bmm/templates/mil498/OCD.md`.
+2.  **Gather Context**:
+    - Load the **PRD** for user needs and business goals.
+    - Load the **Architecture** for system context.
+    - Load **UX Designs** for user workflows and interactions.
+3.  **Map Concept**:
+    - **Section 3 (Current system or situation)**: Describe the problem being solved (from PRD).
+    - **Section 4 (Nature of proposed changes)**: Overview of the solution.
+    - **Section 5 (Operational concept)**: Describe user roles, operational scenarios, and key workflows (from UX/Stories).
+4.  **Clarity**: Ensure the document is written in a way that is easily understood by system users and stakeholders.
+5.  **Output**: Save the generated document to the `{output_folder}/planning-artifacts/` as `OCD.md`.

package/_bmad/custom/workflows/mil498/bmad-mil-generate-sdd.md

@@ -0,0 +1,18 @@
+# bmad-mil-generate-sdd.md
+# Generate Software Design Description (SDD)
+
+This workflow generates a MIL-STD-498 SDD document (using the SSDD template) based on the system design and implementation details.
+
+## Instructions
+1.  **Load Template**: Read the SSDD template from `{project-root}/_bmad/bmm/templates/mil498/SSDD.md`.
+2.  **Gather Context**:
+    - Load the **Architecture** document for high-level design and component structure.
+    - Load **UX Designs** for detailed user interface design.
+    - Load **Epics and Stories** to understand detailed behavior and logic.
+    - Load the **PRD** for design constraints.
+3.  **Map Design**:
+    - **Section 3 (CSCI-wide design decisions)**: Describe the architectural patterns and technology stack.
+    - **Section 4 (CSCI architectural design)**: Define components, their interfaces, and data flow.
+    - **Section 5 (CSCI detailed design)**: Map Stories to detailed logic and internal data structures.
+4.  **Consistency**: Ensure the design matches the requirements specified in the SRS.
+5.  **Output**: Save the generated document to the `{output_folder}/planning-artifacts/` as `SDD.md`.

package/_bmad/custom/workflows/mil498/bmad-mil-generate-sdp.md

@@ -0,0 +1,17 @@
+# bmad-mil-generate-sdp.md
+# Generate Software Development Plan (SDP)
+
+This workflow generates a MIL-STD-498 SDP document to outline the development approach and project management artifacts.
+
+## Instructions
+1.  **Load Template**: Read the SDP template from `{project-root}/_bmad/bmm/templates/mil498/SDP.md`.
+2.  **Gather Context**:
+    - Load the **Product Brief** for project vision and objectives.
+    - Load the **PRD** for scope and constraints.
+    - Identify any **Planning Documents** or schedules.
+3.  **Map Plan**:
+    - **Section 3 (Project organization and resources)**: Define roles and resources based on the Product Brief.
+    - **Section 4 (Software development process)**: Describe the BMAD-METHOD lifecycle used.
+    - **Section 5 (Software development activities)**: Detail the tasks, schedules, and milestones.
+4.  **Consistency**: Ensure the plan reflects the actual development methodology being followed.
+5.  **Output**: Save the generated document to the `{output_folder}/planning-artifacts/` as `SDP.md`.

package/_bmad/custom/workflows/mil498/bmad-mil-generate-srs.md

@@ -0,0 +1,19 @@
+# bmad-mil-generate-srs.md
+# Generate Software Requirements Specification (SRS)
+
+This workflow generates a MIL-STD-498 SRS document by extracting requirements from BMAD-METHOD records.
+
+## Instructions
+1.  **Load Template**: Read the SRS template from `{project-root}/_bmad/bmm/templates/mil498/SRS.md`.
+2.  **Gather Context**:
+    - Load the **PRD** to identify functional and non-functional requirements.
+    - Load the **Architecture** document to understand system boundaries and external interfaces.
+    - Load **UX Designs** to define user interface requirements.
+    - Load **Epics** to group related requirements into capabilities (Section 3.2).
+3.  **Map Requirements**:
+    - **Section 3.1 (States and Modes)**: Identify any operational modes from the PRD/Architecture.
+    - **Section 3.2 (CSCI Capability Requirements)**: Map Epics and leur related requirements to this section.
+    - **Section 3.3 (External Interface Requirements)**: Map Architecture interface definitions here.
+    - **Section 3.10 (Computer Resource Requirements)**: Extract hardware/software constraints from the Architecture document.
+4.  **Traceability**: Ensure each requirement has a unique CID and is traced to the original PRD entry.
+5.  **Output**: Save the generated document to the `{output_folder}/planning-artifacts/` as `SRS.md`.

package/_bmad/custom/workflows/mil498/bmad-mil-generate-sss.md

@@ -0,0 +1,16 @@
+# bmad-mil-generate-sss.md
+# Generate System/Subsystem Specification (SSS)
+
+This workflow generates a MIL-STD-498 SSS document for high-level system requirements.
+
+## Instructions
+1.  **Load Template**: Read the SSS template from `{project-root}/_bmad/bmm/templates/mil498/SSS.md`.
+2.  **Gather Context**:
+    - Load the **Product Brief** for high-level system identification and goals.
+    - Load the **PRD** for primary system requirements.
+3.  **Map Requirements**:
+    - **Section 3.2 (System capability requirements)**: Map high-level PRD features to system capabilities.
+    - **Section 3.3 (System external interface requirements)**: Map top-level interfaces.
+    - **Section 3.4 (System internal interface requirements)**: Map interfaces between major subsystems.
+4.  **High-Level Focus**: Keep requirements at the system/subsystem level, avoiding low-level software details.
+5.  **Output**: Save the generated document to the `{output_folder}/planning-artifacts/` as `SSS.md`.

package/_bmad/custom/workflows/mil498/bmad-mil-generate-std.md

@@ -0,0 +1,17 @@
+# bmad-mil-generate-std.md
+# Generate Software Test Description (STD)
+
+This workflow generates a MIL-STD-498 STD document to define the test cases and procedures for software qualification.
+
+## Instructions
+1.  **Load Template**: Read the STD template from `{project-root}/_bmad/bmm/templates/mil498/STD.md`.
+2.  **Gather Context**:
+    - Load the **Architecture** for test environment details.
+    - Load **Epics and Stories** to identify test objectives and acceptance criteria.
+    - Load the **SRS** to link test cases to requirements (Traceability).
+3.  **Map Tests**:
+    - **Section 3 (Test preparations)**: Describe hardware/software needed for testing (from Architecture).
+    - **Section 4 (Test descriptions)**: Map Story acceptance criteria to specific test cases and procedures.
+    - **Section 5 (Requirements traceability)**: Link each test case to one or more SRS requirements.
+4.  **Verification**: Ensure all requirements in the SRS have at least one test case.
+5.  **Output**: Save the generated document to the `{output_folder}/planning-artifacts/` as `STD.md`.

package/_bmad/custom/workflows/sre/check-deployment-status.md

@@ -0,0 +1,23 @@
+# workflow-check-deployment-status.md
+# Deployment Status Check Workflow
+
+This workflow guides the agent through checking the status of a specific deployment in a Kubernetes cluster.
+
+## Parameters
+- `{namespace}`: The namespace of the deployment (default: `default`)
+- `{deployment_name}`: The name of the deployment to check
+
+## Instructions
+1.  **Identify Resource**: Determine the `{deployment_name}` and `{namespace}` from user input or context.
+2.  **Run Diagnostics**:
+    -   `kubectl get deployment {deployment_name} -n {namespace}`
+    -   `kubectl describe deployment {deployment_name} -n {namespace}`
+3.  **Check Pods**:
+    -   `kubectl get pods -l app={deployment_name} -n {namespace}`
+    -   Identify any pods that are NOT in `Running` state.
+4.  **Analyze Events**:
+    -   Look at the `Events` section of the `describe` output for error messages (e.g., `ImagePullBackOff`, `CrashLoopBackOff`).
+5.  **Report**:
+    -   Summarize the current status.
+    -   Highlight any issues found.
+    -   Suggest next steps (e.g., "Check logs", "Check resource limits").

package/_bmad/custom/workflows/sre/check-secrets.md

@@ -0,0 +1,14 @@
+# workflow-check-secrets.md
+# Secret Debugging Workflow
+
+This workflow helps identify and resolve problems related to Kubernetes Secrets.
+
+## Instructions
+1.  **Check Visibility**: `kubectl get secret -n {namespace}`
+2.  **Verify Mounting**:
+    -   Check if the deployment actually mounts the secret.
+    -   `kubectl get deployment {deployment_name} -o yaml | grep secret`
+3.  **Check Permissions**: Verify ServiceAccount has permissions to read the secret (RBAC).
+4.  **Content Verification**: (Safety first!) Offer to check if keys exist WITHOUT displaying sensitive values unless explicitly requested.
+    -   `kubectl get secret {name} -n {namespace} -o jsonpath='{.data}'`
+5.  **Common Errors**: Look for "Secret not found" or "Authorization" errors in pod events.

package/_bmad/custom/workflows/sre/check-system-status.md

@@ -0,0 +1,18 @@
+# workflow-check-system-status.md
+# Overall System Status Workflow
+
+This workflow provides a high-level overview of the health of the container runtime and orchestration environment.
+
+## Instructions
+1.  **Detect Runtime**: Check if reachable:
+    -   `kubectl cluster-info` (Kubernetes)
+    -   `docker info` (Docker)
+    -   `podman info` (Podman)
+2.  **Resource Overview**:
+    -   **K8s**: `kubectl get nodes`, `kubectl get pods -A | grep -v Running`
+    -   **Docker**: `docker ps`, `docker stats --no-stream`
+    -   **Podman**: `podman ps`, `podman stats --no-stream`
+3.  **Cross-Platform Diagnostics**:
+    -   Check for resource exhaustion (High CPU/Memory).
+    -   Verify network connectivity between key services.
+4.  **Summary Table**: Present a status table of all detected environments.

package/_bmad/custom/workflows/sre/day-2-ops.md

@@ -0,0 +1,16 @@
+# workflow-day-2-ops.md
+# Day 2 Operations & Maintenance Workflow
+
+Focuses on long-term stability, cluster-to-config verification, and periodic maintenance.
+
+## Instructions
+1.  **Config Verification**:
+    - Check current cluster status against the master configuration templates.
+    - Verify consistency of secrets, configmaps, and resource limits.
+2.  **Resource Optimization**:
+    - Review `top nodes` and `top pods`.
+    - Identify over-provisioned or under-utilized resources.
+3.  **Maintenance Tasks**:
+    - Node drain/uncordon (safe handling).
+    - Certificate rotation check.
+4.  **Automation**: Propose cronjobs for periodic backups or diagnostic reports.

package/_bmad/custom/workflows/sre/deployment-strategies.md

@@ -0,0 +1,18 @@
+# workflow-deployment-strategies.md
+# Deployment Strategies Workflow
+
+Guides on implementing and monitoring advanced deployment techniques like Blue-Green, Canary, and Rolling Updates.
+
+## Instructions
+1.  **Select Strategy**:
+    -   **Rolling Update**: Standard Kubernetes strategy.
+    -   **Canary**: Gradual traffic shift (requires Service Mesh or specialized CRDs like Argo Rollouts).
+    -   **Blue-Green**: Instant switch between versions.
+2.  **Strategy Status**:
+    -   `kubectl get rollouts` (Argo Rollouts)
+    -   Monitor success metrics (HTTP 2xx vs 5xx) during transition.
+3.  **Health Verification**: 
+    - Verify healthy startup before increasing traffic.
+    - Automatically propose rollbacks if SLOs are breached.
+4.  **Execution**:
+    - Trigger rollout update or promotion.

package/_bmad/custom/workflows/sre/fix-deployments.md

@@ -0,0 +1,16 @@
+# workflow-fix-deployments.md
+# Deployment Fix Workflow
+
+This workflow provides automated troubleshooting steps to resolve common deployment issues.
+
+## Instructions
+1.  **Detect Issue**: Based on `check-deployment-status` output, identify the root cause.
+2.  **Image issues**: If `ImagePullBackOff`, verify image name and registry secrets.
+3.  **CrashLoopBackOff**:
+    -   `kubectl logs {deployment_name} -n {namespace} --previous`
+    -   Check for missing env vars or config maps.
+4.  **Pending State**:
+    -   Check node resources: `kubectl describe node`
+    -   Verify PersistentVolumeClaims (PVCs).
+5.  **Scaling**: If resource-related, suggest scaling or adjusting `resources.requests/limits`.
+6.  **Action**: Offer to apply a fix (e.g., `kubectl apply -f ...` or `kubectl set image ...`).

package/_bmad/custom/workflows/sre/gitops-status.md

@@ -0,0 +1,16 @@
+# workflow-gitops-status.md
+# GitOps Status & Drift Detection Workflow
+
+This workflow monitors and reports the synchronization state between your git repository and the cluster using ArgoCD or Flux.
+
+## Instructions
+1.  **Identify Tool**: Detect if ArgoCD or Flux is in use.
+2.  **Sync Status**:
+    -   **ArgoCD**: `argocd app list`, `argocd app get {app_name}`
+    -   **Flux**: `flux get kustomizations`, `flux get helmreleases`
+3.  **Drift Detection**:
+    -   Identify "OutOfSync" resources.
+    -   Compare live state with desired state in git.
+4.  **Action**:
+    -   Offer to trigger a sync: `argocd app sync {app_name}` or `flux reconcile kustomization {name}`.
+    -   Analyze reasons for permanent drift (e.g., manual cluster changes).

package/_bmad/skills/config.yaml

@@ -0,0 +1,11 @@
+# SKILLS Module Configuration
+# Generated by BMAD installer
+# Version: 6.0.4
+# Date: 2026-03-01T14:46:10.169Z
+
+
+# Core Configuration Values
+user_name: "995472"
+communication_language: English
+document_output_language: English
+output_folder: _bmad-output

package/bin/cli.js

@@ -382,9 +382,10 @@ async function installWizard(preselectedSkill, preselectedAgents, customPath, fo
   }
 
   // Install requested skills
+  const batchState = {};
   for (const skillId of selectedSkillIds) {
     try {
-      await installSkill(skillId, selectedAgentIds, installPath, installScope, { force: !!forceFlag });
+      await installSkill(skillId, selectedAgentIds, installPath, installScope, { force: !!forceFlag, batchState });
     } catch (error) {
       console.error(chalk.red(`\n Failed to install ${skillId}:`), error.message);
     }