ma-agents 2.15.0 → 2.16.1

package/_bmad/custom/agents/mil498.md

@@ -1,65 +0,0 @@
----
-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

@@ -1,54 +0,0 @@
----
-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

@@ -1,11 +0,0 @@
-# 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

@@ -1,18 +0,0 @@
-# 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

@@ -1,20 +0,0 @@
-# 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

@@ -1,18 +0,0 @@
-# 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

@@ -1,19 +0,0 @@
-# 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

@@ -1,14 +0,0 @@
-# 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

@@ -1,13 +0,0 @@
-# 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

@@ -1,19 +0,0 @@
-# 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

@@ -1,18 +0,0 @@
-# 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

@@ -1,18 +0,0 @@
-# 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

@@ -1,17 +0,0 @@
-# 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

@@ -1,19 +0,0 @@
-# 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

@@ -1,15 +0,0 @@
-# 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

@@ -1,17 +0,0 @@
-# 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

@@ -1,18 +0,0 @@
-# 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

@@ -1,17 +0,0 @@
-# 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

@@ -1,19 +0,0 @@
-# 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

@@ -1,16 +0,0 @@
-# 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

@@ -1,17 +0,0 @@
-# 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

@@ -1,23 +0,0 @@
-# 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

@@ -1,14 +0,0 @@
-# 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

@@ -1,18 +0,0 @@
-# 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

@@ -1,16 +0,0 @@
-# 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

@@ -1,18 +0,0 @@
-# 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

@@ -1,16 +0,0 @@
-# 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

@@ -1,16 +0,0 @@
-# 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

@@ -1,11 +0,0 @@
-# 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/_bmad/skills/sre/.ma-agents.json

@@ -1,14 +0,0 @@
-{
-  "manifestVersion": "1.0.0",
-  "agent": "bmm-sre",
-  "scope": "project",
-  "skills": {
-    "docker-image-signing": {
-      "version": "1.0.0",
-      "installedAt": "2026-03-01T10:23:35.941Z",
-      "updatedAt": "2026-03-01T10:23:35.941Z",
-      "installerVersion": "2.11.0",
-      "agentVersion": "1.0.0"
-    }
-  }
-}