ma-agents 3.8.0 → 3.11.0

package/lib/bmad-extension-plugin/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, 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). 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-plugin/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, 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`:
+   > "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-plugin/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, 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 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-plugin/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, 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 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-plugin/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, 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 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-plugin/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, 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`:
+   > "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-plugin/skills/modify-sprint/SKILL.md

@@ -14,6 +14,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-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

@@ -12,6 +12,45 @@ triggers:
 
 Reprioritize backlog items in `sprint-status.yaml` using multiple criteria: severity, business value, dependencies, type, and age.
 
+## 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 backlog issues (not assigned to any sprint) for project `{jira_project_key}` at `{jira_url}`. Apply the prioritization criteria specified by the user. Reorder the issues in the board backlog by updating the issue rank/priority order (use whatever ranking capability is available on the board — NextGen board issue ranking or classic board priority field). Map canonical priority back to Jira fields.
+      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-plugin/skills/remove-from-sprint/SKILL.md

@@ -11,6 +11,45 @@ triggers:
 
 Guided workflow to move sprint items back to the backlog in the unified `sprint-status.yaml` using reverse movement semantics (inverse of `add-to-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 Jira issue matching the item ID in project `{jira_project_key}` at `{jira_url}` (search by issue key or summary). Remove the issue from its current sprint using the "remove issue from sprint" operation, returning it to the board backlog.
+      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-plugin/skills/sprint-status-view/SKILL.md

@@ -16,6 +16,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.js

@@ -752,6 +752,7 @@ async function installBmad(modules = ['bmm', 'bmb'], tools = [], projectRoot = p
         const profile = require('./profile').getProfile(projectRoot);
         await applyOnPremPhasePrefixToDeployedSkills(projectRoot, profile);
         await deployMethodology(projectRoot, force);
+        await deployClineWorkflows(projectRoot, tools);
         postStepsSucceeded = true;
         return true;
     } catch (error) {
@@ -868,6 +869,7 @@ async function runMigration(modules, tools, projectRoot, force, { userName, comm
     await applyOnPremPhasePrefixToDeployedSkills(projectRoot, profile);
 
     await deployMethodology(projectRoot, force);
+    await deployClineWorkflows(projectRoot, tools);
 
     // All migration steps succeeded — safe to clean up the stage now.
     // Cleaning up earlier would remove diagnostics if any of steps 3-4 or
@@ -948,6 +950,7 @@ async function updateBmad(modules = ['bmm', 'bmb'], tools = [], projectRoot = pr
         const profile = require('./profile').getProfile(projectRoot);
         await applyOnPremPhasePrefixToDeployedSkills(projectRoot, profile);
         await deployMethodology(projectRoot, force);
+        await deployClineWorkflows(projectRoot, tools);
         postStepsSucceeded = true;
         return true;
     } catch (error) {
@@ -1113,16 +1116,12 @@ const PERSONA_SKILL_MAP = Object.freeze({
 // agents module into install-time code paths that don't need it. The five
 // IDE tools listed are the only targets that receive `bmad-agent-*` persona
 // skills post-22.6 (verified 2026-04-23 via scratch install).
-// F2b — copilot's skills directory was realigned from `.github/copilot/skills`
-// to `.github/skills` so it matches bmad-method 6.3.0's `github-copilot`
-// platform target_dir. Without this update F1a's prefix pass would walk a
-// directory that no longer receives the persona SKILL.md files.
+// bmad-method 6.5.0 moved copilot, roo, and kilo to the shared .agents/skills/
+// directory. Deduplicated here — F1a walks each unique dir once.
 const TOOL_SKILL_DIRS = Object.freeze([
     path.join('.claude', 'skills'),
-    path.join('.github', 'skills'),
+    path.join('.agents', 'skills'),   // copilot, roo-code, kilocode (bmad-method 6.5.0)
     path.join('.cline', 'skills'),
-    path.join('.roo', 'skills'),
-    path.join('.kilocode', 'skills'),
 ]);
 
 /**
@@ -1373,6 +1372,74 @@ async function deployMethodology(projectRoot = process.cwd(), force = false) {
     console.log(chalk.gray('  Tip: Use /open-presentation to open the slides (install via npx ma-agents install open-presentation)'));
 }
 
+/**
+ * Generate Cline workflow wrappers for all BMAD skills installed to .cline/skills/.
+ * Creates .clinerules/workflows/<skill-name>.md for each installed skill so they
+ * can be invoked via / commands in Cline chat.
+ * No-op when 'cline' is not in the selected tools list.
+ */
+async function deployClineWorkflows(projectRoot, tools = []) {
+    if (!tools.includes('cline')) return;
+
+    const clineSkillsDir = path.join(projectRoot, '.cline', 'skills');
+    if (!(await fs.pathExists(clineSkillsDir))) return;
+
+    const workflowsDir = path.join(projectRoot, '.clinerules', 'workflows');
+    await fs.ensureDir(workflowsDir);
+
+    const entries = await fs.readdir(clineSkillsDir, { withFileTypes: true });
+    const skillDirs = entries.filter(e => e.isDirectory());
+
+    let generated = 0;
+    for (const entry of skillDirs) {
+        const skillName = entry.name;
+        const skillDir = path.join(clineSkillsDir, skillName);
+        const skillMdPath = path.join(skillDir, 'SKILL.md');
+        const workflowMdPath = path.join(skillDir, 'workflow.md');
+
+        if (!(await fs.pathExists(skillMdPath))) continue;
+
+        const skillMdContent = await fs.readFile(skillMdPath, 'utf8');
+        let displayName = skillName.replace(/-/g, ' ').replace(/\b\w/g, c => c.toUpperCase());
+        let description = '';
+
+        const fmMatch = skillMdContent.match(/^---\n([\s\S]*?)\n---/);
+        if (fmMatch) {
+            const fm = fmMatch[1];
+            const nameMatch = fm.match(/^name:\s*(.+)$/m);
+            const descMatch = fm.match(/^description:\s*(.+)$/m);
+            if (nameMatch) displayName = nameMatch[1].trim();
+            if (descMatch) description = descMatch[1].trim().replace(/^['"]|['"]$/g, '');
+        }
+
+        const hasWorkflow = await fs.pathExists(workflowMdPath);
+        const lines = [`# ${displayName}`, ''];
+        if (description) lines.push(description, '');
+
+        if (hasWorkflow) {
+            lines.push(
+                '## Step 1: Read and follow the BMAD skill workflow',
+                `Read the file \`.cline/skills/${skillName}/workflow.md\` and follow all instructions within it exactly.`,
+                ''
+            );
+        } else {
+            lines.push(
+                '## Step 1: Read and follow the BMAD skill instructions',
+                `Read the file \`.cline/skills/${skillName}/SKILL.md\`. Ignore the YAML frontmatter block (the \`---\` delimited section at the top of the file). Follow all instructions in the body of that file exactly.`,
+                ''
+            );
+        }
+
+        await fs.writeFile(path.join(workflowsDir, `${skillName}.md`), lines.join('\n'), 'utf8');
+        generated++;
+    }
+
+    if (generated > 0) {
+        console.log(chalk.green(`  ✓ Generated ${generated} Cline workflow wrappers in .clinerules/workflows/`));
+        console.log(chalk.gray('  Tip: In Cline, type / to browse and invoke BMAD skills'));
+    }
+}
+
 async function prePopulateBmadCache(force = false) {
     const cacheSource = path.join(__dirname, 'bmad-cache');
     if (!(await fs.pathExists(cacheSource))) {
@@ -1531,7 +1598,7 @@ function ensureCanonicalConfigLocation(projectRoot) {
 
 // ── Migration constants ─────────────────────────────────────────────────────
 
-const BMAD_TARGET_VERSION = '6.5.0';
+const BMAD_TARGET_VERSION = '6.6.0';
 const BMAD_MIGRATION_THRESHOLD = '6.2.0'; // versions below this need migration
 const BACKUP_DIR_NAME = '.backup-pre-migration';
 
@@ -2491,6 +2558,7 @@ module.exports = {
     updateBmad,
     prePopulateBmadCache,
     deployMethodology,
+    deployClineWorkflows,
     // Story 22.7 — canonical config (_bmad/bmm/config.yaml) helpers
     readCanonicalBmadConfig,
     ensureCanonicalConfigLocation,

package/lib/installer.js

@@ -1581,7 +1581,12 @@ const OBSOLETE_SKILL_IDS = Object.freeze([...RETIRED_SKILL_IDS, ...RENAMED_SKILL
 const OBSOLETE_TOOL_SKILL_DIRS = Object.freeze([
   // Pre-F2b (PR #70) copilot wrote skills to .github/copilot/skills;
   // F2b realigned the target to .github/skills to match the BMAD upstream path.
-  { obsolete: '.github/copilot/skills', replacedBy: '.github/skills', sinceVersion: '3.7.0' }
+  { obsolete: '.github/copilot/skills', replacedBy: '.github/skills', sinceVersion: '3.7.0' },
+  // bmad-method 6.5.0 moved github-copilot, roo, and kilo platforms from
+  // tool-specific paths to the shared .agents/skills/ directory.
+  { obsolete: '.github/skills', replacedBy: '.agents/skills', sinceVersion: '3.8.1' },
+  { obsolete: '.roo/skills', replacedBy: '.agents/skills', sinceVersion: '3.8.1' },
+  { obsolete: '.kilocode/skills', replacedBy: '.agents/skills', sinceVersion: '3.8.1' }
 ]);
 
 async function migrateRetiredSkills(options = {}) {