teamcraft-jcg:fetch-issue

---
name: teamcraft-jcg:fetch-issue
description: Fetch a Jira issue, analyze its requirements against the current codebase, and assess feasibility. The starting point for every build cycle. Accepts a Jira issue key as argument. Use when starting a ticket, picking up work, checking feasibility of an issue, pulling up a Jira ticket, asking "what does this issue need", or beginning any new piece of work. Also run this when you want to understand what a ticket involves before committing to it, or when checking if an issue is ready to plan.
argument-hint: "[issue key, e.g. PROJ-42]"
disable-model-invocation: true
user-invocable: true
allowed-tools:
  - Read
  - Glob
  - Grep
  - Bash
  - mcp__sooperset-mcp-atlassian__jira_get_issue
  - mcp__sooperset-mcp-atlassian__jira_get_all_projects
  - mcp__sooperset-mcp-atlassian__jira_transition_issue
  - mcp__sooperset-mcp-atlassian__jira_get_transitions
---

## Goal

Produce a clear, grounded feasibility assessment for the issue — what the issue requires, what already exists in the codebase that's relevant, and whether the work is ready to plan. The developer should leave this skill knowing exactly what they're taking on and any blockers to address first.

## Hard Constraints

- The issue key comes from `$ARGUMENTS`. If not provided, ask — do not guess or list issues.
- Find the Jira project from `.teamcraft/project.md` if it exists, then from the issue key itself (the project key prefix identifies the project). Confirm the project before fetching.
- If neither `.teamcraft/project.md` nor CLAUDE.md exists, note this clearly after presenting the feasibility assessment: no local project context was found. `plan-and-implement-issue` will ask about Confluence tech decisions and conventions before planning — make sure to have those Confluence page IDs or URLs ready. Once scaffolding is complete, run `init-project` to make the project context permanent.
- Apply the "In Progress" status transition only after the developer confirms they are starting this issue. Use `mcp__sooperset-mcp-atlassian__jira_get_transitions` to fetch the available transitions, find the transition whose name corresponds to "In Progress" (the exact name varies by project workflow), then call `mcp__sooperset-mcp-atlassian__jira_transition_issue`. Never assume transition names — every Jira project may have different workflow state names.
- Never make code changes. This skill is read-only on the codebase.

## Load the Issue

Fetch the issue from Jira using `mcp__sooperset-mcp-atlassian__jira_get_issue` with the issue key from `$ARGUMENTS`. Read it completely — title, description, acceptance criteria, status, labels, sprint, and any existing comments that contain technical decisions or scope changes.

Note which sprint this issue belongs to (cross-reference with `.teamcraft/project.md` if the manifest exists).

## Analyze the Codebase

Search the codebase for what's relevant to this issue. The goal is to understand: what already exists that this work connects to or extends, what patterns and conventions are established in this area, what files will likely be touched, and whether anything makes this issue blocked or already done.

CLAUDE.md and `.claude/rules/` contain conventions already captured for this project — read them for relevant context rather than rediscovering it from scratch.

## Produce the Assessment

Present to the developer:

**What the issue requires** — a clear restatement of the requirements and acceptance criteria, in your own words, flagging any ambiguity that should be resolved before planning.

**What exists** — relevant existing code, patterns, integration points, and related components found in the codebase.

**Feasibility assessment** — one of:
- Ready to plan — requirements are clear, no blockers found
- Partially started — describe what exists and what remains
- Already implemented — describe the evidence; recommend closing or repurposing
- Blocked — describe the dependency or gap that must be resolved first

**Questions to resolve** — any ambiguity in the issue that would make planning harder or implementation risky. Raise these explicitly; don't paper over them. These are surfaced for awareness — they are resolved in `plan-and-implement-issue`, not here. Never ask the developer to answer design or implementation questions during this skill. Asking design questions implies implementation is next, which violates the read-only purpose of this skill.

## Update Issue Status

If the developer confirms they are starting this issue, transition it to "In Progress" in Jira. First call `mcp__sooperset-mcp-atlassian__jira_get_transitions` to get the available transitions for this issue. Find the transition corresponding to "In Progress" — the name may be "In Progress", "Start", "Start Work", or similar depending on the project workflow. Apply that transition via `mcp__sooperset-mcp-atlassian__jira_transition_issue`. If no clear "In Progress" equivalent exists, present the available transitions to the developer and ask which to apply.

## Done

Present the assessment. Apply the status transition if confirmed. Then:

> "Do you have any visual references for this work — mockups, wireframes, style guides, or screenshots? If so, have them ready for `plan-and-implement-issue` — they'll be loaded into context during planning."

Then close with exactly this:

> "Run `plan-and-implement-issue [ISSUE-KEY]` when ready to plan implementation."

**This skill is now over.** Do not write code. Do not plan implementation. Do not ask design questions. Do not ask what to do next. If the developer asks a design or implementation question after the assessment, respond with: "That's a question for plan-and-implement-issue — it will be resolved there before planning starts." Then stop. No further action. No exceptions.