ma-agents 2.15.0 → 2.16.1

package/_bmad/bmm/workflows/bmad-quick-flow/quick-spec/steps/step-04-review.md

@@ -1,200 +0,0 @@
----
-name: 'step-04-review'
-description: 'Review and finalize the tech-spec'
-
-wipFile: '{implementation_artifacts}/tech-spec-wip.md'
----
-
-# Step 4: Review & Finalize
-
-**Progress: Step 4 of 4** - Final Step
-
-## RULES:
-
-- MUST NOT skip steps.
-- MUST NOT optimize sequence.
-- MUST follow exact instructions.
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-## CONTEXT:
-
-- Requires `{wipFile}` from Step 3. 
-- MUST present COMPLETE spec content. Iterate until user is satisfied.
-- **Criteria**: The spec MUST meet the **READY FOR DEVELOPMENT** standard defined in `workflow.md`.
-
-## SEQUENCE OF INSTRUCTIONS
-
-### 1. Load and Present Complete Spec
-
-**Read `{wipFile}` completely and extract `slug` from frontmatter for later use.**
-
-**Present to user:**
-
-"Here's your complete tech-spec. Please review:"
-
-[Display the complete spec content - all sections]
-
-"**Quick Summary:**
-
-- {task_count} tasks to implement
-- {ac_count} acceptance criteria to verify
-- {files_count} files to modify"
-
-**Present review menu:**
-
-Display: "**Select:** [C] Continue [E] Edit [Q] Questions [A] Advanced Elicitation [P] Party Mode"
-
-**HALT and wait for user selection.**
-
-#### Menu Handling Logic:
-
-- IF C: Proceed to Section 3 (Finalize the Spec)
-- IF E: Proceed to Section 2 (Handle Review Feedback), then return here and redisplay menu
-- IF Q: Answer questions, then redisplay this menu
-- IF A: Read fully and follow: `{advanced_elicitation}` with current spec content, process enhanced insights, ask user "Accept improvements? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
-- IF P: Read fully and follow: `{party_mode_exec}` with current spec content, process collaborative insights, ask user "Accept changes? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
-- IF Any other comments or queries: respond helpfully then redisplay menu
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- ONLY proceed to finalize when user selects 'C'
-- After other menu items execution, return to this menu
-
-### 2. Handle Review Feedback
-
-a) **If user requests changes:**
-
-- Make the requested edits to `{wipFile}`
-- Re-present the affected sections
-- Ask if there are more changes
-- Loop until user is satisfied
-
-b) **If the spec does NOT meet the "Ready for Development" standard:**
-
-- Point out the missing/weak sections (e.g., non-actionable tasks, missing ACs).
-- Propose specific improvements to reach the standard.
-- Make the edits once the user agrees.
-
-c) **If user has questions:**
-
-- Answer questions about the spec
-- Clarify any confusing sections
-- Make clarifying edits if needed
-
-### 3. Finalize the Spec
-
-**When user confirms the spec is good AND it meets the "Ready for Development" standard:**
-
-a) Update `{wipFile}` frontmatter:
-
-   ```yaml
-   ---
-   # ... existing values ...
-   status: 'ready-for-dev'
-   stepsCompleted: [1, 2, 3, 4]
-   ---
-   ```
-
-b) **Rename WIP file to final filename:**
-   - Using the `slug` extracted in Section 1
-   - Rename `{wipFile}` → `{implementation_artifacts}/tech-spec-{slug}.md`
-   - Store this as `finalFile` for use in menus below
-
-### 4. Present Final Menu
-
-a) **Display completion message and menu:**
-
-```
-**Tech-Spec Complete!**
-
-Saved to: {finalFile}
-
----
-
-**Next Steps:**
-
-[A] Advanced Elicitation - refine further
-[R] Adversarial Review - critique of the spec (highly recommended)
-[B] Begin Development - start implementing now (not recommended)
-[D] Done - exit workflow
-[P] Party Mode - get expert feedback before dev
-
----
-
-Once you are fully satisfied with the spec (ideally after **Adversarial Review** and maybe a few rounds of **Advanced Elicitation**), it is recommended to run implementation in a FRESH CONTEXT for best results.
-
-Copy this prompt to start dev:
-
-\`\`\`
-quick-dev {finalFile}
-\`\`\`
-
-This ensures the dev agent has clean context focused solely on implementation.
-```
-
-b) **HALT and wait for user selection.**
-
-#### Menu Handling Logic:
-
-- IF A: Read fully and follow: `{advanced_elicitation}` with current spec content, process enhanced insights, ask user "Accept improvements? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
-- IF B: Read the entire workflow file at `{quick_dev_workflow}` and follow the instructions with the final spec file (warn: fresh context is better)
-- IF D: Exit workflow - display final confirmation and path to spec
-- IF P: Read fully and follow: `{party_mode_exec}` with current spec content, process collaborative insights, ask user "Accept changes? (y/n)", if yes update spec then redisplay menu, if no keep original then redisplay menu
-- IF R: Execute Adversarial Review (see below)
-- IF Any other comments or queries: respond helpfully then redisplay menu
-
-#### EXECUTION RULES:
-
-- ALWAYS halt and wait for user input after presenting menu
-- After A, P, or R execution, return to this menu
-
-#### Adversarial Review [R] Process:
-
-1. **Invoke Adversarial Review Task**:
-       > With `{finalFile}` constructed, load and follow the review task. If possible, use information asymmetry: load this task, and only it, in a separate subagent or process with read access to the project, but no context except the `{finalFile}`.
-       <invoke-task>Review {finalFile} using {project-root}/_bmad/core/tasks/review-adversarial-general.xml</invoke-task>
-       > **Platform fallback:** If task invocation not available, load the task file and follow its instructions inline, passing `{finalFile}` as the content.
-       > The task should: review `{finalFile}` and return a list of findings.
-
-    2. **Process Findings**:
-       > Capture the findings from the task output.
-       > **If zero findings:** HALT - this is suspicious. Re-analyze or request user guidance.
-       > Evaluate severity (Critical, High, Medium, Low) and validity (real, noise, undecided).
-       > DO NOT exclude findings based on severity or validity unless explicitly asked to do so.
-       > Order findings by severity.
-       > Number the ordered findings (F1, F2, F3, etc.).
-       > If TodoWrite or similar tool is available, turn each finding into a TODO, include ID, severity, validity, and description in the TODO; otherwise present findings as a table with columns: ID, Severity, Validity, Description
-
-    3. Return here and redisplay menu.
-
-### 5. Exit Workflow
-
-**When user selects [D]:**
-
-"**All done!** Your tech-spec is ready at:
-
-`{finalFile}`
-
-When you're ready to implement, run:
-
-```
-quick-dev {finalFile}
-```
-
-Ship it!"
-
----
-
-## REQUIRED OUTPUTS:
-
-- MUST update status to 'ready-for-dev'.
-- MUST rename file to `tech-spec-{slug}.md`.
-- MUST provide clear next-step guidance and recommend fresh context for dev.
-
-## VERIFICATION CHECKLIST:
-
-- [ ] Complete spec presented for review.
-- [ ] Requested changes implemented.
-- [ ] Spec verified against **READY FOR DEVELOPMENT** standard.
-- [ ] `stepsCompleted: [1, 2, 3, 4]` set and file renamed.

package/_bmad/bmm/workflows/bmad-quick-flow/quick-spec/tech-spec-template.md

@@ -1,74 +0,0 @@
----
-title: '{title}'
-slug: '{slug}'
-created: '{date}'
-status: 'in-progress'
-stepsCompleted: []
-tech_stack: []
-files_to_modify: []
-code_patterns: []
-test_patterns: []
----
-
-# Tech-Spec: {title}
-
-**Created:** {date}
-
-## Overview
-
-### Problem Statement
-
-{problem_statement}
-
-### Solution
-
-{solution}
-
-### Scope
-
-**In Scope:**
-{in_scope}
-
-**Out of Scope:**
-{out_of_scope}
-
-## Context for Development
-
-### Codebase Patterns
-
-{codebase_patterns}
-
-### Files to Reference
-
-| File | Purpose |
-| ---- | ------- |
-
-{files_table}
-
-### Technical Decisions
-
-{technical_decisions}
-
-## Implementation Plan
-
-### Tasks
-
-{tasks}
-
-### Acceptance Criteria
-
-{acceptance_criteria}
-
-## Additional Context
-
-### Dependencies
-
-{dependencies}
-
-### Testing Strategy
-
-{testing_strategy}
-
-### Notes
-
-{notes}

package/_bmad/bmm/workflows/bmad-quick-flow/quick-spec/workflow.md

@@ -1,79 +0,0 @@
----
-name: quick-spec
-description: 'Very quick process to create implementation-ready quick specs for small changes or features. Use when the user says "create a quick spec" or "generate a quick tech spec"'
-main_config: '{project-root}/_bmad/bmm/config.yaml'
-
-# Checkpoint handler paths
-advanced_elicitation: '{project-root}/_bmad/core/workflows/advanced-elicitation/workflow.xml'
-party_mode_exec: '{project-root}/_bmad/core/workflows/party-mode/workflow.md'
-quick_dev_workflow: '{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-dev/workflow.md'
----
-
-# Quick-Spec Workflow
-
-**Goal:** Create implementation-ready technical specifications through conversational discovery, code investigation, and structured documentation.
-
-**READY FOR DEVELOPMENT STANDARD:**
-
-A specification is considered "Ready for Development" ONLY if it meets the following:
-
-- **Actionable**: Every task has a clear file path and specific action.
-- **Logical**: Tasks are ordered by dependency (lowest level first).
-- **Testable**: All ACs follow Given/When/Then and cover happy path and edge cases.
-- **Complete**: All investigation results from Step 2 are inlined; no placeholders or "TBD".
-- **Self-Contained**: A fresh agent can implement the feature without reading the workflow history.
-
----
-
-**Your Role:** You are an elite developer and spec engineer. You ask sharp questions, investigate existing code thoroughly, and produce specs that contain ALL context a fresh dev agent needs to implement the feature. No handoffs, no missing context - just complete, actionable specs.
-
----
-
-## WORKFLOW ARCHITECTURE
-
-This uses **step-file architecture** for disciplined execution:
-
-### Core Principles
-
-- **Micro-file Design**: Each step is a self-contained instruction file that must be followed exactly
-- **Just-In-Time Loading**: Only the current step file is in memory - never load future step files until directed
-- **Sequential Enforcement**: Sequence within step files must be completed in order, no skipping or optimization
-- **State Tracking**: Document progress in output file frontmatter using `stepsCompleted` array
-- **Append-Only Building**: Build the tech-spec by updating content as directed
-
-### Step Processing Rules
-
-1. **READ COMPLETELY**: Always read the entire step file before taking any action
-2. **FOLLOW SEQUENCE**: Execute all numbered sections in order, never deviate
-3. **WAIT FOR INPUT**: If a menu is presented, halt and wait for user selection
-4. **CHECK CONTINUATION**: Only proceed to next step when user selects [C] (Continue)
-5. **SAVE STATE**: Update `stepsCompleted` in frontmatter before loading next step
-6. **LOAD NEXT**: When directed, read fully and follow the next step file
-
-### Critical Rules (NO EXCEPTIONS)
-
-- **NEVER** load multiple step files simultaneously
-- **ALWAYS** read entire step file before execution
-- **NEVER** skip steps or optimize the sequence
-- **ALWAYS** update frontmatter of output file when completing a step
-- **ALWAYS** follow the exact instructions in the step file
-- **ALWAYS** halt at menus and wait for user input
-- **NEVER** create mental todo lists from future steps
-
----
-
-## INITIALIZATION SEQUENCE
-
-### 1. Configuration Loading
-
-Load and read full config from `{main_config}` and resolve:
-
-- `project_name`, `planning_artifacts`, `implementation_artifacts`, `user_name`
-- `communication_language`, `document_output_language`, `user_skill_level`
-- `date` as system-generated current datetime
-- `project_context` = `**/project-context.md` (load if exists)
-- ✅ YOU MUST ALWAYS SPEAK OUTPUT In your Agent communication style with the config `{communication_language}`
-
-### 2. First Step Execution
-
-Read fully and follow: `{project-root}/_bmad/bmm/workflows/bmad-quick-flow/quick-spec/steps/step-01-understand.md` to begin the workflow.

package/_bmad/bmm/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/bmm/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/bmm/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/bmm/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/bmm/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/bmm/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/bmm/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/bmm/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/bmm/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/bmm/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/bmm/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/bmm/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.