teamcraft-glgd:fetch-issue

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

## 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 IID comes from `$ARGUMENTS`. If not provided, ask — do not guess or list issues.
- Find the GitLab project from `.teamcraft/project.md` if it exists, then from git remote context. 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 Google Drive tech decisions and conventions before planning — make sure to have those URLs ready. Once scaffolding is complete, run `init-project` to make the project context permanent.
- Apply the "In Progress" label only after the developer confirms they are starting this issue. Fetch current labels first, merge the new label into the existing set, then update — do not replace all labels.
- Never make code changes. This skill is read-only on the codebase.

## Load the Issue

Fetch the issue from GitLab. Read it completely — title, description, acceptance criteria, labels, milestone, and any existing comments that contain technical decisions or scope changes.

Note which sprint milestone 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, apply the "In Progress" label in GitLab. Fetch current labels first, add "In Progress" to the set, then update. If the label doesn't exist in the project, note that and ask the developer whether to create it.

## Done

Present the assessment. Apply the label 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 [IID]` 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.