Agent skill · bmad-labs
jira-to-local
Use when the user wants Jira issues pulled onto disk as local files — "pull PROJ-123", "fetch this story", "get that ticket locally", "download the bug", "save this issue and its comments", "grab the NFR", "read this ticket offline", or a pasted Jira browse URL with nothing else asked of it. Also for many at once — "sync all tickets in sprint 62", "pull every bug in the sprint", "fetch the whole backlog locally", "download all of team X's issues". Covers any issue type — story, bug, epic, subtask, or whatever types the project has invented for itself. Also when the issue links a Confluence page that should come down with it. This skill only reads: for creating, editing, transitioning, commenting, searching, or pushing anything back to Jira, use atlassian-rest instead.
What it needs
About 10k tokens when loaded.
What this skill does
Pull a Jira issue into a local folder One job: an issue key goes in, a folder of readable files comes out. One issue, one folder, everything in it — fields, comments, subtasks, worklogs, attachments, and any Confluence page the issue links to. <skill-path> below is this skill's directory. The seven rules 1. Pull only. This skill never creates, edits, transitions, comments on, assigns, or deletes anything in Jira. Every request reads: every REST call is a GET, and the one POST is a GraphQL query — the only way to read the deployment list, which no REST endpoint serves. Nothing here mutates anything. If the user wants a write, say so plainly and route to atlassian-rest — do not improvise it here. 2. Config first, and the config records the user's ticks. No .jira.config.json means run workflows/setup.md before anything else. Setup's five decisions — project, issue types, fields per type, board, output — are the user's, and each is settled by a box in a file that setup-choices.mjs generates from the API's own answer. The agent fetches the options and records what the user did — never narrowing a list, summarising it, or marking one option as recommended before they have seen all of it. Only the starting state differs. Project, issue types, board and output arrive unticked, so a tick is the answer. A per-type fields file arrives fully ticked, because its options are the fields that issue type's screen shows — Jira's own answer to what the type holds — so keeping it all is the honest default and the user's job is to untick what they do not want. Either way their edit is the decision, and a fresh file is not one. Setup also records one thing that is not a tick file: which of this site's custom fields fills each metadata row (project.metaFields). Propose that mapping from the field list already on screen, then let the user confirm it. An unmapped row is written —, never guessed. 3. One part per call. fetch-issue.mjs writes one document per run. …
How to use it
Reference it in AdaL, Claude Code, Cursor or any coding agent — nothing to install:
@skills bmad-labs/jira-to-local