{"id":17984,"plugin_id":"plugins_6a82e3d1df508191bfffcec222b18433","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:14:32.866Z","digest":"07e7031201b0a55be1d8a02ed04683733f33a91a0aed6406aad381b1c9ffec3b","against":null,"payload":{"description":"Fetch a work item (summary, status, description, acceptance criteria, comments) from the team's issue tracker and display a clean summary. Supports Jira, Linear, GitHub Issues, and Azure DevOps via adapters. Use whenever a prompt contains an issue reference (e.g. PROJ-1234, ENG-42,","included_files":[],"name":"issue-fetch","skill_md_contents":"---\nname: issue-fetch\ndescription: Fetch a work item (summary, status, description, acceptance criteria, comments) from the team's issue tracker and display a clean summary. Supports Jira, Linear, GitHub Issues, and Azure DevOps via adapters. Use whenever a prompt contains an issue reference (e.g. PROJ-1234, ENG-42, #123) or the user asks to work on a user story.\n---\n\n# Issue Fetch\n\nFetch full context for a work item before any planning or implementation begins. The tracker is configured once (see below); this skill speaks to whichever one the team uses.\n\n## Trigger\n\nAny prompt containing an issue reference, or an explicit request to fetch/work on a story. Reference shapes differ by tracker:\n\n| Tracker | Key shape | Example |\n|---|---|---|\n| Jira | `[A-Z][A-Z0-9]+-\\d+` | `PROJ-1234` |\n| Linear | `[A-Z]+-\\d+` | `ENG-42` |\n| GitHub Issues | `#\\d+` or `owner/repo#\\d+` | `#123` |\n| Azure DevOps | `#?\\d+` (work item id) | `#4567` |\n\n## Project configuration\n\nRead `.claude/dev-kit.json` at the consuming repo root. The `tracker` block names the active adapter and its settings:\n\n```json\n{ \"tracker\": { \"type\": \"jira\" | \"linear\" | \"github\" | \"azure\", ... } }\n```\n\n**If the file does not exist (or has no `tracker` block), run the `dev-kit-setup` skill first** — it detects the tracker, gathers what it needs, persists the file, and returns here. Do not ask the user for values that setup can discover.\n\nIf the requested key's project/prefix does not match the configured one, confirm with the user before fetching (it may be a cross-project item — allowed, just not silently).\n\n## Adapters — how to fetch\n\nUse the adapter matching `tracker.type`. In every case request at minimum: **summary/title, type, status, priority, assignee, reporter, labels, description, acceptance criteria, and all comments** (plus story points and sprint/cycle when the tracker has them).\n\n### Jira (`type: \"jira\"`)\nConfig: `site`, `cloudId`, `projectKey`, `fields` (custom field IDs for acceptance criteria / sprint / story points).\nUse the **Atlassian MCP** tools against the configured site to get the issue and its comments, reading acceptance criteria via the configured field IDs.\n- If a configured field ID turns out to be invalid, re-run `dev-kit-setup` discovery for that field and update the config.\n\n### Linear (`type: \"linear\"`)\nConfig: `teamKey` (and optionally `workspace`).\nUse the **Linear MCP** tools to fetch the issue by identifier, its description, labels, state, assignee, and comments. Acceptance criteria usually live in the description body or a checklist — extract them from there.\n\n### GitHub Issues (`type: \"github\"`)\nConfig: `repo` (`owner/name`); defaults to the current repo's `origin` when omitted.\nFetch with the GitHub CLI (no MCP needed):\n```bash\ngh issue view <number> --repo <owner/name> --json number,title,state,labels,assignees,body,comments\n```\nAcceptance criteria are parsed from the issue body (task lists / a \"Acceptance criteria\" section).\n\n### Azure DevOps (`type: \"azure\"`)\nConfig: `org`, `project`.\nFetch via the Azure DevOps MCP if configured, otherwise the REST API / `az boards work-item show --id <id>`. Map fields: `System.Title`, `System.State`, `System.Description`, `Microsoft.VSTS.Common.AcceptanceCriteria`, and the work-item comments.\n\n## Authentication\n\nIf the adapter's backend is not authenticated (MCP connector not authorized, `gh`/`az` not logged in), tell the user exactly how to authenticate — MCP connectors via `/mcp` or claude.ai connector settings; CLIs via `gh auth login` / `az login` — and stop. **Never invent ticket content.**\n\n## Output format\n\nDisplay a concise summary before doing anything else:\n\n```\n===== KEY =====\nSummary  : ...\nType     : ...\nStatus   : ...\nPriority : ...\nAssignee : ...\nPoints   : ...        (omit if the tracker has no such field)\nSprint   : ...        (omit if the tracker has no such field)\nLabels   : ...\n\n--- Description ---\n...\n\n--- Acceptance Criteria ---\n...\n\n--- Comments (N) ---\n[date] author: ...\n```\n\n## After fetching\n\n1. If the description or comments contain a **Figma URL** (`figma.com/(design|file)/...`), invoke the `figma-fetch` skill next.\n2. Present an **implementation plan** and **wait for explicit user approval** before writing any code (see the issue-to-PR workflow). Never skip this gate unless the caller explicitly says the plan is pre-approved.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}