Issue Fetch

Fetch 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.

Trigger

Any prompt containing an issue reference, or an explicit request to fetch/work on a story. Reference shapes differ by tracker:

Project configuration

Read .claude/dev-kit.json at the consuming repo root. The tracker block names the active adapter and its settings:

{ "tracker": { "type": "jira" | "linear" | "github" | "azure", ... } }

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.

If 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).

Adapters — how to fetch

Use 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).

Jira (type: "jira")

Config: site, cloudId, projectKey, fields (custom field IDs for acceptance criteria / sprint / story points). Optional authMode: "mcp" (default) or "rest".

authMode: "mcp" (default). Use the Atlassian MCP tools against the configured site to get the issue and its comments, reading acceptance criteria via the configured field IDs.

authMode: "rest" — for clients without the Atlassian MCP. Call the Jira REST API directly with credentials from the environment (never from .claude/dev-kit.json, which stays secret-free):

• Jira Cloud: base URL https://<site> (or JIRA_BASE_URL), header Authorization: Basic <base64(JIRA_EMAIL:JIRA_API_TOKEN)>.
• Jira Server / Data Center: base URL JIRA_BASE_URL, header Authorization: Bearer <JIRA_PAT>.
• Fetch: GET <base>/rest/api/3/issue/<KEY>?fields=summary,description,status,comment,<ACfieldId>,<sprintFieldId>,<pointsFieldId> (use /rest/api/2/ on older Server). Read acceptance criteria from the configured fields IDs and comments from fields.comment.comments.
• If a required env var is missing, stop and tell the user exactly which to set, and to add .env to .gitignore — never invent credentials or fetch without them.

Automatic fallback (MCP unavailable or blocked). When authMode is unset or "mcp", first check the Atlassian MCP is actually usable. If it is not — not installed, not authorized, or blocked by policy (e.g. an enterprise that disables third-party MCPs) — and the JIRA_* env vars are present, use REST automatically and say so. Don't repeatedly retry a blocked MCP: when the block looks permanent (a policy/enterprise block rather than a missing one-time OAuth), offer to persist authMode: "rest" in .claude/dev-kit.json so every later run goes straight to REST. If neither the MCP nor the env credentials are available, stop and offer both paths (authorize the MCP, or set authMode: "rest" + the env vars).

• If a configured field ID turns out to be invalid, re-run dev-kit-setup discovery for that field and update the config.

Linear (type: "linear")

Config: teamKey (and optionally workspace). Use 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.

GitHub Issues (type: "github")

Config: repo (owner/name); defaults to the current repo's origin when omitted. Fetch with the GitHub CLI (no MCP needed):

gh issue view <number> --repo <owner/name> --json number,title,state,labels,assignees,body,comments

Acceptance criteria are parsed from the issue body (task lists / a "Acceptance criteria" section).

Azure DevOps (type: "azure")

Config: org, project. Fetch 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.

Authentication

If 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.

Output format

Display a concise summary before doing anything else:

===== KEY =====
Summary  : ...
Type     : ...
Status   : ...
Priority : ...
Assignee : ...
Points   : ...        (omit if the tracker has no such field)
Sprint   : ...        (omit if the tracker has no such field)
Labels   : ...

--- Description ---
...

--- Acceptance Criteria ---
...

--- Comments (N) ---
[date] author: ...

After fetching

1. If the description or comments contain a Figma URL (figma.com/(design|file)/...), invoke the figma-fetch skill next.
2. 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.