ma-agents 3.9.0 → 3.12.0

package/lib/bmad-cache/tea/src/module-help.csv

@@ -1,11 +1,11 @@
 module,skill,display-name,menu-code,description,action,args,phase,after,before,required,output-location,outputs
 Test Architecture Enterprise,_meta,,,,,,,,,false,https://bmad-code-org.github.io/bmad-method-test-architecture-enterprise/llms.txt,
-Test Architecture Enterprise,bmad-teach-me-testing,Teach Me Testing,TMT,Teach testing fundamentals through 7 sessions (TEA Academy).,,0-learning,,,false,test_artifacts,"progress file|session notes|certificate"
-Test Architecture Enterprise,bmad-testarch-test-design,Test Design,TD,Risk-based test planning.,,3-solutioning,,bmad-testarch-framework,false,test_artifacts,test design document
-Test Architecture Enterprise,bmad-testarch-framework,Test Framework,TF,Initialize production-ready test framework.,,3-solutioning,bmad-testarch-test-design,bmad-testarch-ci,false,test_artifacts,framework scaffold
-Test Architecture Enterprise,bmad-testarch-ci,CI Setup,CI,Configure CI/CD quality pipeline.,,3-solutioning,bmad-testarch-framework,,false,test_artifacts,ci config
-Test Architecture Enterprise,bmad-testarch-atdd,ATDD,AT,Generate red-phase acceptance test scaffolds before implementation.,,4-implementation,bmad-create-story:create,bmad-dev-story,false,test_artifacts,"atdd-checklist|red-phase acceptance tests"
-Test Architecture Enterprise,bmad-testarch-automate,Test Automation,TA,Expand test coverage.,,4-implementation,bmad-testarch-atdd,,false,test_artifacts,test suite
-Test Architecture Enterprise,bmad-testarch-test-review,Test Review,RV,Quality audit (0-100 scoring).,,4-implementation,bmad-testarch-automate,,false,test_artifacts,review report
-Test Architecture Enterprise,bmad-testarch-nfr,NFR Assessment,NR,Non-functional requirements assessment.,,4-implementation,bmad-testarch-automate,,false,test_artifacts,nfr report
-Test Architecture Enterprise,bmad-testarch-trace,Traceability,TR,Coverage traceability and gate.,,4-implementation,bmad-testarch-test-review,,false,test_artifacts,"traceability matrix|gate decision"
+Test Architecture Enterprise,bmad-teach-me-testing,Teach Me Testing,TMT,Teach testing fundamentals through 7 sessions (TEA Academy).,,,0-learning,,,false,test_artifacts,progress file|session notes|certificate
+Test Architecture Enterprise,bmad-testarch-test-design,Test Design,TD,Risk-based test planning.,,,3-solutioning,,bmad-testarch-framework,false,test_artifacts,test design document
+Test Architecture Enterprise,bmad-testarch-framework,Test Framework,TF,Initialize production-ready test framework.,,,3-solutioning,bmad-testarch-test-design,bmad-testarch-ci,false,test_artifacts,framework scaffold
+Test Architecture Enterprise,bmad-testarch-ci,CI Setup,CI,Configure CI/CD quality pipeline.,,,3-solutioning,bmad-testarch-framework,,false,test_artifacts,ci config
+Test Architecture Enterprise,bmad-testarch-atdd,ATDD,AT,Generate red-phase acceptance test scaffolds before implementation.,,,4-implementation,bmad-create-story:create,bmad-dev-story,false,test_artifacts,atdd-checklist|red-phase acceptance tests
+Test Architecture Enterprise,bmad-testarch-automate,Test Automation,TA,Expand test coverage.,,,4-implementation,bmad-testarch-atdd,,false,test_artifacts,test suite
+Test Architecture Enterprise,bmad-testarch-test-review,Test Review,RV,Quality audit (0-100 scoring).,,,4-implementation,bmad-testarch-automate,,false,test_artifacts,review report
+Test Architecture Enterprise,bmad-testarch-nfr,NFR Assessment,NR,Non-functional requirements assessment.,,,4-implementation,bmad-testarch-automate,,false,test_artifacts,nfr report
+Test Architecture Enterprise,bmad-testarch-trace,Traceability,TR,Coverage traceability and gate.,,,4-implementation,bmad-testarch-test-review,,false,test_artifacts,traceability matrix|gate decision

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

@@ -2,7 +2,7 @@
   "_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[]).",
+    "Fields follow the v6.6.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."
@@ -39,7 +39,7 @@
     "roo-code",
     "kilocode"
   ],
-  "bmad_min_version": "6.5.0",
+  "bmad_min_version": "6.6.0",
   "plugins": [
     {
       "name": "ma-skills",

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

@@ -16,7 +16,7 @@ Guided workflow to create a new sprint entry in the `sprints` section of `sprint
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -18,7 +18,7 @@ Guided workflow to move backlog items to a sprint in the unified `sprint-status.
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -41,7 +41,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -47,7 +47,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -42,7 +42,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -25,7 +25,7 @@ Keeps the active sprint view lean by archiving completed and cancelled work. Pre
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -18,7 +18,7 @@ Close an active sprint — archive done/cancelled items, disposition incomplete
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -27,7 +27,7 @@ This skill reads `epics.md` and `bug-*.md` files and writes the `backlog` and `e
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -19,7 +19,7 @@ Guided workflow to modify an existing sprint's metadata (name, capacity, dates,
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

package/lib/bmad-extension/skills/module.yaml

@@ -1,4 +1,4 @@
-# ma-skills module manifest (BMAD v6.5.0 schema)
+# ma-skills module manifest (BMAD v6.6.0 schema)
 #
 # Canonical location: `skills/module.yaml` (BMAD 6.2.2+ / 6.3.0). The previous
 # location `lib/bmad-extension/module.yaml` was moved here during Story 22.5.

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

@@ -17,7 +17,7 @@ Reprioritize backlog items in `sprint-status.yaml` using multiple criteria: seve
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

package/lib/bmad-extension/skills/remove-from-sprint/SKILL.md

@@ -16,7 +16,7 @@ Guided workflow to move sprint items back to the backlog in the unified `sprint-
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

package/lib/bmad-extension/skills/sprint-status-view/SKILL.md

@@ -21,7 +21,7 @@ Display a formatted, read-only dashboard of all sprint, backlog, and epic data f
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

package/lib/bmad-extension/workflows/add-sprint/workflow.md

@@ -2,6 +2,45 @@
 
 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, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise 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/workflows/add-to-sprint/workflow.md

@@ -4,6 +4,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, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise 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/workflows/modify-sprint/workflow.md

@@ -5,6 +5,45 @@ Guided workflow to modify an existing sprint's metadata (name, capacity, dates,
 > **Scope:** This skill modifies sprint **metadata only** — name, capacity, start date, end date, and status.
 > To assign items to a sprint, use `/add-to-sprint`. To remove items, use `/remove-from-sprint`.
 
+## 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, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise 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 sprint by name or ID in the board for project `{jira_project_key}` at `{jira_url}`. Update the sprint's name, dates, or goal using the sprint update API. If the status is being changed to `active`: start the sprint using the sprint start API (transitions the sprint from future/planning to active state — enforces the single-active-sprint constraint).
+      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/workflows/sprint-status-view/workflow.md

@@ -6,6 +6,45 @@ Display a formatted, read-only dashboard of all sprint, backlog, and epic data f
 
 ---
 
+## 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, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise 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 sprint data for project `{jira_project_key}` at `{jira_url}`: active sprint with all its issues and their statuses, backlog issues count and list, epic summary and progress. Map Jira sprint states to canonical vocabulary (future → planning, active → active, closed → closed). Map Jira issue statuses to canonical statuses per the status mapping below. Use this data for the display — 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.
+
+---
+
 ## Step 1 — Load sprint-status.yaml
 
 Resolve the path to `sprint-status.yaml` using the BMAD config:

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

@@ -31,13 +31,13 @@
     "roo-code",
     "kilocode"
   ],
-  "bmad_min_version": "6.5.0",
+  "bmad_min_version": "6.6.0",
   "plugins": [
     {
       "name": "ma-skills",
       "source": "./",
       "description": "ma-agents extension module providing enterprise SDLC personas and operational workflow skills.",
-      "version": "3.9.0",
+      "version": "3.12.0",
       "author": {
         "name": "Alon Mayaffit"
       },

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

@@ -16,7 +16,7 @@ Guided workflow to create a new sprint entry in the `sprints` section of `sprint
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -18,7 +18,7 @@ Guided workflow to move backlog items to a sprint in the unified `sprint-status.
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -41,7 +41,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -47,7 +47,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -42,7 +42,7 @@ Load config from `{project-root}/_bmad/bmm/config.yaml` and resolve:
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -25,7 +25,7 @@ Keeps the active sprint view lean by archiving completed and cancelled work. Pre
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -18,7 +18,7 @@ Close an active sprint — archive done/cancelled items, disposition incomplete
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

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

@@ -27,7 +27,7 @@ This skill reads `epics.md` and `bug-*.md` files and writes the `backlog` and `e
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

package/lib/bmad-extension-plugin/skills/modify-sprint/SKILL.md

@@ -19,7 +19,7 @@ Guided workflow to modify an existing sprint's metadata (name, capacity, dates,
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

package/lib/bmad-extension-plugin/skills/module.yaml

@@ -1,4 +1,4 @@
-# ma-skills module manifest (BMAD v6.5.0 schema)
+# ma-skills module manifest (BMAD v6.6.0 schema)
 #
 # Canonical location: `skills/module.yaml` (BMAD 6.2.2+ / 6.3.0). The previous
 # location `lib/bmad-extension/module.yaml` was moved here during Story 22.5.

package/lib/bmad-extension-plugin/skills/prioritize-backlog/SKILL.md

@@ -17,7 +17,7 @@ Reprioritize backlog items in `sprint-status.yaml` using multiple criteria: seve
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

package/lib/bmad-extension-plugin/skills/remove-from-sprint/SKILL.md

@@ -16,7 +16,7 @@ Guided workflow to move sprint items back to the backlog in the unified `sprint-
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.

package/lib/bmad-extension-plugin/skills/sprint-status-view/SKILL.md

@@ -21,7 +21,7 @@ Display a formatted, read-only dashboard of all sprint, backlog, and epic data f
 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`.
+   If the field is absent or the file does not exist, read `sprint_backend` from `_bmad/bmm/config.yaml`. Use that value if present, otherwise default to `file-system`.
 
 2. If `tracking_system` is `file-system`:
    Proceed with the **File-System Backend** instructions below.