[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6J0GWP75FWQF0RVPDAGAHB7":3,"skill-same:01M6J0GWP75FWQF0RVPDAGAHB7":67},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":39,"linkOnly":40,"markdownContent":41,"markdownBody":42,"frontMatter":43,"refName":44,"commitSha":45,"skillDirectory":46,"forksCount":47,"repositoryHtmlUrl":48,"repositoryHomepageUrl":6,"ownerHtmlUrl":49,"ownerBlogUrl":50,"ownerDescription":51,"updatedAt":52,"install":53,"resources":66},"01M6J0GWP75FWQF0RVPDAGAHB7","jira-genie",null,"Search, create, edit, and manage Jira issues via jira-genie CLI. Use when the user needs to interact with Jira — find tickets, create tasks, update status, extract templates, or automate workflows. Includes recovery patterns for generic 400 errors, sprint discovery without board permissions, and unattended traceability workflows.","henriquebastos\u002Fjira-genie","henriquebastos","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F12066?v=4","01M6J0GP0PND2FN6YSZKPTX310","Henrique Bastos","01M6J0GP5A11R8ZW4VJXAT5RMM",8,"MIT","https:\u002F\u002Fgithub.com\u002Fhenriquebastos\u002Fjira-genie\u002Fblob\u002Fmain\u002Fskills\u002Fjira-genie\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28,29,30,31,32,33,34,35,36,37,38],"jira genie","jira","genie","discovery","for","errors","traceability","sprint","patterns","edit","automate","cli","search","issues","permissions","update","create","tasks","status","workflows","2026-11-10 10:12:30",false,"---\nname: jira-genie\ndescription: Search, create, edit, and manage Jira issues via jira-genie CLI. Use when the user needs to interact with Jira — find tickets, create tasks, update status, extract templates, or automate workflows. Includes recovery patterns for generic 400 errors, sprint discovery without board permissions, and unattended traceability workflows.\n---\n\n# Jira Genie\n\nOperate Jira Cloud through the `jira` CLI. All commands output JSON to stdout.\n\n## Prerequisites\n\nCheck auth status before any operation:\n\n```bash\njira auth status\n```\n\nIf not logged in:\n\n```bash\njira auth login\n```\n\nCheck if schema is synced (needed for field resolution and completion):\n\n```bash\njira fields list --filter summary\n```\n\nIf empty or missing, sync:\n\n```bash\njira fields sync                      # field list + discover projects\njira fields sync --project DEV        # also sync type schemas for a project\n```\n\n## Agent fast path and recoveries\n\nRead this before choosing commands for unattended workflows:\n\n- Search with `jira search`; do not invent `jira issue list`.\n- If a workflow only needs traceability, create the core issue first and add optional metadata afterward.\n- `--json` is the friendly path for normal use because it resolves names and converts Markdown descriptions. For high-reliability automation, or after any generic 400 with valid-looking `--json`, use a minimal `--raw-payload` create:\n\n  ```bash\n  jira issue create --raw-payload '{\"fields\": {\"project\": {\"key\": \"DEV\"}, \"issuetype\": {\"name\": \"Task\"}, \"summary\": \"Real summary\"}}'\n  ```\n\n- Do not create probe\u002Ftest issues to test schema. The first successful create should be the real ticket.\n- If `jira issue edit --json` or `--set` returns a generic 400 for a valid-looking field, retry that field with `--raw-payload` and the exact Jira API shape. Edit one optional field per command while recovering.\n- For active sprint discovery in automation, prefer JQL: `jira search \"project = DEV AND sprint in openSprints() ORDER BY updated DESC\"`. Board APIs can return 403. Sprint assignment is best-effort.\n- Assignment normally uses `jira issue assign \u003Ckey> \u003Cemail>`; raw accountId edits are fallback.\n- Do not assume `jira issue create --json` can atomically set parent, description, assignee, links, and optional fields. For unattended reliability, create the core issue first, then enrich it one concern at a time.\n- For long or multi-line descriptions, write Markdown to a temp file and use `jira issue edit \u003Ckey> --body-file \u002Ftmp\u002Fdescription.md` after creation. Avoid embedding large descriptions in create JSON during automation.\n- If `jira issue link` returns a `JSONDecodeError`, do not retry blindly. The link may have succeeded while the CLI failed parsing an empty response. Verify with `jira issue get \u003Ckey> --fields issuelinks` first.\n- If a transition is not available, use the statuses printed in the error and walk through the required intermediate state.\n- Markdown bodies (descriptions, comments) are auto-converted to ADF — but **do not nest inline code inside another inline mark** (e.g. `**\\`text\\`**`). The current converter emits `marks=[strong, code]` on a single text node, which Atlassian rejects with a generic HTTP 400. See \"Known issues\" below.\n\n## Searching Issues\n\nUse JQL queries. Always returns a JSON array of formatted issues.\n\n```bash\n# Open issues in a project\njira search \"project = DEV AND status != Done\"\n\n# Current user's work\njira search \"assignee = currentUser() AND status != Done\"\n\n# Children of an epic\njira search \"parent = DEV-100\"\n\n# Current sprint\njira search \"project = DEV AND sprint in openSprints()\"\n\n# With specific fields\njira search \"project = DEV\" --fields summary,status,assignee,parent\n```\n\nThe output is an array of `{key, summary, status, assignee, priority, type}` objects.\n\n**Pagination:** Search returns up to 50 results. For larger result sets, narrow\nthe JQL query (add date ranges, status filters, etc.) rather than expecting all\nresults at once.\n\n## Reading Issues\n\n```bash\n# Formatted (clean JSON)\njira issue get DEV-123\n\n# Specific fields only\njira issue get DEV-123 --fields summary,status,parent,components\n\n# Raw API response (all fields, nested structure)\njira issue get DEV-123 --raw\n```\n\nUse `--raw` when you need fields not in the default format (description, comments,\ncustom fields, sprint info).\n\n## Creating Issues\n\n### From JSON with friendly names\n\n```bash\njira issue create --json '{\n  \"project\": \"DEV\",\n  \"issuetype\": \"Task\",\n  \"summary\": \"Implement feature X\",\n  \"parent\": \"DEV-100\",\n  \"priority\": \"P2: Medium\",\n  \"components\": [\"API\"],\n  \"labels\": [\"backend\"]\n}'\n```\n\nField names are resolved automatically: `story_points` → `customfield_10036`,\n`team` → `customfield_10001`, etc.\n\nReturns: `{\"id\": \"12345\", \"key\": \"DEV-125\", \"self\": \"https:\u002F\u002F...\"}`.\n\n### Setting descriptions\n\nDescriptions accept **Markdown** — it's auto-converted to Atlassian Document Format (ADF):\n\n```bash\njira issue create --json '{\n  \"project\": \"DEV\",\n  \"issuetype\": \"Task\",\n  \"summary\": \"Fix the auth flow\",\n  \"description\": \"## Problem\\n\\nUsers are getting **401 errors** after token refresh.\\n\\n## Steps to reproduce\\n\\n1. Login normally\\n2. Wait for token expiry\\n3. Try any API call\\n\\n## Notes\\n\\n- Affects `PaymentService`\\n- See [docs](https:\u002F\u002Fexample.com\u002Fauth)\"\n}'\n```\n\nSupported Markdown elements:\n- Headings (`#` through `######`)\n- Bold (`**text**`), italic (`*text*`), inline code (`` `text` ``), strikethrough (`~~text~~`)\n- Links (`[text](url)`)\n- Bullet lists (`- item`) and ordered lists (`1. item`), including nested\n- Code blocks (` ```language `)\n- Blockquotes (`> text`)\n- Horizontal rules (`---`)\n\nPlain text works too — it becomes a single paragraph.\n\n> **Caveat (see Known issues):** ADF rejects the `code` mark combined with any other inline mark. Avoid `**\\`code\\`**`, `*\\`code\\`*`, and `[\\`code\\`](url)` in Markdown bodies. Use a fenced code block, or split the formatting (e.g. `**See** \\`code\\`).\n\nFor pre-built ADF (rare), pass a dict — it goes through untouched:\n\n```bash\njira issue create --json '{\n  \"description\": {\"type\": \"doc\", \"version\": 1, \"content\": [...]}\n}'\n```\n\nThe same applies to the `environment` field.\n\n### With a template\n\nTemplates provide defaults. Only specify what varies:\n\n```bash\njira issue create --template backend --summary \"Fix the race condition\"\n```\n\nBefore using a template with a `parent`, verify the parent is still the right\nactive epic:\n\n```bash\njira template show backend\njira issue get DEV-100 --fields summary,status,components\n```\n\nIf the parent is closed or stale, search for the active epic before creating the\nticket:\n\n```bash\njira search \"project = DEV AND issuetype = Epic AND component = 'SomeTeam' AND status != Closed ORDER BY updated DESC\" --fields summary,status,components\njira search \"project = DEV AND issuetype = Epic AND summary ~ 'SomeProject' ORDER BY updated DESC\" --fields summary,status,components\n```\n\nOverride template fields:\n\n```bash\njira issue create --template backend --json '{\"parent\": \"DEV-200\"}' --summary \"Different epic\"\n```\n\nComposition order (later overrides earlier):\n\n```\ntemplate → --json → --set\u002F--summary → resolved → API\n```\n\n### With --set flags\n\n```bash\njira issue create --json '{\"project\": \"DEV\", \"issuetype\": \"Task\"}' \\\n  --summary \"Quick task\" \\\n  --set parent=DEV-100 \\\n  --set priority=\"P1: High\"\n```\n\n### With --body-file (long description)\n\nWhen the description is too large to fit comfortably on the command line, write it to a Markdown file first:\n\n```bash\njira issue create --json '{\"project\": \"DEV\", \"issuetype\": \"Task\"}' \\\n  --summary \"Fix the bug\" \\\n  --body-file \u002Ftmp\u002Fdescription.md\n```\n\nThe file contents are loaded into the `description` field and Markdown-to-ADF conversion runs as usual.\n\n### Reliable minimal create \u002F raw payload\n\n`--json` is preferred for normal interactive use. Use `--raw-payload` when a workflow must not be blocked by field resolution, when templates contain fields you need to omit, or when `jira issue create --json` returns a generic 400 despite valid-looking fields.\n\nCreate the core issue with only required fields first:\n\n```bash\njira issue create --raw-payload '{\"fields\": {\"project\": {\"key\": \"DEV\"}, \"issuetype\": {\"name\": \"Task\"}, \"summary\": \"Create the ticket\"}}'\n```\n\nPrefer stable ids if friendly keys\u002Fnames fail:\n\n```bash\njira issue get DEV-123 --raw | jq '.fields.project, .fields.issuetype'\njira issue create --raw-payload '{\n  \"fields\": {\n    \"project\": {\"id\": \"\u003Cproject_id>\"},\n    \"issuetype\": {\"id\": \"\u003Cissuetype_id>\"},\n    \"summary\": \"Create the ticket\"\n  }\n}'\n```\n\nAfter raw creation, fill description and optional fields with `jira issue edit`. This keeps core ticket creation unblocked even when one template field or resolved field is bad.\n\n### Reliable create\u002Fenrich\u002Flink sequence\n\nFor unattended creation with any optional metadata, use separate steps. This avoids losing the whole create to a generic 400 from one optional field and makes recovery deterministic.\n\n```bash\n# 1. If copying context from an existing issue, inspect it first.\njira issue get DEV-123 --fields summary,status,assignee,parent,issuetype\n\n# 2. Create the real issue with only stable required\u002Fcore fields.\njira issue create --raw-payload '{\"fields\":{\"project\":{\"key\":\"DEV\"},\"issuetype\":{\"name\":\"Task\"},\"parent\":{\"key\":\"DEV-EPIC\"},\"summary\":\"Issue summary\"}}'\n\n# 3. Add long descriptions separately from a temp Markdown file.\ncat > \u002Ftmp\u002Fdev-new-description.md \u003C\u003C'EOF'\nDescription in Markdown.\nEOF\njira issue edit DEV-NEW --body-file \u002Ftmp\u002Fdev-new-description.md\n\n# 4. Assign explicitly if needed.\njira user me\njira issue assign DEV-NEW user@example.com\n\n# 5. Link separately if needed. If this reports JSONDecodeError, verify before retrying.\njira issue link --type Relates DEV-NEW DEV-123\njira issue get DEV-NEW --fields issuelinks\n```\n\nUse this sequence for follow-ups, traceability tickets, and any create where parent\u002Fdescription\u002Fassignment\u002Flinks\u002Foptional fields are involved. The first successful create should always be the real issue, not a probe.\n\n## Extracting Templates from Existing Tickets\n\nWhen the user wants a template based on how they already create tickets:\n\n### Step 1: Find representative tickets\n\n```bash\njira search \"reporter = currentUser() AND type = Task ORDER BY created DESC\" --fields summary,parent,components,labels,priority\n```\n\n### Step 2: Inspect fields and schema\n\n```bash\n# Look at a real ticket's fields\njira issue get DEV-123 --raw\n\n# Check all available fields for that type (required fields, allowed values)\njira fields schema --project DEV --type Task\n```\n\nLook at the fields that are consistent across tickets (project, issuetype, parent,\ncomponents, labels) — these become the template. Ignore fields that vary per ticket\n(summary, description).\n\n### Step 3: Create the template\n\nExtract the common fields into a template:\n\n```bash\njira template create my-template --json '{\n  \"project\": \"DEV\",\n  \"issuetype\": \"Task\",\n  \"parent\": \"DEV-100\",\n  \"components\": [\"API\"]\n}'\n```\n\n### Step 4: Verify\n\n```bash\njira template show my-template\n```\n\n## Managing Templates\n\n```bash\njira template list                    # all templates\njira template show backend            # view one\njira template create NAME --json '{}'  # create\njira template delete NAME             # remove\n\njira template default backend         # set as default\njira template default                 # show current default\njira template default --clear         # remove default\n```\n\nWhen a default is set, `jira issue create --summary \"...\"` uses it automatically.\n\nThere is no reliable non-interactive JSON edit flow for templates. To replace a\nstale template, create a new one, set it as default, verify, then delete the old\none:\n\n```bash\njira template create someproject-new --json '{\"project\":\"DEV\",\"issuetype\":\"Task\",\"parent\":\"DEV-100\",\"components\":[\"SomeTeam\"]}'\njira template default someproject-new\njira template show someproject-new\njira template delete someproject-old\n```\n\n## Editing Issues\n\n```bash\n# Set individual fields\njira issue edit DEV-123 --set priority=\"P1: High\" --set story_points=5\n\n# JSON override; useful for Markdown description because it converts to ADF\njira issue edit DEV-123 --json '{\"description\": \"## Updated analysis\\n\\nThe root cause is...\"}'\njira issue edit DEV-123 --json '{\"team\": \"Backend\", \"labels\": [\"urgent\"]}'\n\n# Set description directly (accepts Markdown — same converter, same caveat about nested code marks)\njira issue edit DEV-123 --description \"## Updated\\n\\nNew description\"\n\n# Read description from file (avoids shell-escaping pain for long Markdown)\njira issue edit DEV-123 --body-file \u002Ftmp\u002Fdescription.md\n\n# Raw payload; bypasses field\u002Fvalue resolution and sends exact Jira API JSON\njira issue edit DEV-123 --raw-payload '{\"fields\": {\"summary\": \"Updated title\"}}'\n```\n\nIf `--set` or `--json` returns a generic 400 even though the field\u002Fvalue looks valid, retry with `--raw-payload`. Apply one optional field per request while recovering so one bad field does not block the rest:\n\n```bash\njira issue edit DEV-123 --raw-payload '{\"fields\": {\"components\": [{\"name\": \"SomeTeam\"}]}}'\njira issue edit DEV-123 --raw-payload '{\"fields\": {\"customfield_10008\": [\u003Csprint_id>]}}'\njira issue edit DEV-123 --raw-payload '{\"fields\": {\"\u003Ccustomfield_id>\": \"\u003Cvalue>\"}}'\n```\n\nUse `jira fields list --filter \u003Ckeyword>` or `jira fields schema --project DEV --type Task` to find custom field ids and allowed values.\n\n## Workflow Operations\n\n```bash\n# Transition status\njira issue transition DEV-123 \"In Progress\"\njira issue transition DEV-123 \"Done\"\n\n# Assign\njira issue assign DEV-123 alice@example.com\n\n# Comment\njira issue comment DEV-123 \"Fixed in commit abc1234\"\n\n# Link issues (--type values: \"blocks\", \"is blocked by\", \"relates to\", \"duplicates\", \"is duplicated by\", \"clones\", \"is cloned by\")\njira issue link DEV-123 DEV-456 --type blocks\n```\n\nIf the target status is not currently available, the CLI error lists available\ntransitions. Walk through the required intermediate statuses, for example:\n\n```bash\njira issue transition DEV-123 \"In Progress\"\njira issue transition DEV-123 \"In Review\"\n```\n\n## Bulk Operations\n\nOnly bulk edit is supported. Use it to update the same field(s) across multiple issues:\n\n```bash\njira bulk edit DEV-1 DEV-2 DEV-3 --set parent=DEV-100\njira bulk edit DEV-1 DEV-2 --set priority=\"P1: High\"\njira bulk edit DEV-1 DEV-2 --json '{\"team\": \"Backend\"}'\n```\n\nFor bulk creation or transitions, loop over individual commands.\n\n## Schema Inspection\n\nUse these to discover what fields and values are available:\n\n```bash\n# All fields with their IDs and types\njira fields list\n\n# Search for a field by name\njira fields list --filter story\n\n# Full schema for a project + issue type (required fields, allowed values)\njira fields schema --project DEV --type Task\n```\n\nThe schema output tells you exactly what to pass when creating or editing issues.\n\n## Sprints and Boards\n\nFor active sprint discovery in automation, prefer JQL first because board APIs may return 403:\n\n```bash\njira search \"project = DEV AND sprint in openSprints() ORDER BY updated DESC\" --fields key,summary,status,assignee,sprint\n```\n\nIf you need the raw sprint id, inspect an issue already in the active sprint:\n\n```bash\njira issue get DEV-123 --raw | jq '.fields.customfield_10008'\n```\n\nSprint assignment is best-effort. If setting the sprint field returns 400, do not block a traceability workflow whose required end state is ticket, assignee, status, and PR linkage. If sprint assignment is still desired, use raw payload with the exact sprint custom field shape for the project:\n\n```bash\njira issue edit DEV-123 --raw-payload '{\"fields\": {\"customfield_10008\": [\u003Csprint_id>]}}'\n```\n\nUse board APIs only when you specifically need board\u002Fbacklog operations and permissions allow them:\n\n```bash\njira board list --project DEV\njira sprint current --board 42\njira sprint list --board 42 --state active,future\njira sprint issues 123 --fields summary,status,assignee\njira board backlog 42\n```\n\n## Users\n\n```bash\njira user me                # current user\njira user search \"alice\"    # find users\n```\n\n## Error Handling\n\nAll errors output structured JSON to stderr:\n\n```json\n{\"error\": \"404 Client Error: Not Found for url: ...\", \"type\": \"HTTPError\"}\n```\n\nParse the `error` and `type` fields to decide how to recover. When a command fails, read the error message and recover:\n\n- **Field validation error** on create\u002Fedit → check required fields and allowed values:\n  ```bash\n  jira fields schema --project DEV --type Task\n  ```\n- **Generic 400 on create\u002Fedit with valid-looking `--json` or `--set`** → retry with `--raw-payload` using exact Jira API field shapes. For creates, create the minimal core issue first, then edit optional fields afterward. For edits, set one optional field per request while recovering.\n- **Generic 400 when posting a comment \u002F description from Markdown** → check whether the Markdown contains nested inline marks like `**\\`code\\`**`, `*\\`code\\`*`, or `[\\`code\\`](url)`. The converter emits invalid ADF for those and Atlassian rejects the document. Workaround: use a fenced code block, or split the formatting (`**See** \\`code\\` here`).\n- **Template create fails or creates tickets under old work** → inspect the\n  template with `jira template show`, verify its `parent` issue status, and\n  replace the template if the parent is stale.\n- **Unknown field name** → list available fields and find the correct name:\n  ```bash\n  jira fields list --filter \u003Ckeyword>\n  ```\n- **Invalid transition** → the issue's current status may not allow that transition.\n  Use the available statuses printed in the error and transition through the\n  appropriate intermediate state.\n- **Permission denied \u002F 403** → the authenticated user lacks permission for that\n  project or operation. Verify with `jira auth status` and `jira user me`. If\n  board\u002Fsprint APIs are forbidden, use JQL search fallbacks.\n- **Invalid JQL** → simplify the query, check field names and function syntax.\n\n## Field Resolution Reference\n\nWhen using `--json` or `--set`, field names and values are resolved automatically:\n\n| You write | API receives |\n|-----------|-------------|\n| `\"project\": \"DEV\"` | `\"project\": {\"key\": \"DEV\"}` |\n| `\"issuetype\": \"Task\"` | `\"issuetype\": {\"name\": \"Task\"}` |\n| `\"parent\": \"DEV-100\"` | `\"parent\": {\"key\": \"DEV-100\"}` |\n| `\"priority\": \"P1: High\"` | `\"priority\": {\"name\": \"P1: High\"}` |\n| `\"team\": \"Backend\"` | `\"customfield_10001\": {\"value\": \"Backend\"}` |\n| `\"components\": [\"API\"]` | `\"components\": [{\"name\": \"API\"}]` |\n| `\"story_points\": 5` | `\"customfield_10036\": 5` |\n| `\"description\": \"**Markdown** text\"` | parsed as Markdown, converted to ADF |\n| `\"description\": {ADF doc}` | passed through as-is (dicts are never wrapped) |\n\nUse `--raw-payload` to bypass all resolution and send exact JSON to the API.\n\n## Known issues\n\n### Markdown → ADF: nested inline code marks produce invalid ADF (HTTP 400)\n\nWhen Markdown contains an inline code span nested inside another inline mark, the converter emits a single text node with two marks (e.g. `marks=[strong, code]`). ADF's schema does not allow the `code` mark to combine with any other inline mark, so Atlassian rejects the document with a generic `400 Bad Request`.\n\nTriggers (all produce HTTP 400 from the comment \u002F description endpoints):\n\n- `**\\`foo.py\\`**` (bold around inline code)\n- `*\\`foo.py\\`*` (italic around inline code)\n- `[\\`foo.py\\`](url)` (link around inline code)\n- Any sentence-level bold that contains inline code as a child: `**See \\`foo.py\\` here**`\n\nSafe alternatives:\n\n- Plain inline code: `` `foo.py` `` — fine, even with quotes\u002Fbraces\u002Fparens inside (`` `os.system(f\"echo {x}\")` `` is OK).\n- Fenced code block — fine for any language and any content.\n- Bold of plain text: `**foo.py**` — fine.\n- Split the formatting at the boundary: `**See** \\`foo.py\\` **here**`.\n\nQuick local repro (run with the jira-genie tool's interpreter):\n\n```python\nfrom jira_genie.adf import markdown_to_adf\nadf = markdown_to_adf(\"Bad: **`foo.py`**\")\n# Walk to a text node and you'll see marks=[strong, code] — invalid per ADF schema.\n```\n\n## Common Agent Patterns\n\n### Gather context before working\n\n```bash\njira issue get DEV-123\njira search \"parent = DEV-123\" --fields summary,status\n```\n\n### Update a ticket's description\n\nUse `jira issue edit` with `--description` (short Markdown), `--body-file` (long Markdown), or `--json` (Markdown inside a JSON payload):\n\n```bash\n# Short description inline\njira issue edit DEV-123 --description \"## Updated analysis\\n\\nThe root cause is...\"\n\n# Long description from file (avoids shell-escaping pain)\njira issue edit DEV-123 --body-file \u002Ftmp\u002Fdescription.md\n\n# Or via --json (when you want to set description alongside other fields)\njira issue edit DEV-123 --json '{\"description\": \"## Updated analysis\\n\\nThe root cause is...\"}'\n```\n\nFor long descriptions assembled in shell, write to a file first, then use one of the above:\n\n```bash\ncat > \u002Ftmp\u002Fdesc.md \u003C\u003C 'EOF'\n## Full analysis\n\nDetailed description here...\nEOF\njira issue edit DEV-123 --body-file \u002Ftmp\u002Fdesc.md\n```\n\n### Add a comment\n\n```bash\n# Short comment\njira issue comment DEV-123 \"Fixed in commit abc1234\"\n\n# Long comment from file\njira issue comment DEV-123 --body-file \u002Ftmp\u002Fanalysis.md\n```\n\nComments accept Markdown — it's auto-converted to Atlassian Document Format. Same caveat as descriptions: avoid nested inline code marks (see Known issues).\n\n### Create task, do work, close\n\n```bash\njira issue create --template backend --summary \"Fix the bug\"\n# ... do the work ...\njira issue transition DEV-124 \"In Progress\"\njira issue comment DEV-124 \"Working on it\"\n# ... finish ...\njira issue transition DEV-124 \"Done\"\njira issue comment DEV-124 \"Fixed in commit abc1234\"\n```\n\n### Discover and report\n\n```bash\njira search \"project = DEV AND sprint in openSprints() AND status = 'To Do'\" --fields summary,assignee,priority\n```\n","# Jira Genie\n\nOperate Jira Cloud through the `jira` CLI. All commands output JSON to stdout.\n\n## Prerequisites\n\nCheck auth status before any operation:\n\n```bash\njira auth status\n```\n\nIf not logged in:\n\n```bash\njira auth login\n```\n\nCheck if schema is synced (needed for field resolution and completion):\n\n```bash\njira fields list --filter summary\n```\n\nIf empty or missing, sync:\n\n```bash\njira fields sync                      # field list + discover projects\njira fields sync --project DEV        # also sync type schemas for a project\n```\n\n## Agent fast path and recoveries\n\nRead this before choosing commands for unattended workflows:\n\n- Search with `jira search`; do not invent `jira issue list`.\n- If a workflow only needs traceability, create the core issue first and add optional metadata afterward.\n- `--json` is the friendly path for normal use because it resolves names and converts Markdown descriptions. For high-reliability automation, or after any generic 400 with valid-looking `--json`, use a minimal `--raw-payload` create:\n\n  ```bash\n  jira issue create --raw-payload '{\"fields\": {\"project\": {\"key\": \"DEV\"}, \"issuetype\": {\"name\": \"Task\"}, \"summary\": \"Real summary\"}}'\n  ```\n\n- Do not create probe\u002Ftest issues to test schema. The first successful create should be the real ticket.\n- If `jira issue edit --json` or `--set` returns a generic 400 for a valid-looking field, retry that field with `--raw-payload` and the exact Jira API shape. Edit one optional field per command while recovering.\n- For active sprint discovery in automation, prefer JQL: `jira search \"project = DEV AND sprint in openSprints() ORDER BY updated DESC\"`. Board APIs can return 403. Sprint assignment is best-effort.\n- Assignment normally uses `jira issue assign \u003Ckey> \u003Cemail>`; raw accountId edits are fallback.\n- Do not assume `jira issue create --json` can atomically set parent, description, assignee, links, and optional fields. For unattended reliability, create the core issue first, then enrich it one concern at a time.\n- For long or multi-line descriptions, write Markdown to a temp file and use `jira issue edit \u003Ckey> --body-file \u002Ftmp\u002Fdescription.md` after creation. Avoid embedding large descriptions in create JSON during automation.\n- If `jira issue link` returns a `JSONDecodeError`, do not retry blindly. The link may have succeeded while the CLI failed parsing an empty response. Verify with `jira issue get \u003Ckey> --fields issuelinks` first.\n- If a transition is not available, use the statuses printed in the error and walk through the required intermediate state.\n- Markdown bodies (descriptions, comments) are auto-converted to ADF — but **do not nest inline code inside another inline mark** (e.g. `**\\`text\\`**`). The current converter emits `marks=[strong, code]` on a single text node, which Atlassian rejects with a generic HTTP 400. See \"Known issues\" below.\n\n## Searching Issues\n\nUse JQL queries. Always returns a JSON array of formatted issues.\n\n```bash\n# Open issues in a project\njira search \"project = DEV AND status != Done\"\n\n# Current user's work\njira search \"assignee = currentUser() AND status != Done\"\n\n# Children of an epic\njira search \"parent = DEV-100\"\n\n# Current sprint\njira search \"project = DEV AND sprint in openSprints()\"\n\n# With specific fields\njira search \"project = DEV\" --fields summary,status,assignee,parent\n```\n\nThe output is an array of `{key, summary, status, assignee, priority, type}` objects.\n\n**Pagination:** Search returns up to 50 results. For larger result sets, narrow\nthe JQL query (add date ranges, status filters, etc.) rather than expecting all\nresults at once.\n\n## Reading Issues\n\n```bash\n# Formatted (clean JSON)\njira issue get DEV-123\n\n# Specific fields only\njira issue get DEV-123 --fields summary,status,parent,components\n\n# Raw API response (all fields, nested structure)\njira issue get DEV-123 --raw\n```\n\nUse `--raw` when you need fields not in the default format (description, comments,\ncustom fields, sprint info).\n\n## Creating Issues\n\n### From JSON with friendly names\n\n```bash\njira issue create --json '{\n  \"project\": \"DEV\",\n  \"issuetype\": \"Task\",\n  \"summary\": \"Implement feature X\",\n  \"parent\": \"DEV-100\",\n  \"priority\": \"P2: Medium\",\n  \"components\": [\"API\"],\n  \"labels\": [\"backend\"]\n}'\n```\n\nField names are resolved automatically: `story_points` → `customfield_10036`,\n`team` → `customfield_10001`, etc.\n\nReturns: `{\"id\": \"12345\", \"key\": \"DEV-125\", \"self\": \"https:\u002F\u002F...\"}`.\n\n### Setting descriptions\n\nDescriptions accept **Markdown** — it's auto-converted to Atlassian Document Format (ADF):\n\n```bash\njira issue create --json '{\n  \"project\": \"DEV\",\n  \"issuetype\": \"Task\",\n  \"summary\": \"Fix the auth flow\",\n  \"description\": \"## Problem\\n\\nUsers are getting **401 errors** after token refresh.\\n\\n## Steps to reproduce\\n\\n1. Login normally\\n2. Wait for token expiry\\n3. Try any API call\\n\\n## Notes\\n\\n- Affects `PaymentService`\\n- See [docs](https:\u002F\u002Fexample.com\u002Fauth)\"\n}'\n```\n\nSupported Markdown elements:\n- Headings (`#` through `######`)\n- Bold (`**text**`), italic (`*text*`), inline code (`` `text` ``), strikethrough (`~~text~~`)\n- Links (`[text](url)`)\n- Bullet lists (`- item`) and ordered lists (`1. item`), including nested\n- Code blocks (` ```language `)\n- Blockquotes (`> text`)\n- Horizontal rules (`---`)\n\nPlain text works too — it becomes a single paragraph.\n\n> **Caveat (see Known issues):** ADF rejects the `code` mark combined with any other inline mark. Avoid `**\\`code\\`**`, `*\\`code\\`*`, and `[\\`code\\`](url)` in Markdown bodies. Use a fenced code block, or split the formatting (e.g. `**See** \\`code\\`).\n\nFor pre-built ADF (rare), pass a dict — it goes through untouched:\n\n```bash\njira issue create --json '{\n  \"description\": {\"type\": \"doc\", \"version\": 1, \"content\": [...]}\n}'\n```\n\nThe same applies to the `environment` field.\n\n### With a template\n\nTemplates provide defaults. Only specify what varies:\n\n```bash\njira issue create --template backend --summary \"Fix the race condition\"\n```\n\nBefore using a template with a `parent`, verify the parent is still the right\nactive epic:\n\n```bash\njira template show backend\njira issue get DEV-100 --fields summary,status,components\n```\n\nIf the parent is closed or stale, search for the active epic before creating the\nticket:\n\n```bash\njira search \"project = DEV AND issuetype = Epic AND component = 'SomeTeam' AND status != Closed ORDER BY updated DESC\" --fields summary,status,components\njira search \"project = DEV AND issuetype = Epic AND summary ~ 'SomeProject' ORDER BY updated DESC\" --fields summary,status,components\n```\n\nOverride template fields:\n\n```bash\njira issue create --template backend --json '{\"parent\": \"DEV-200\"}' --summary \"Different epic\"\n```\n\nComposition order (later overrides earlier):\n\n```\ntemplate → --json → --set\u002F--summary → resolved → API\n```\n\n### With --set flags\n\n```bash\njira issue create --json '{\"project\": \"DEV\", \"issuetype\": \"Task\"}' \\\n  --summary \"Quick task\" \\\n  --set parent=DEV-100 \\\n  --set priority=\"P1: High\"\n```\n\n### With --body-file (long description)\n\nWhen the description is too large to fit comfortably on the command line, write it to a Markdown file first:\n\n```bash\njira issue create --json '{\"project\": \"DEV\", \"issuetype\": \"Task\"}' \\\n  --summary \"Fix the bug\" \\\n  --body-file \u002Ftmp\u002Fdescription.md\n```\n\nThe file contents are loaded into the `description` field and Markdown-to-ADF conversion runs as usual.\n\n### Reliable minimal create \u002F raw payload\n\n`--json` is preferred for normal interactive use. Use `--raw-payload` when a workflow must not be blocked by field resolution, when templates contain fields you need to omit, or when `jira issue create --json` returns a generic 400 despite valid-looking fields.\n\nCreate the core issue with only required fields first:\n\n```bash\njira issue create --raw-payload '{\"fields\": {\"project\": {\"key\": \"DEV\"}, \"issuetype\": {\"name\": \"Task\"}, \"summary\": \"Create the ticket\"}}'\n```\n\nPrefer stable ids if friendly keys\u002Fnames fail:\n\n```bash\njira issue get DEV-123 --raw | jq '.fields.project, .fields.issuetype'\njira issue create --raw-payload '{\n  \"fields\": {\n    \"project\": {\"id\": \"\u003Cproject_id>\"},\n    \"issuetype\": {\"id\": \"\u003Cissuetype_id>\"},\n    \"summary\": \"Create the ticket\"\n  }\n}'\n```\n\nAfter raw creation, fill description and optional fields with `jira issue edit`. This keeps core ticket creation unblocked even when one template field or resolved field is bad.\n\n### Reliable create\u002Fenrich\u002Flink sequence\n\nFor unattended creation with any optional metadata, use separate steps. This avoids losing the whole create to a generic 400 from one optional field and makes recovery deterministic.\n\n```bash\n# 1. If copying context from an existing issue, inspect it first.\njira issue get DEV-123 --fields summary,status,assignee,parent,issuetype\n\n# 2. Create the real issue with only stable required\u002Fcore fields.\njira issue create --raw-payload '{\"fields\":{\"project\":{\"key\":\"DEV\"},\"issuetype\":{\"name\":\"Task\"},\"parent\":{\"key\":\"DEV-EPIC\"},\"summary\":\"Issue summary\"}}'\n\n# 3. Add long descriptions separately from a temp Markdown file.\ncat > \u002Ftmp\u002Fdev-new-description.md \u003C\u003C'EOF'\nDescription in Markdown.\nEOF\njira issue edit DEV-NEW --body-file \u002Ftmp\u002Fdev-new-description.md\n\n# 4. Assign explicitly if needed.\njira user me\njira issue assign DEV-NEW user@example.com\n\n# 5. Link separately if needed. If this reports JSONDecodeError, verify before retrying.\njira issue link --type Relates DEV-NEW DEV-123\njira issue get DEV-NEW --fields issuelinks\n```\n\nUse this sequence for follow-ups, traceability tickets, and any create where parent\u002Fdescription\u002Fassignment\u002Flinks\u002Foptional fields are involved. The first successful create should always be the real issue, not a probe.\n\n## Extracting Templates from Existing Tickets\n\nWhen the user wants a template based on how they already create tickets:\n\n### Step 1: Find representative tickets\n\n```bash\njira search \"reporter = currentUser() AND type = Task ORDER BY created DESC\" --fields summary,parent,components,labels,priority\n```\n\n### Step 2: Inspect fields and schema\n\n```bash\n# Look at a real ticket's fields\njira issue get DEV-123 --raw\n\n# Check all available fields for that type (required fields, allowed values)\njira fields schema --project DEV --type Task\n```\n\nLook at the fields that are consistent across tickets (project, issuetype, parent,\ncomponents, labels) — these become the template. Ignore fields that vary per ticket\n(summary, description).\n\n### Step 3: Create the template\n\nExtract the common fields into a template:\n\n```bash\njira template create my-template --json '{\n  \"project\": \"DEV\",\n  \"issuetype\": \"Task\",\n  \"parent\": \"DEV-100\",\n  \"components\": [\"API\"]\n}'\n```\n\n### Step 4: Verify\n\n```bash\njira template show my-template\n```\n\n## Managing Templates\n\n```bash\njira template list                    # all templates\njira template show backend            # view one\njira template create NAME --json '{}'  # create\njira template delete NAME             # remove\n\njira template default backend         # set as default\njira template default                 # show current default\njira template default --clear         # remove default\n```\n\nWhen a default is set, `jira issue create --summary \"...\"` uses it automatically.\n\nThere is no reliable non-interactive JSON edit flow for templates. To replace a\nstale template, create a new one, set it as default, verify, then delete the old\none:\n\n```bash\njira template create someproject-new --json '{\"project\":\"DEV\",\"issuetype\":\"Task\",\"parent\":\"DEV-100\",\"components\":[\"SomeTeam\"]}'\njira template default someproject-new\njira template show someproject-new\njira template delete someproject-old\n```\n\n## Editing Issues\n\n```bash\n# Set individual fields\njira issue edit DEV-123 --set priority=\"P1: High\" --set story_points=5\n\n# JSON override; useful for Markdown description because it converts to ADF\njira issue edit DEV-123 --json '{\"description\": \"## Updated analysis\\n\\nThe root cause is...\"}'\njira issue edit DEV-123 --json '{\"team\": \"Backend\", \"labels\": [\"urgent\"]}'\n\n# Set description directly (accepts Markdown — same converter, same caveat about nested code marks)\njira issue edit DEV-123 --description \"## Updated\\n\\nNew description\"\n\n# Read description from file (avoids shell-escaping pain for long Markdown)\njira issue edit DEV-123 --body-file \u002Ftmp\u002Fdescription.md\n\n# Raw payload; bypasses field\u002Fvalue resolution and sends exact Jira API JSON\njira issue edit DEV-123 --raw-payload '{\"fields\": {\"summary\": \"Updated title\"}}'\n```\n\nIf `--set` or `--json` returns a generic 400 even though the field\u002Fvalue looks valid, retry with `--raw-payload`. Apply one optional field per request while recovering so one bad field does not block the rest:\n\n```bash\njira issue edit DEV-123 --raw-payload '{\"fields\": {\"components\": [{\"name\": \"SomeTeam\"}]}}'\njira issue edit DEV-123 --raw-payload '{\"fields\": {\"customfield_10008\": [\u003Csprint_id>]}}'\njira issue edit DEV-123 --raw-payload '{\"fields\": {\"\u003Ccustomfield_id>\": \"\u003Cvalue>\"}}'\n```\n\nUse `jira fields list --filter \u003Ckeyword>` or `jira fields schema --project DEV --type Task` to find custom field ids and allowed values.\n\n## Workflow Operations\n\n```bash\n# Transition status\njira issue transition DEV-123 \"In Progress\"\njira issue transition DEV-123 \"Done\"\n\n# Assign\njira issue assign DEV-123 alice@example.com\n\n# Comment\njira issue comment DEV-123 \"Fixed in commit abc1234\"\n\n# Link issues (--type values: \"blocks\", \"is blocked by\", \"relates to\", \"duplicates\", \"is duplicated by\", \"clones\", \"is cloned by\")\njira issue link DEV-123 DEV-456 --type blocks\n```\n\nIf the target status is not currently available, the CLI error lists available\ntransitions. Walk through the required intermediate statuses, for example:\n\n```bash\njira issue transition DEV-123 \"In Progress\"\njira issue transition DEV-123 \"In Review\"\n```\n\n## Bulk Operations\n\nOnly bulk edit is supported. Use it to update the same field(s) across multiple issues:\n\n```bash\njira bulk edit DEV-1 DEV-2 DEV-3 --set parent=DEV-100\njira bulk edit DEV-1 DEV-2 --set priority=\"P1: High\"\njira bulk edit DEV-1 DEV-2 --json '{\"team\": \"Backend\"}'\n```\n\nFor bulk creation or transitions, loop over individual commands.\n\n## Schema Inspection\n\nUse these to discover what fields and values are available:\n\n```bash\n# All fields with their IDs and types\njira fields list\n\n# Search for a field by name\njira fields list --filter story\n\n# Full schema for a project + issue type (required fields, allowed values)\njira fields schema --project DEV --type Task\n```\n\nThe schema output tells you exactly what to pass when creating or editing issues.\n\n## Sprints and Boards\n\nFor active sprint discovery in automation, prefer JQL first because board APIs may return 403:\n\n```bash\njira search \"project = DEV AND sprint in openSprints() ORDER BY updated DESC\" --fields key,summary,status,assignee,sprint\n```\n\nIf you need the raw sprint id, inspect an issue already in the active sprint:\n\n```bash\njira issue get DEV-123 --raw | jq '.fields.customfield_10008'\n```\n\nSprint assignment is best-effort. If setting the sprint field returns 400, do not block a traceability workflow whose required end state is ticket, assignee, status, and PR linkage. If sprint assignment is still desired, use raw payload with the exact sprint custom field shape for the project:\n\n```bash\njira issue edit DEV-123 --raw-payload '{\"fields\": {\"customfield_10008\": [\u003Csprint_id>]}}'\n```\n\nUse board APIs only when you specifically need board\u002Fbacklog operations and permissions allow them:\n\n```bash\njira board list --project DEV\njira sprint current --board 42\njira sprint list --board 42 --state active,future\njira sprint issues 123 --fields summary,status,assignee\njira board backlog 42\n```\n\n## Users\n\n```bash\njira user me                # current user\njira user search \"alice\"    # find users\n```\n\n## Error Handling\n\nAll errors output structured JSON to stderr:\n\n```json\n{\"error\": \"404 Client Error: Not Found for url: ...\", \"type\": \"HTTPError\"}\n```\n\nParse the `error` and `type` fields to decide how to recover. When a command fails, read the error message and recover:\n\n- **Field validation error** on create\u002Fedit → check required fields and allowed values:\n  ```bash\n  jira fields schema --project DEV --type Task\n  ```\n- **Generic 400 on create\u002Fedit with valid-looking `--json` or `--set`** → retry with `--raw-payload` using exact Jira API field shapes. For creates, create the minimal core issue first, then edit optional fields afterward. For edits, set one optional field per request while recovering.\n- **Generic 400 when posting a comment \u002F description from Markdown** → check whether the Markdown contains nested inline marks like `**\\`code\\`**`, `*\\`code\\`*`, or `[\\`code\\`](url)`. The converter emits invalid ADF for those and Atlassian rejects the document. Workaround: use a fenced code block, or split the formatting (`**See** \\`code\\` here`).\n- **Template create fails or creates tickets under old work** → inspect the\n  template with `jira template show`, verify its `parent` issue status, and\n  replace the template if the parent is stale.\n- **Unknown field name** → list available fields and find the correct name:\n  ```bash\n  jira fields list --filter \u003Ckeyword>\n  ```\n- **Invalid transition** → the issue's current status may not allow that transition.\n  Use the available statuses printed in the error and transition through the\n  appropriate intermediate state.\n- **Permission denied \u002F 403** → the authenticated user lacks permission for that\n  project or operation. Verify with `jira auth status` and `jira user me`. If\n  board\u002Fsprint APIs are forbidden, use JQL search fallbacks.\n- **Invalid JQL** → simplify the query, check field names and function syntax.\n\n## Field Resolution Reference\n\nWhen using `--json` or `--set`, field names and values are resolved automatically:\n\n| You write | API receives |\n|-----------|-------------|\n| `\"project\": \"DEV\"` | `\"project\": {\"key\": \"DEV\"}` |\n| `\"issuetype\": \"Task\"` | `\"issuetype\": {\"name\": \"Task\"}` |\n| `\"parent\": \"DEV-100\"` | `\"parent\": {\"key\": \"DEV-100\"}` |\n| `\"priority\": \"P1: High\"` | `\"priority\": {\"name\": \"P1: High\"}` |\n| `\"team\": \"Backend\"` | `\"customfield_10001\": {\"value\": \"Backend\"}` |\n| `\"components\": [\"API\"]` | `\"components\": [{\"name\": \"API\"}]` |\n| `\"story_points\": 5` | `\"customfield_10036\": 5` |\n| `\"description\": \"**Markdown** text\"` | parsed as Markdown, converted to ADF |\n| `\"description\": {ADF doc}` | passed through as-is (dicts are never wrapped) |\n\nUse `--raw-payload` to bypass all resolution and send exact JSON to the API.\n\n## Known issues\n\n### Markdown → ADF: nested inline code marks produce invalid ADF (HTTP 400)\n\nWhen Markdown contains an inline code span nested inside another inline mark, the converter emits a single text node with two marks (e.g. `marks=[strong, code]`). ADF's schema does not allow the `code` mark to combine with any other inline mark, so Atlassian rejects the document with a generic `400 Bad Request`.\n\nTriggers (all produce HTTP 400 from the comment \u002F description endpoints):\n\n- `**\\`foo.py\\`**` (bold around inline code)\n- `*\\`foo.py\\`*` (italic around inline code)\n- `[\\`foo.py\\`](url)` (link around inline code)\n- Any sentence-level bold that contains inline code as a child: `**See \\`foo.py\\` here**`\n\nSafe alternatives:\n\n- Plain inline code: `` `foo.py` `` — fine, even with quotes\u002Fbraces\u002Fparens inside (`` `os.system(f\"echo {x}\")` `` is OK).\n- Fenced code block — fine for any language and any content.\n- Bold of plain text: `**foo.py**` — fine.\n- Split the formatting at the boundary: `**See** \\`foo.py\\` **here**`.\n\nQuick local repro (run with the jira-genie tool's interpreter):\n\n```python\nfrom jira_genie.adf import markdown_to_adf\nadf = markdown_to_adf(\"Bad: **`foo.py`**\")\n# Walk to a text node and you'll see marks=[strong, code] — invalid per ADF schema.\n```\n\n## Common Agent Patterns\n\n### Gather context before working\n\n```bash\njira issue get DEV-123\njira search \"parent = DEV-123\" --fields summary,status\n```\n\n### Update a ticket's description\n\nUse `jira issue edit` with `--description` (short Markdown), `--body-file` (long Markdown), or `--json` (Markdown inside a JSON payload):\n\n```bash\n# Short description inline\njira issue edit DEV-123 --description \"## Updated analysis\\n\\nThe root cause is...\"\n\n# Long description from file (avoids shell-escaping pain)\njira issue edit DEV-123 --body-file \u002Ftmp\u002Fdescription.md\n\n# Or via --json (when you want to set description alongside other fields)\njira issue edit DEV-123 --json '{\"description\": \"## Updated analysis\\n\\nThe root cause is...\"}'\n```\n\nFor long descriptions assembled in shell, write to a file first, then use one of the above:\n\n```bash\ncat > \u002Ftmp\u002Fdesc.md \u003C\u003C 'EOF'\n## Full analysis\n\nDetailed description here...\nEOF\njira issue edit DEV-123 --body-file \u002Ftmp\u002Fdesc.md\n```\n\n### Add a comment\n\n```bash\n# Short comment\njira issue comment DEV-123 \"Fixed in commit abc1234\"\n\n# Long comment from file\njira issue comment DEV-123 --body-file \u002Ftmp\u002Fanalysis.md\n```\n\nComments accept Markdown — it's auto-converted to Atlassian Document Format. Same caveat as descriptions: avoid nested inline code marks (see Known issues).\n\n### Create task, do work, close\n\n```bash\njira issue create --template backend --summary \"Fix the bug\"\n# ... do the work ...\njira issue transition DEV-124 \"In Progress\"\njira issue comment DEV-124 \"Working on it\"\n# ... finish ...\njira issue transition DEV-124 \"Done\"\njira issue comment DEV-124 \"Fixed in commit abc1234\"\n```\n\n### Discover and report\n\n```bash\njira search \"project = DEV AND sprint in openSprints() AND status = 'To Do'\" --fields summary,assignee,priority\n```\n",{"name":5,"description":7},"main","405a8f4042e8fbb2780ce1c2ee0048c47ff03af7","skills\u002Fjira-genie",0,"https:\u002F\u002Fgithub.com\u002Fhenriquebastos\u002Fjira-genie","https:\u002F\u002Fgithub.com\u002Fhenriquebastos","http:\u002F\u002Fhenriquebastos.net","🔥 Drinking AI from the firehose •  🐍 Python since 1999 •  ⛩ Trained 10k+ devs • 🚀 PSF and DSF Fellow","2026-09-18 10:49:05",{"source":8,"skillName":5,"commands":54,"prompt":64,"zipAvailable":65},[55,58,61],{"tool":56,"command":57},"npx","npx skills add henriquebastos\u002Fjira-genie --skill jira-genie",{"tool":59,"command":60},"bunx","bunx skills add henriquebastos\u002Fjira-genie --skill jira-genie",{"tool":62,"command":63},"pnpm","pnpm dlx skills add henriquebastos\u002Fjira-genie --skill jira-genie","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fhenriquebastos\u002Fjira-genie\u002Fblob\u002Fmain\u002Fskills\u002Fjira-genie\u002FSKILL.md",true,[],[68,73,99],{"skillNo":69,"name":5,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":70,"categories":71,"keywords":72,"publishedAt":39},"01M6J0H6KJYPWP41YVK0QV2PP6","https:\u002F\u002Fgithub.com\u002Fhenriquebastos\u002Fjira-genie\u002Fblob\u002Fmain\u002Fsrc\u002Fjira_genie\u002Fskills\u002Fjira-genie\u002FSKILL.md",[],[19,21,20],{"skillNo":74,"name":75,"nameZh":6,"description":76,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":77,"categories":78,"keywords":84,"publishedAt":39},"01M6J0H390VPXZPGMY33KJCH2R","orchestrate","Poll beans for ready epics, create worktrees, and delegate to sub-agents that implement each epic following docs\u002Fworkflow.md. Use when asked to \"run orchestration\", \"process epics\", or \"start the agent loop\".","https:\u002F\u002Fgithub.com\u002Fhenriquebastos\u002Fjira-genie\u002Fblob\u002Fmain\u002Fskills\u002Forchestrate\u002FSKILL.md",[79],{"categoryNo":80,"categoryName":81,"taxonomyType":82,"taxonomyTypeDesc":83},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",[75,85,86,87,88,89,90,91,92,93,94,95,23,35,96,97,98],"run","workflow","start","loop","delegate","agent loop","process","use","ready","worktrees","EPIC","orchestration","implement","docs",{"skillNo":100,"name":101,"nameZh":6,"description":102,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":39},"01M6J0GQWMT0MCC7WSGHMS6VZA","intake","Sync GitHub Issues into beans epics. Run periodically or on demand to import new issues as beans epics for the orchestrator to pick up.","https:\u002F\u002Fgithub.com\u002Fhenriquebastos\u002Fjira-genie\u002Fblob\u002Fmain\u002Fskills\u002Fintake\u002FSKILL.md",[],[101,106,23,107,108,109,110,111,112,32,113,85,114],"github","import","sync github","as","up","orchestrator","pick","github issues","sync"]