Skills › BMAD Method › bmad-agent-po › jira-ticketing.toml
jira-ticketing.toml
83 lines · skills/bmad-agent-po/config/jira-ticketing.toml at bd70c64
1# Store starter: Jira Cloud. `scripts/read_store.py` reads this file as the base layer; the project's
2# _bmad/custom/ticketing-store-config.toml names the store, fills the empty fields below, and replaces
3# any other key here, key by key.
4# It updates with the skill and holds only what is specific to this store: the rules every store shares
5# are in references/board.md. Comments and `description` are never loaded; `description` is for choosing a store.
6#
7# One tool: acli, Atlassian's official CLI (`acli jira workitem ...`): create with --parent, transition,
8# links, comments, assign, JQL. The Atlassian Rovo MCP server (https://mcp.atlassian.com/v1/mcp/authv2)
9# is the alternative for an org that prefers MCP; it has no link-creation tool.
11description = "Jira Cloud through acli: work types, transitions, links, JQL. For teams already on Jira, usually with an admin who can adjust the project workflow."
13[tickets]
14store = "jira"
15key = "" # the default Jira project key, e.g. "SHOP"; Jira assigns the number. A container's own `key` overrides it for everything under it
16site = "" # https://yourorg.atlassian.net
17access = """
18Use acli against `site`. Custom fields go through `--from-json`; check a subcommand's spelling
19with `acli jira workitem --help` before first use.
20"""
22fields = """
23severity is Jira's priority: P0 = Highest, P1 = High, P2 = Medium, P3 = Low; set it at create
24(--priority, or --from-json when the flag is absent) and change it the same way. risk is a label
25risk-low, risk-medium, or risk-high. estimate is the Story Points field on a story and a label est:<value> on an epic, through --from-json. Empty field: default priority, no label.
26"""
28reference = """
29acli creates no web links; the description line is the reference.
30"""
32[verbs]
33setup = """
34Connect, unless acli is already installed and signed in to `site`: install acli (on macOS,
35`brew tap atlassian/homebrew-acli && brew install acli`; elsewhere, per Atlassian's acli install
36guide), then `acli jira auth login --web --site <site>`.
37acli cannot create work types or statuses; those live in the project's settings. At first publish,
38read an existing work item (`acli jira workitem view <key> --json --fields issuetype,status`) and
39the project's work types, compare with [tickets.types] and [tickets.status], and tell the user
40exactly what to add in Jira or which map entry to set in the project's store config. Jira's defaults (To Do, In
41Progress, Done; resolution Won't Do) need no setup; [tickets.status] also expects an In Review status.
42Do not ask for a level above Epic: by default the initiative stays local and everything below it
43publishes. A team-managed project's admin adds a status as a board column under
44Project settings, Board; a company-managed project needs a Jira admin to add it to the workflow.
45"""
47write = """
48The project is the ticket's own `key`, else that of the nearest container above it, else `key` here.
49tracker_id is the work item's key and remote its url.
50Create:
51`acli jira workitem create --project <key> --type <per [tickets.types]> --summary <t>
52--description-file <b> --parent <key> --label <type>[,hitl,risk-<risk>]`, priority per `fields` on
53a bug. Changes: `edit` (body, labels), `assign`, `transition --status <[tickets.status].<state>>` —
54status never moves by edit — `link create --out <blocker> --in <blocked> --type "Blocks"`,
55`comment create`. No parent: omit --parent — the item sits loose in the project. Custom fields go through --from-json; when dropped shares a status with done,
56set the resolution the same way so the two stay distinct.
57Epics sit loose in the project while [tickets.types].initiative is empty. Set that type only when the
58project has a level above Epic; then epics take it as --parent.
59"""
61query = """
62One work item: `acli jira workitem view <key> --json --fields
63key,issuetype,summary,status,assignee,parent,labels,issuelinks,resolution,description`. after is the
64"is blocked by" links; Done with resolution Won't Do is dropped; the description's covers holds the source requirement ids. Children:
65`search --jql "parent = <key>"`. Words: `search --jql 'project = <key> AND text ~ "<words>"'`,
66narrowed by issuetype or status per the maps.
67"""
69# BMad type -> this store's type.
70[tickets.types]
71initiative = "" # empty: the initiative stays local. Jira's default hierarchy is Epic > Story > Subtask; a level above Epic needs Plans (Premium or Enterprise). Set to "Initiative" only when the project has that level.
72epic = "Epic"
73story = "Story"
74spike = "Task" # plus label spike
75bug = "Bug"
77# BMad state -> this store's status.
78[tickets.status]
79backlog = "To Do"
80in-progress = "In Progress"
81review = "In Review" # not a default Jira status; `setup` asks for it. With no review status, set it to the in-progress one
82done = "Done"
83dropped = "Done" # Jira default has no separate status; resolution Won't Do distinguishes it