# Issue tracker resolution for code review

Use this guide only when the repository being reviewed does not already provide its own issue-tracker instructions. Repository-specific instructions always take precedence.

The goal is narrow: resolve an issue or ticket referenced by the commits so the **Spec** review can compare the diff against the originating requirement. Do not modify tracker configuration as part of code review.

## 1. Detect the tracker

Inspect the repository's Git remotes and nearby project documentation.

- A GitHub remote normally means GitHub Issues.
- A GitLab remote normally means GitLab Issues.
- A repository that keeps work items under `.scratch/` may use local Markdown specs/issues.
- For Jira, Linear, Azure DevOps, Gitea, or another tracker, follow any project-specific instructions or ask the user how to retrieve the referenced ticket.

If the tracker cannot be determined reliably, ask the user rather than guessing.

## 2. GitHub

Use the GitHub CLI when it is available and authenticated.

- Read an issue: `gh issue view <number> --comments`
- If a bare number may refer to a pull request, try `gh pr view <number> --comments` and use `gh pr diff <number>` when the pull request itself is the relevant spec/change discussion.
- Infer the repository from the current clone when possible; otherwise use the repository explicitly.

Capture the issue title, body, relevant comments, and any acceptance criteria needed for the Spec review.

## 3. GitLab

Use the GitLab CLI when it is available and authenticated.

- Read an issue: `glab issue view <number> --comments`
- Read a merge request when the commit reference points there: `glab mr view <number> --comments`

Capture the issue or merge-request description, relevant comments, and acceptance criteria needed for the Spec review.

## 4. Local Markdown

If the repository uses local work items, search `.scratch/`, `specs/`, and project documentation for a file matching the issue number, branch name, feature name, or commit-message reference. Prefer an explicit spec file when one exists.

## 5. Other trackers or unavailable tooling

If the tracker is known but its client/tooling is unavailable, ask the user for either:

- the issue/spec contents,
- a local path containing the spec, or
- access to the appropriate tracker integration/tool.

Do not invent requirements from the diff.

## 6. No spec available

If no issue/spec can be retrieved after the above checks, ask the user where the spec is. If the user confirms there is no spec, skip the Spec sub-agent and report `no spec available`, while still completing the Standards review.