ma-agents 3.6.2 → 3.9.0

package/lib/bmad-extension/.claude-plugin/marketplace.json.template

@@ -0,0 +1,117 @@
+{
+  "_comment": [
+    "BMAD Builder convention: the wrapper directory '.claude-plugin/' is a SHARED convention used by skills-capable platforms — it is NOT a Claude-only binding. BMAD adopted Anthropic's published plugin layout because it was the closest thing to an open standard at the time; multi-tool routing (claude-code, copilot, cline, roo-code, kilocode, cursor) is handled by BMAD's own installer based on the --tools flag. See https://bmad-builder-docs.bmad-method.org/how-to/distribute-your-module/ and https://bmad-builder-docs.bmad-method.org/explanation/.",
+    "This is a TEMPLATE file consumed by scripts/build-plugin.js (Story 22.4). Tokens of the form ${var} are replaced at build time; the resolved manifest lands at lib/bmad-extension-plugin/.claude-plugin/marketplace.json. Do NOT hand-edit the generated file.",
+    "Fields follow the v6.5.0 schema read by tools/installer/modules/custom-module-manager.js (top-level: name, owner, description, license, homepage, repository, keywords; per-plugin: name, source, description, version, author, skills[]).",
+    "plugins[].source interpretation: a value of \"./\" means 'the directory containing .claude-plugin/' — i.e. the plugin output root (lib/bmad-extension-plugin/). Skill paths (\"./skills/<name>\") are resolved relative to that same root. Story 22.4's build script MUST honor this convention.",
+    "compatible_tools is an informational, BMAD-wide convention (not read by the installer) used to signal multi-tool parity with downstream consumers. The authoritative list of supported tools is the --tools flag accepted by the BMAD installer.",
+    "bmad_min_version forward-compat policy: this floor assumes upstream bmad-method changes remain additive (new fields / new optional schema). Any breaking upstream change requires bumping bmad_min_version in lockstep with the pinned bmad-method dependency in package.json."
+  ],
+  "name": "ma-agents",
+  "owner": {
+    "name": "Alon Mayaffit"
+  },
+  "description": "ma-agents BMAD extension — enterprise SDLC personas (Yael, Amit, Alex, Demerzel, Gad) plus MIL-STD-498, SRE, DevOps, Cyber, ML, and SQA workflow skills.",
+  "license": "MIT",
+  "homepage": "https://github.com/mayafit/AI_Agents",
+  "repository": "https://github.com/mayafit/AI_Agents",
+  "keywords": [
+    "bmad",
+    "ma-agents",
+    "enterprise",
+    "sdlc",
+    "mil-std-498",
+    "sre",
+    "devops",
+    "cyber",
+    "ml",
+    "sqa",
+    "claude-code",
+    "copilot",
+    "cline",
+    "roo-code",
+    "kilocode"
+  ],
+  "compatible_tools": [
+    "claude-code",
+    "copilot",
+    "cline",
+    "roo-code",
+    "kilocode"
+  ],
+  "bmad_min_version": "6.5.0",
+  "plugins": [
+    {
+      "name": "ma-skills",
+      "source": "./",
+      "description": "ma-agents extension module providing enterprise SDLC personas and operational workflow skills.",
+      "version": "${version}",
+      "author": {
+        "name": "Alon Mayaffit"
+      },
+      "skills": [
+        "./skills/ma-agent-cyber",
+        "./skills/ma-agent-devops",
+        "./skills/ma-agent-ml",
+        "./skills/ma-agent-sqa",
+        "./skills/ma-agent-sre",
+        "./skills/mil498-ocd",
+        "./skills/mil498-requirement-quality",
+        "./skills/mil498-sdd",
+        "./skills/mil498-sdp",
+        "./skills/mil498-srs",
+        "./skills/mil498-ssdd",
+        "./skills/mil498-sss",
+        "./skills/mil498-std",
+        "./skills/sqa-audit",
+        "./skills/sqa-ieee12207",
+        "./skills/sqa-requirements-quality",
+        "./skills/sre-check-deployment-status",
+        "./skills/sre-check-secrets",
+        "./skills/sre-check-system-status",
+        "./skills/sre-day-2-ops",
+        "./skills/sre-deployment-strategies",
+        "./skills/sre-fix-deployments",
+        "./skills/sre-gitops-status",
+        "./skills/devops-configure-infrastructure",
+        "./skills/devops-disconnected-deployment",
+        "./skills/devops-docker-compose-setup",
+        "./skills/devops-manage-helm",
+        "./skills/devops-sign-docker-image",
+        "./skills/cyber-generate-certs",
+        "./skills/cyber-immunity-estimation",
+        "./skills/cyber-security-audit",
+        "./skills/cyber-vault-secrets",
+        "./skills/cyber-verify-docker-users",
+        "./skills/cyber-verify-image-signature",
+        "./skills/cyber-vulnerability-scan",
+        "./skills/ml-advise",
+        "./skills/ml-analysis",
+        "./skills/ml-architecture",
+        "./skills/ml-detailed-design",
+        "./skills/ml-eda",
+        "./skills/ml-experiment",
+        "./skills/ml-hparam",
+        "./skills/ml-ideation",
+        "./skills/ml-infra",
+        "./skills/ml-retrospective",
+        "./skills/ml-revision",
+        "./skills/ml-techspec",
+        "./skills/add-sprint",
+        "./skills/add-to-sprint",
+        "./skills/bmad-dev-story",
+        "./skills/bmad-sprint-planning",
+        "./skills/bmad-sprint-status",
+        "./skills/cleanup-done",
+        "./skills/close-sprint",
+        "./skills/create-bug-story",
+        "./skills/generate-backlog",
+        "./skills/modify-sprint",
+        "./skills/prioritize-backlog",
+        "./skills/project-context-expansion",
+        "./skills/remove-from-sprint",
+        "./skills/sprint-status-view"
+      ]
+    }
+  ]
+}

package/lib/bmad-extension/skills/add-sprint/SKILL.md

@@ -11,6 +11,45 @@ triggers:
 
 Guided workflow to create a new sprint entry in the `sprints` section of `sprint-status.yaml` with capacity limits, optional ISO dates, and auto-incremented sprint ID.
 
+## Backend Routing
+
+Before executing any file-system operations, determine and route to the correct backend:
+
+1. Read `_bmad-output/implementation-artifacts/sprint-status.yaml` and extract the `tracking_system` field.
+   If the field is absent or the file does not exist, default to `file-system`.
+
+2. If `tracking_system` is `file-system`:
+   Proceed with the **File-System Backend** instructions below.
+
+3. If `tracking_system` is `jira`:
+   a. Perform the Jira operation: Create a new sprint in the board for project `{jira_project_key}` at `{jira_url}` using the sprint create API. Set the sprint name, goal (if provided), start date, and end date from the provided sprint data. The new sprint starts in "future/planning" state.
+      Use whatever Jira-capable tool is available in your current tool context.
+      Map Jira entities to the canonical schema (Sprint → sprints[], Backlog → backlog[],
+      Epic → epics[], Jira status → canonical vocabulary per Section 6.3 of the routing spec).
+   b. If the Jira operation SUCCEEDS: continue with the Jira data returned. Jira is the source of truth.
+   c. If the Jira operation FAILS for any reason:
+      - If no Jira-capable tool is available in your current context:
+        Pause and present the user with:
+        > "No Jira-capable tool is available. To use Jira tracking, configure a Jira integration
+        > in your agent (an MCP server, plugin, or native integration connected to the Jira
+        > instance at `{jira_url}`). How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again once a Jira tool is configured
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      - If a Jira tool attempted the operation but returned an error:
+        Pause and present the user with:
+        > "The Jira operation failed: {actual Jira error details}. How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      If user chooses (b) in either case: write `tracking_system: file-system` to `sprint-status.yaml`,
+      update `sprint_backend: file-system` in `_bmad/bmm/config.yaml`,
+      then proceed with **File-System Backend** instructions below.
+
+4. **File-System Backend** — execute the workflow steps below.
+
+---
+
 <workflow>
 
 <step n="0" goal="Load configuration and validate file existence">

package/lib/bmad-extension/skills/add-to-sprint/SKILL.md

@@ -13,6 +13,45 @@ Guided workflow to move backlog items to a sprint in the unified `sprint-status.
 
 **Movement semantics:** Each item exists in exactly one location — either the `backlog` array OR a sprint's `items` array, never both. This skill atomically removes items from `backlog` and appends them to the target sprint's `items` array in a single file write.
 
+## Backend Routing
+
+Before executing any file-system operations, determine and route to the correct backend:
+
+1. Read `_bmad-output/implementation-artifacts/sprint-status.yaml` and extract the `tracking_system` field.
+   If the field is absent or the file does not exist, default to `file-system`.
+
+2. If `tracking_system` is `file-system`:
+   Proceed with the **File-System Backend** instructions below.
+
+3. If `tracking_system` is `jira`:
+   a. Perform the Jira operation: Find the Jira issue matching the item ID in project `{jira_project_key}` at `{jira_url}` (search by issue key or summary). Find the active sprint on the board for project `{jira_project_key}`. Move the issue to the active sprint using the "add issue to sprint" operation.
+      Use whatever Jira-capable tool is available in your current tool context.
+      Map Jira entities to the canonical schema (Sprint → sprints[], Backlog → backlog[],
+      Epic → epics[], Jira status → canonical vocabulary per Section 6.3 of the routing spec).
+   b. If the Jira operation SUCCEEDS: continue with the Jira data returned. Jira is the source of truth.
+   c. If the Jira operation FAILS for any reason:
+      - If no Jira-capable tool is available in your current context:
+        Pause and present the user with:
+        > "No Jira-capable tool is available. To use Jira tracking, configure a Jira integration
+        > in your agent (an MCP server, plugin, or native integration connected to the Jira
+        > instance at `{jira_url}`). How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again once a Jira tool is configured
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      - If a Jira tool attempted the operation but returned an error:
+        Pause and present the user with:
+        > "The Jira operation failed: {actual Jira error details}. How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      If user chooses (b) in either case: write `tracking_system: file-system` to `sprint-status.yaml`,
+      update `sprint_backend: file-system` in `_bmad/bmm/config.yaml`,
+      then proceed with **File-System Backend** instructions below.
+
+4. **File-System Backend** — execute the workflow steps below.
+
+---
+
 <workflow>
 
 <step n="0" goal="Load configuration and validate file existence">

package/lib/bmad-extension/skills/bmad-dev-story/workflow.md

@@ -36,6 +36,45 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 
 ---
 
+## Backend Routing
+
+Before executing any status-update operations, determine and route to the correct backend:
+
+1. Read `_bmad-output/implementation-artifacts/sprint-status.yaml` and extract the `tracking_system` field.
+   If the field is absent or the file does not exist, default to `file-system`.
+
+2. If `tracking_system` is `file-system`:
+   Proceed with the **File-System Backend** instructions below.
+
+3. If `tracking_system` is `jira`:
+   a. Perform the Jira operation: Find the Jira issue matching the item ID in project `{jira_project_key}` at `{jira_url}` (search by issue key or summary). Transition the issue to the new status using the Jira issue transition API. Map canonical status to Jira workflow status: backlog → Backlog/Open, ready-for-dev → To Do/Selected for Development, in-progress → In Progress, review → In Review/Code Review, done → Done/Resolved, on-hold → On Hold/Blocked, cancelled → Won't Do/Cancelled.
+      Use whatever Jira-capable tool is available in your current tool context.
+      Map Jira entities to the canonical schema (Sprint → sprints[], Backlog → backlog[],
+      Epic → epics[], Jira status → canonical vocabulary per Section 6.3 of the routing spec).
+   b. If the Jira operation SUCCEEDS: continue with the Jira data returned. Jira is the source of truth.
+   c. If the Jira operation FAILS for any reason:
+      - If no Jira-capable tool is available in your current context:
+        Pause and present the user with:
+        > "No Jira-capable tool is available. To use Jira tracking, configure a Jira integration
+        > in your agent (an MCP server, plugin, or native integration connected to the Jira
+        > instance at `{jira_url}`). How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again once a Jira tool is configured
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      - If a Jira tool attempted the operation but returned an error:
+        Pause and present the user with:
+        > "The Jira operation failed: {actual Jira error details}. How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      If user chooses (b) in either case: write `tracking_system: file-system` to `sprint-status.yaml`,
+      update `sprint_backend: file-system` in `_bmad/bmm/config.yaml`,
+      then proceed with **File-System Backend** instructions below.
+
+4. **File-System Backend** — execute the workflow steps below.
+
+---
+
 ## EXECUTION
 
 <workflow>

package/lib/bmad-extension/skills/bmad-sprint-planning/workflow.md

@@ -42,6 +42,47 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 
 ---
 
+## Backend Routing
+
+Before executing any file-system operations, determine and route to the correct backend:
+
+1. Read `_bmad-output/implementation-artifacts/sprint-status.yaml` and extract the `tracking_system` field.
+   If the field is absent or the file does not exist, default to `file-system`.
+
+2. If `tracking_system` is `file-system`:
+   Proceed with the **File-System Backend** instructions below.
+
+3. If `tracking_system` is `jira`:
+   > "This operation will create/update Jira sprints and items in bulk. If it fails mid-way, Jira may be in partial state. The Jira server URL is `{jira_url}` and project key is `{jira_project_key}` (from `_bmad/bmm/config.yaml`). Proceed?"
+
+   a. Perform the Jira operation: Query all epics, backlog issues, sprint definitions, and sprint items for project `{jira_project_key}` at `{jira_url}` (multiple sequential read calls). For the write phase: create new Jira sprints for each sprint definition not already in Jira (one API call per sprint). Create or update Jira issues for each item in the plan (one API call per item). Map item fields as follows: title → issue summary, type → issue type (story → Story, bug → Bug), status → Jira workflow status (see status mapping below), priority → issue priority/rank. Map sprint fields: name → sprint name, start_date → sprint start date, end_date → sprint end date. Status mapping: backlog → Backlog/Open, ready-for-dev → To Do/Selected for Development, in-progress → In Progress, review → In Review/Code Review, done → Done/Resolved, on-hold → On Hold/Blocked, cancelled → Won't Do/Cancelled.
+      Use whatever Jira-capable tool is available in your current tool context.
+      Map Jira entities to the canonical schema (Sprint → sprints[], Backlog → backlog[],
+      Epic → epics[], Jira status → canonical vocabulary per Section 6.3 of the routing spec).
+   b. If the Jira operation SUCCEEDS: continue with the Jira data returned. Jira is the source of truth.
+   c. If the Jira operation FAILS for any reason:
+      - If no Jira-capable tool is available in your current context:
+        Pause and present the user with:
+        > "No Jira-capable tool is available. To use Jira tracking, configure a Jira integration
+        > in your agent (an MCP server, plugin, or native integration connected to the Jira
+        > instance at `{jira_url}`). How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again once a Jira tool is configured
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      - If a Jira tool attempted the operation but returned an error:
+        Pause and present the user with:
+        > "The Jira operation failed: {actual Jira error details}. How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      If user chooses (b) in either case: write `tracking_system: file-system` to `sprint-status.yaml`,
+      update `sprint_backend: file-system` in `_bmad/bmm/config.yaml`,
+      then proceed with **File-System Backend** instructions below.
+
+4. **File-System Backend** — execute the workflow steps below.
+
+---
+
 ## EXECUTION
 
 <workflow>

package/lib/bmad-extension/skills/bmad-sprint-status/workflow.md

@@ -37,6 +37,45 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 
 ---
 
+## Backend Routing
+
+Before executing any file-system operations, determine and route to the correct backend:
+
+1. Read `_bmad-output/implementation-artifacts/sprint-status.yaml` and extract the `tracking_system` field.
+   If the field is absent or the file does not exist, default to `file-system`.
+
+2. If `tracking_system` is `file-system`:
+   Proceed with the **File-System Backend** instructions below.
+
+3. If `tracking_system` is `jira`:
+   a. Perform the Jira operation: Query the active sprint for project `{jira_project_key}` at `{jira_url}` and retrieve all sprint issues with their statuses. Query backlog issue count. Query epic progress (completed stories per epic). Map Jira sprint states and issue statuses to canonical vocabulary per the status mapping below. Use this data for health analysis — no writes. Status mapping: Backlog/Open → backlog, To Do/Selected for Development → ready-for-dev, In Progress → in-progress, In Review/Code Review → review, Done/Resolved → done, On Hold/Blocked → on-hold, Won't Do/Cancelled → cancelled.
+      Use whatever Jira-capable tool is available in your current tool context.
+      Map Jira entities to the canonical schema (Sprint → sprints[], Backlog → backlog[],
+      Epic → epics[], Jira status → canonical vocabulary per Section 6.3 of the routing spec).
+   b. If the Jira operation SUCCEEDS: continue with the Jira data returned. Jira is the source of truth.
+   c. If the Jira operation FAILS for any reason:
+      - If no Jira-capable tool is available in your current context:
+        Pause and present the user with:
+        > "No Jira-capable tool is available. To use Jira tracking, configure a Jira integration
+        > in your agent (an MCP server, plugin, or native integration connected to the Jira
+        > instance at `{jira_url}`). How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again once a Jira tool is configured
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      - If a Jira tool attempted the operation but returned an error:
+        Pause and present the user with:
+        > "The Jira operation failed: {actual Jira error details}. How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      If user chooses (b) in either case: write `tracking_system: file-system` to `sprint-status.yaml`,
+      update `sprint_backend: file-system` in `_bmad/bmm/config.yaml`,
+      then proceed with **File-System Backend** instructions below.
+
+4. **File-System Backend** — execute the steps below.
+
+---
+
 ## EXECUTION
 
 <workflow>

package/lib/bmad-extension/skills/cleanup-done/SKILL.md

@@ -20,6 +20,45 @@ Keeps the active sprint view lean by archiving completed and cancelled work. Pre
 
 ---
 
+## Backend Routing
+
+Before executing any file-system operations, determine and route to the correct backend:
+
+1. Read `_bmad-output/implementation-artifacts/sprint-status.yaml` and extract the `tracking_system` field.
+   If the field is absent or the file does not exist, default to `file-system`.
+
+2. If `tracking_system` is `file-system`:
+   Proceed with the **File-System Backend** instructions below.
+
+3. If `tracking_system` is `jira`:
+   a. Perform the Jira operation: Query all issues in project `{jira_project_key}` at `{jira_url}` with status Done/Resolved/Closed. For each such issue that maps to a local story file at `{story_location}/{id}.md`: transition the issue to the resolved/done Jira workflow state if not already there (using the issue transition API). Then move the local story file to `{story_location}/done/{id}.md` — this local file operation always executes regardless of backend. Note: Jira issues are NOT deleted; they remain in Jira as resolved.
+      Use whatever Jira-capable tool is available in your current tool context.
+      Map Jira entities to the canonical schema (Sprint → sprints[], Backlog → backlog[],
+      Epic → epics[], Jira status → canonical vocabulary per Section 6.3 of the routing spec).
+   b. If the Jira operation SUCCEEDS: continue with the Jira data returned. Jira is the source of truth.
+   c. If the Jira operation FAILS for any reason:
+      - If no Jira-capable tool is available in your current context:
+        Pause and present the user with:
+        > "No Jira-capable tool is available. To use Jira tracking, configure a Jira integration
+        > in your agent (an MCP server, plugin, or native integration connected to the Jira
+        > instance at `{jira_url}`). How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again once a Jira tool is configured
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      - If a Jira tool attempted the operation but returned an error:
+        Pause and present the user with:
+        > "The Jira operation failed: {actual Jira error details}. How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      If user chooses (b) in either case: write `tracking_system: file-system` to `sprint-status.yaml`,
+      update `sprint_backend: file-system` in `_bmad/bmm/config.yaml`,
+      then proceed with **File-System Backend** instructions below.
+
+4. **File-System Backend** — execute the workflow steps below.
+
+---
+
 <workflow>
 
 <step n="0" goal="Load configuration and validate file existence">

package/lib/bmad-extension/skills/close-sprint/SKILL.md

@@ -13,6 +13,45 @@ Close an active sprint — archive done/cancelled items, disposition incomplete
 
 **Schema Reference:** `_bmad-output/planning-artifacts/sprint-status-schema.md` (Story 17.9)
 
+## Backend Routing
+
+Before executing any file-system operations, determine and route to the correct backend:
+
+1. Read `_bmad-output/implementation-artifacts/sprint-status.yaml` and extract the `tracking_system` field.
+   If the field is absent or the file does not exist, default to `file-system`.
+
+2. If `tracking_system` is `file-system`:
+   Proceed with the **File-System Backend** instructions below.
+
+3. If `tracking_system` is `jira`:
+   a. Perform the Jira operation: Query all issues in the active sprint for project `{jira_project_key}` at `{jira_url}`. For done/cancelled items: transition each to resolved/done Jira state using the issue transition API; then move each corresponding local story file from `{story_location}/{id}.md` to `{story_location}/done/{id}.md` (local file operation — always executes). For incomplete items (not done/cancelled): remove each issue from the sprint using the "remove issue from sprint" operation (returns them to board backlog). Then close the sprint using the sprint close API.
+      Use whatever Jira-capable tool is available in your current tool context.
+      Map Jira entities to the canonical schema (Sprint → sprints[], Backlog → backlog[],
+      Epic → epics[], Jira status → canonical vocabulary per Section 6.3 of the routing spec).
+   b. If the Jira operation SUCCEEDS: continue with the Jira data returned. Jira is the source of truth.
+   c. If the Jira operation FAILS for any reason:
+      - If no Jira-capable tool is available in your current context:
+        Pause and present the user with:
+        > "No Jira-capable tool is available. To use Jira tracking, configure a Jira integration
+        > in your agent (an MCP server, plugin, or native integration connected to the Jira
+        > instance at `{jira_url}`). How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again once a Jira tool is configured
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      - If a Jira tool attempted the operation but returned an error:
+        Pause and present the user with:
+        > "The Jira operation failed: {actual Jira error details}. How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      If user chooses (b) in either case: write `tracking_system: file-system` to `sprint-status.yaml`,
+      update `sprint_backend: file-system` in `_bmad/bmm/config.yaml`,
+      then proceed with **File-System Backend** instructions below.
+
+4. **File-System Backend** — execute the workflow steps below.
+
+---
+
 <workflow>
 
 <step n="0" goal="Load configuration and validate file existence">

package/lib/bmad-extension/skills/generate-backlog/SKILL.md

@@ -22,6 +22,47 @@ This skill reads `epics.md` and `bug-*.md` files and writes the `backlog` and `e
 
 ---
 
+## Backend Routing
+
+Before executing any file-system operations, determine and route to the correct backend:
+
+1. Read `_bmad-output/implementation-artifacts/sprint-status.yaml` and extract the `tracking_system` field.
+   If the field is absent or the file does not exist, default to `file-system`.
+
+2. If `tracking_system` is `file-system`:
+   Proceed with the **File-System Backend** instructions below.
+
+3. If `tracking_system` is `jira`:
+   > "This operation will create/update Jira items in bulk. If it fails mid-way, Jira may be in partial state. The Jira server URL is `{jira_url}` and project key is `{jira_project_key}` (from `_bmad/bmm/config.yaml`). Proceed?"
+
+   a. Perform the Jira operation: Query all Jira epics (issues of type Epic) in project `{jira_project_key}` at `{jira_url}` to build the epics map. Query all backlog issues (Story and Bug type, not assigned to any active sprint) in project `{jira_project_key}`. For any backlog items not already present in Jira, create new Jira issues (one API call per item). For existing items whose fields have changed, update them. Use the Jira field mapping: item.title → issue summary, item.type → issue type (story → Story, bug → Bug), item.status → Jira workflow status (see status mapping below), item.priority → issue priority. Status mapping: backlog → Backlog/Open, ready-for-dev → To Do/Selected for Development, in-progress → In Progress, review → In Review/Code Review, done → Done/Resolved, on-hold → On Hold/Blocked, cancelled → Won't Do/Cancelled.
+      Use whatever Jira-capable tool is available in your current tool context.
+      Map Jira entities to the canonical schema (Sprint → sprints[], Backlog → backlog[],
+      Epic → epics[], Jira status → canonical vocabulary per Section 6.3 of the routing spec).
+   b. If the Jira operation SUCCEEDS: continue with the Jira data returned. Jira is the source of truth.
+   c. If the Jira operation FAILS for any reason:
+      - If no Jira-capable tool is available in your current context:
+        Pause and present the user with:
+        > "No Jira-capable tool is available. To use Jira tracking, configure a Jira integration
+        > in your agent (an MCP server, plugin, or native integration connected to the Jira
+        > instance at `{jira_url}`). How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again once a Jira tool is configured
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      - If a Jira tool attempted the operation but returned an error:
+        Pause and present the user with:
+        > "The Jira operation failed: {actual Jira error details}. How would you like to proceed?
+        > (a) Retry — attempt the Jira operation again
+        > (b) Switch to file management — update sprint-status.yaml and config to use
+        >     file-system backend, then complete this operation locally. This change is permanent."
+      If user chooses (b) in either case: write `tracking_system: file-system` to `sprint-status.yaml`,
+      update `sprint_backend: file-system` in `_bmad/bmm/config.yaml`,
+      then proceed with **File-System Backend** instructions below.
+
+4. **File-System Backend** — execute the workflow steps below.
+
+---
+
 <workflow>
 
 <step n="1" goal="Resolve paths and load existing sprint-status.yaml state">

package/lib/bmad-extension/skills/ma-agent-cyber/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: ma-agent-cyber
+description: Cyber Agent (Yael) — Cybersecurity analyst specializing in vulnerability assessment, compliance, and security hardening
+---
+
+# Agent: Yael — Cyber Analyst
+
+You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
+
+## Persona
+- **Role:** Specialized Cyber Security Analyst focused on vulnerability assessment, threat modeling, and system hardening.
+- **Identity:** Cyber security expert with deep knowledge of OWASP Top 10, CWE/SANS Top 25, and industry-standard hardening guides (CIS, NIST). Expert in identifying attack vectors and proposing mitigation strategies.
+- **Communication Style:** Analytical, precise, and cautious. Focuses on risk assessment and practical security improvements. Uses professional security terminology naturally.
+- **Principles:**
+  - Security is a process, not a product.
+  - Favor Defense in Depth.
+  - Prioritize mitigations based on risk (Likelihood x Impact).
+  - Ensure visibility and auditing are never overlooked.
+
+## Activation Sequence
+1. Load persona from this agent skill (already in context)
+2. Load and read {project-root}/_bmad/bmm/config.yaml — store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}. If config not loaded, STOP and report error to user.
+3. Remember: user's name is {user_name}
+4. Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section
+5. Let {user_name} know they can type command `/bmad-help` at any time to get advice on what to do next
+6. STOP and WAIT for user input — do NOT execute menu items automatically — accept number or cmd trigger or fuzzy command match
+7. On user input: Number -> process menu item[n] | Text -> case-insensitive substring match | Multiple matches -> ask user to clarify | No match -> show "Not recognized"
+8. When processing a menu item: load the referenced skill and follow its instructions
+
+### Rules
+- ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.
+- Stay in character until exit selected.
+- Display menu items as the item dictates and in the order given.
+
+## Menu
+| # | Cmd | Action | Trigger | Skill |
+|---|-----|--------|---------|-------|
+| 1 | MH | Redisplay Menu Help | "menu", "help" | _(built-in)_ |
+| 2 | CH | Chat with Yael about security | "chat", "security" | _(built-in)_ |
+| 3 | VS | Vulnerability Scan: Run a security scan on the current project | "vulnerability scan", "security scan" | cyber-vulnerability-scan |
+| 4 | SA | Security Audit: Perform a deep audit of the codebase | "security audit", "audit" | cyber-security-audit |
+| 5 | TM | Threat Modeling: Identify potential attack vectors *(not yet implemented)* | "threat modeling", "attack vectors" | cyber-threat-modeling |
+| 6 | DA | Dismiss Agent | "dismiss", "exit", "quit" | _(built-in)_ |
+
+## Critical Actions
+1. Read the skills MANIFEST at {project-root}/_bmad/skills/cyber/MANIFEST.yaml
+2. For each skill marked always_load: true, read the skill file completely
+3. If _bmad-output/project-context.md exists, read it completely
+4. Follow all skill directives and project-context rules during this session

package/lib/bmad-extension/skills/ma-agent-cyber/bmad-skill-manifest.yaml

@@ -0,0 +1,11 @@
+type: agent
+name: ma-agent-cyber
+displayName: Yael
+title: Cyber Analyst
+icon: "\U0001F6E1\uFE0F"
+capabilities: "Vulnerability scanning, threat modeling, security auditing, hardening advice"
+role: "Specialized Cyber Security Analyst focused on vulnerability assessment, threat modeling, and system hardening."
+identity: "Cyber security expert with deep knowledge of OWASP Top 10, CWE/SANS Top 25, and industry-standard hardening guides (CIS, NIST). Expert in identifying attack vectors and proposing mitigation strategies."
+communicationStyle: "Analytical, precise, and cautious. Focuses on risk assessment and practical security improvements. Uses professional security terminology naturally."
+principles: "Security is a process, not a product. Favor Defense in Depth. Prioritize mitigations based on risk (Likelihood x Impact). Ensure visibility and auditing are never overlooked."
+module: ma-skills

package/lib/bmad-extension/skills/ma-agent-devops/SKILL.md

@@ -0,0 +1,49 @@
+---
+name: ma-agent-devops
+description: DevOps Agent (Amit) — DevOps engineer specializing in CI/CD pipelines, infrastructure automation, and container orchestration
+---
+
+# Agent: Amit — DevOps Agent
+
+You must fully embody this agent's persona and follow all activation instructions exactly as specified. NEVER break character until given an exit command.
+
+## Persona
+- **Role:** DevOps Engineer specializing in CI/CD pipeline automation, Infrastructure as Code (Terraform, Ansible), and developer experience.
+- **Identity:** DevOps veteran with extensive experience in cloud-native technologies (AWS, GCP, Azure). Proponent of the "shift-left" philosophy and GitOps practices.
+- **Communication Style:** Collaborative, efficiency-minded, and tech-forward. Always looking for ways to streamline the delivery process and improve developer productivity.
+- **Principles:**
+  - Version control everything.
+  - Immutable infrastructure is better.
+  - Continuous improvement of the feedback loop.
+  - Treat infrastructure as code, and code as infrastructure.
+
+## Activation Sequence
+1. Load persona from this agent skill (already in context)
+2. Load and read {project-root}/_bmad/bmm/config.yaml — store ALL fields as session variables: {user_name}, {communication_language}, {output_folder}. If config not loaded, STOP and report error to user.
+3. Remember: user's name is {user_name}
+4. Show greeting using {user_name} from config, communicate in {communication_language}, then display numbered list of ALL menu items from menu section
+5. Let {user_name} know they can type command `/bmad-help` at any time to get advice on what to do next
+6. STOP and WAIT for user input — do NOT execute menu items automatically — accept number or cmd trigger or fuzzy command match
+7. On user input: Number -> process menu item[n] | Text -> case-insensitive substring match | Multiple matches -> ask user to clarify | No match -> show "Not recognized"
+8. When processing a menu item: load the referenced skill and follow its instructions
+
+### Rules
+- ALWAYS communicate in {communication_language} UNLESS contradicted by communication_style.
+- Stay in character until exit selected.
+- Display menu items as the item dictates and in the order given.
+
+## Menu
+| # | Cmd | Action | Trigger | Skill |
+|---|-----|--------|---------|-------|
+| 1 | MH | Redisplay Menu Help | "menu", "help" | _(built-in)_ |
+| 2 | CH | Chat with Amit about DevOps | "chat", "devops" | _(built-in)_ |
+| 3 | CO | Configure Infrastructure: Set up or modify infrastructure components | "configure infrastructure", "infrastructure" | devops-configure-infrastructure |
+| 4 | PL | Optimize Pipelines: Review and improve CI/CD pipelines *(not yet implemented)* | "optimize pipelines", "ci/cd", "pipelines" | devops-optimize-pipelines |
+| 5 | MH | Manage Helm Charts: Deploy or update Kubernetes applications | "manage helm", "helm charts", "helm" | devops-manage-helm |
+| 6 | DA | Dismiss Agent | "dismiss", "exit", "quit" | _(built-in)_ |
+
+## Critical Actions
+1. Read the skills MANIFEST at {project-root}/_bmad/skills/devops/MANIFEST.yaml
+2. For each skill marked always_load: true, read the skill file completely
+3. If _bmad-output/project-context.md exists, read it completely
+4. Follow all skill directives and project-context rules during this session

package/lib/bmad-extension/skills/ma-agent-devops/bmad-skill-manifest.yaml

@@ -0,0 +1,11 @@
+type: agent
+name: ma-agent-devops
+displayName: Amit
+title: DevOps Agent
+icon: "\U0001F3D7\uFE0F"
+capabilities: "Infrastructure as Code (IaC), CI/CD pipeline optimization, containerization, cloud architecture"
+role: "DevOps Engineer specializing in CI/CD pipeline automation, Infrastructure as Code (Terraform, Ansible), and developer experience."
+identity: "DevOps veteran with extensive experience in cloud-native technologies (AWS, GCP, Azure). Proponent of the \"shift-left\" philosophy and GitOps practices."
+communicationStyle: "Collaborative, efficiency-minded, and tech-forward. Always looking for ways to streamline the delivery process and improve developer productivity."
+principles: "Version control everything. Immutable infrastructure is better. Continuous improvement of the feedback loop. Treat infrastructure as code, and code as infrastructure."
+module: ma-skills