ma-agents 3.18.0 → 3.18.1-beta.1

package/bin/cli.js

@@ -159,7 +159,9 @@ ${chalk.bold('Install options:')}
   ${chalk.cyan('--bmad-modules [csv]')} Control BMAD module selection.
                        Bare:    open a multiselect prompt (offers every
                                 bundled module: bmm, tea, bmb, cis)
-                       With CSV: install exactly those (e.g. tea,bmb)
+                       With CSV: install exactly those (e.g. "tea,bmb" —
+                                 quote it: PowerShell splits a bare
+                                 comma list into separate arguments)
                        Omitted: install bmm,tea,bmb,cis (default)
                        'bmm' is always force-included. The design-studio
                        modules gds and wds are not bundled and cannot be
@@ -193,7 +195,7 @@ ${chalk.bold('Examples:')}
   npx ${NAME} install --yes
   npx ${NAME} install --yes --agent claude-code
   npx ${NAME} install --yes --global
-  npx ${NAME} install --yes --bmad-modules bmm,tea,bmb
+  npx ${NAME} install --yes --bmad-modules "bmm,tea,bmb"  # quote the list in PowerShell
   npx ${NAME} install --bmad-modules                    # prompt for modules
   npx ${NAME} install --yes --bmad-custom-source ./org-marketplace
   npx ${NAME} install --bmad-custom-source git@git.intra.example:team/bmad-marketplace.git

package/lib/bmad-cache/cache-manifest.json

@@ -7,18 +7,21 @@
       "url": "https://github.com/bmad-code-org/bmad-method-test-architecture-enterprise",
       "branch": "main",
       "commitSha": "8734d51f24071ddbcb3617390b5fcddb4128ef77",
+      "pinTag": "v1.19.0",
       "clonedAt": "2026-06-13T15:11:39.614Z"
     },
     "bmb": {
       "url": "https://github.com/bmad-code-org/bmad-builder",
       "branch": "main",
       "commitSha": "e6935f2776c34ffd9b18f4ef1e334584ef10a50f",
+      "pinTag": "v2.1.0",
       "clonedAt": "2026-06-27T14:28:16.693Z"
     },
     "cis": {
       "url": "https://github.com/bmad-code-org/bmad-module-creative-intelligence-suite",
       "branch": "main",
       "commitSha": "07a8dd03d196a762f21c241d985293fe5b0f90e7",
+      "pinTag": "v0.2.1",
       "clonedAt": "2026-06-13T15:11:42.507Z"
     }
   }

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

@@ -95,6 +95,7 @@
         "./skills/create-bug-story",
         "./skills/generate-backlog",
         "./skills/modify-sprint",
+        "./skills/my-next-issue",
         "./skills/prioritize-backlog",
         "./skills/project-context-expansion",
         "./skills/remove-from-sprint",

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

@@ -136,6 +136,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -138,6 +138,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -161,6 +161,18 @@ Before executing any status-update operations, determine and route to the correc
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -218,6 +218,18 @@ Before executing any file-system operations, determine and route to the correct
 
    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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -162,6 +162,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -145,6 +145,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -138,6 +138,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -198,6 +198,18 @@ Before executing any file-system operations, determine and route to the correct
 
    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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -139,6 +139,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

package/lib/bmad-extension/skills/module-help.csv

@@ -46,6 +46,7 @@ ma-skills,4-implementation,Sprint Status Health,bmad-sprint-status,,skill:bmad-s
 ma-skills,4-implementation,Cleanup Done,cleanup-done,,skill:cleanup-done,cleanup-done,false,bmm-sm,,"Archive done and cancelled items — remove from sprint-status.yaml and move files to done/ subfolder.",_bmad-output/implementation-artifacts,"archival",
 ma-skills,4-implementation,Close Sprint,close-sprint,,skill:close-sprint,close-sprint,false,bmm-sm,,"Close an active sprint — archive done/cancelled items, disposition incomplete items, set sprint status to closed.",_bmad-output/implementation-artifacts,"sprint plan",
 ma-skills,4-implementation,Prioritize Backlog,prioritize-backlog,,skill:prioritize-backlog,prioritize-backlog,false,bmm-sm,,"Reprioritize backlog items using multiple criteria -- severity, business value, dependencies, type, age.",_bmad-output/implementation-artifacts,"backlog",
+ma-skills,4-implementation,My Next Issue,my-next-issue,,skill:my-next-issue,my-next-issue,false,bmm-sm,,"Return the highest-priority open item assigned to the operating user (Jira: assignee = currentUser()) and answer 'what should I work on next?'.",_bmad-output/implementation-artifacts,"issue selection",
 ma-skills,4-implementation,Project Context Expansion,project-context-expansion,,skill:project-context-expansion,project-context-expansion,false,bmm-sm,,"Post-retrospective companion to update project-context.md with new rules.",_bmad-output,"project context",
 ma-skills,4-implementation,Requirements Quality Audit,sqa-requirements-quality,,skill:sqa-requirements-quality,sqa-requirements-quality,false,bmm-qa,,"Evaluate project requirements against 14 quality criteria — produces a per-requirement audit table, missing-elements section, and overall quality score.",_bmad-output,"quality report",
 ma-skills,anytime,Knowledge Atlas,bmad-knowledge,,skill:bmad-knowledge,bmad-knowledge,false,bmm-sm,,"Generate a self-contained Knowledge Atlas HTML site from project planning and implementation artifacts.",_bmad-output/knowledge-site,"knowledge site",

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

@@ -15,6 +15,6 @@
 code: ma-skills
 name: "MA-Agents Skills & Agents"
 description: "Enterprise methodology enforcement, specialized agents, and operational workflows"
-module_version: "3.7.0"
+module_version: "3.8.0"
 extends-module: bmm
 default_selected: false

package/lib/bmad-extension/skills/my-next-issue/SKILL.md

@@ -0,0 +1,195 @@
+---
+name: my-next-issue
+description: Return the highest-priority open item assigned to the operating user (Jira: assignee = currentUser()) and answer "what should I work on next?"
+type: skill
+triggers:
+  - "my next issue"
+  - "what should I work on"
+  - "most important issue assigned to me"
+  - "/my-next-issue"
+---
+
+# My Next Issue
+
+Answer the question "what should **I** work on next?" — return the single
+highest-priority open item **assigned to the operating user**, with the runners-up
+listed for context.
+
+This is the user-scoped counterpart to `sprint-status-view` (whole board) and
+`prioritize-backlog` (whole backlog reordering). Neither of those filters by
+assignee, so neither can answer this question.
+
+> **READ-ONLY SKILL:** This skill NEVER writes to `sprint-status.yaml`, to Jira, or
+> to any other file. It selects and reports; it does not transition, assign, or
+> reorder anything. To start work on what it returns, hand the item to `bmad-dev-story`.
+
+---
+
+## 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 open issues assigned to the operating user in project `{jira_project_key}` at `{jira_url}` with the JQL
+      `project = {jira_project_key} AND assignee = currentUser() AND statusCategory != Done ORDER BY priority DESC, rank ASC`.
+      Prefer issues in the board's active sprint over backlog issues; within the same
+      scope, rank by the ORDER BY above. Return the top issue plus the next four as
+      runners-up.
+      Use whatever Jira-capable tool is available in your current tool context.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
+      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.
+
+### A note on assignee under the file-system backend
+
+`sprint-status.yaml` has no assignee field, and it does not need one: the file-system
+backend is inherently **single-operator** — whoever owns the working tree owns the
+file. Under this backend the assignee filter is therefore a deliberate no-op, and the
+skill degrades to "the highest-priority item I could pick up next". Do NOT invent an
+assignee field, do NOT read the OS login name, and do NOT ask the user who they are.
+State the degradation once in the output so the answer is not mistaken for a
+user-scoped result on a shared board.
+
+---
+
+<workflow>
+
+<step n="0" goal="Load state">
+  <action>Read `_bmad-output/implementation-artifacts/sprint-status.yaml` — the single source of truth for all sprint and backlog state.</action>
+  <check if="sprint-status.yaml does not exist">
+    <output>No sprint-status.yaml found. Run `bmad-sprint-planning` first to initialize the file.</output>
+    <action>Exit workflow — do not create any file.</action>
+  </check>
+  <action>Parse the `epics`, `backlog` and `sprints` sections. Store as {{file_data}}.</action>
+</step>
+
+<step n="1" goal="Build the candidate set">
+  <action>Collect candidates in this precedence order:
+  1. Items in the **active** sprint (`status: active`) whose item status is `ready-for-dev` or `in-progress`.
+  2. If no sprint is active, or the active sprint yields no candidates: items from `backlog` whose status is `ready-for-dev`.
+  </action>
+  <action>EXCLUDE any item whose status is `done`, `cancelled`, `wont-fix`, `review`, or `on-hold`. An item in `review` is finished work awaiting someone else; an `on-hold`/`blocked` item cannot be started.</action>
+  <action>EXCLUDE any item with an unsatisfied `blocked-on` dependency — that is, any item listing a blocker whose own status is not `done`. Record these separately as {{blocked_items}} so they can be reported rather than silently dropped.</action>
+  <check if="candidate set is empty">
+    <output>
+## Nothing ready to pick up
+
+No item is currently `ready-for-dev` or `in-progress`{{#if active_sprint}} in sprint **{{active_sprint.name}}**{{/if}}.
+
+{{#if blocked_items.length > 0}}
+**{{blocked_items.length}} item(s) are ready but blocked:**
+
+| ID | Title | Blocked on | Blocker status |
+|---|---|---|---|
+{{#each blocked_items}}
+| {{id}} | {{title}} | {{blocked_on}} | {{blocker_status}} |
+{{/each}}
+{{/if}}
+
+**Next steps:**
+- `/add-to-sprint` — pull `ready-for-dev` backlog items into the active sprint
+- `/bmad-create-story` — prepare the next story if the backlog has none ready
+- `/sprint-status-view` — see the whole board
+    </output>
+    <action>Exit workflow.</action>
+  </check>
+</step>
+
+<step n="2" goal="Rank the candidates">
+  <action>Score each candidate with the SAME composite criteria `prioritize-backlog` uses, so the two skills never disagree about what "most important" means:
+  - **Severity:** critical +40, high +30, medium +10, low +5, none +0
+  - **Business value:** the item's existing `priority` value (lower = more important) contributes `max(0, (N - priority + 1) * 2)` where N is the candidate count
+  - **Dependency:** +15 if this item blocks others
+  - **Type:** bug +3, story +0
+  - **Age:** lower-numbered epics get a small starvation-prevention boost
+  </action>
+  <action>Apply two selection rules that outrank the composite score:
+  1. An `in-progress` item always wins over a `ready-for-dev` item — finish what is started before starting more.
+  2. An active-sprint item always wins over a backlog item.
+  </action>
+  <action>Sort by (in-progress first, then active-sprint first, then composite score descending). Break ties by `priority` ascending, then by ID.</action>
+  <action>Store {{top}} = first item, {{runners_up}} = next four.</action>
+</step>
+
+<step n="3" goal="Report">
+  <output>
+## Work on this next
+
+**{{top.id}}** — {{top.title}}
+
+| | |
+|---|---|
+| Type | {{top.type}} |
+| Status | {{top.status}} |
+| Epic | {{#if top.epic}}epic-{{top.epic}}{{else}}—{{/if}} |
+| Severity | {{top.severity or "—"}} |
+| Scope | {{#if top.in_active_sprint}}active sprint — {{active_sprint.name}}{{else}}backlog{{/if}} |
+| Story file | {{top.story_file_path or "not yet created"}} |
+
+**Why this one:** {{top.rationale}}
+
+{{#if runners_up.length > 0}}
+### Next in line
+
+| ID | Title | Type | Status | Why lower |
+|---|---|---|---|---|
+{{#each runners_up}}
+| {{id}} | {{title}} | {{type}} | {{status}} | {{reason}} |
+{{/each}}
+{{/if}}
+
+{{#if blocked_items.length > 0}}
+> **{{blocked_items.length}} item(s) excluded as blocked:** {{blocked_ids_list}}
+{{/if}}
+
+> **Note — file-system backend:** `sprint-status.yaml` tracks no assignee, so this is
+> "the highest-priority item available to pick up", not "the highest-priority item
+> assigned to you". On a Jira-backed project this same skill filters on
+> `assignee = currentUser()`.
+
+**Next steps:**
+- `/bmad-dev-story {{top.id}}` — implement it
+- `/bmad-create-story {{top.id}}` — prepare the story file first, if none exists
+- `/prioritize-backlog` — if this ranking looks wrong
+  </output>
+</step>
+
+</workflow>

package/lib/bmad-extension/skills/my-next-issue/bmad-skill-manifest.yaml

@@ -0,0 +1,3 @@
+type: skill
+name: my-next-issue
+module: ma-skills

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

@@ -186,6 +186,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -136,6 +136,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -141,6 +141,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -127,6 +127,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -129,6 +129,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

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

@@ -130,6 +130,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.

package/lib/bmad-extension/workflows/sprint-status-view/workflow.md

@@ -131,6 +131,18 @@ Before executing any file-system operations, determine and route to the correct
 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.
+      Resolve the operating user from the Jira tool's OWN authenticated identity: in JQL,
+      `assignee = currentUser()`. Jira evaluates `currentUser()` against the credential the
+      tool already holds, so it needs no configuration and never goes stale. Do NOT derive
+      the user from the OS login name and do NOT store a Jira user id in config — a local
+      account name has no defined relation to an Atlassian accountId (it resolves to nothing
+      on Cloud, and can silently resolve to a DIFFERENT person on Server/DC where directory
+      usernames collide).
+      Whenever the request is scoped to the operator — "my issues", "assigned to me", "what
+      should I work on" — add `AND assignee = currentUser()` to the JQL.
+      If `currentUser()` resolves to no user (a shared service-account token), STOP and tell
+      the user that the Jira tool is authenticated as a shared account, so user-scoped
+      queries are unavailable. Do NOT silently widen the query back to whole-project scope.
       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.