/arn-code-pick-issue

name: arn-code-pick-issue
description: >-
  This skill should be used when the user says "pick issue", "work on issue",
  "arness code pick", "arness code pick issue", "arn-code-pick-issue", "grab issue", "pick from backlog", "what should I work on",
  "show issues", "find issue", "browse issues", "next issue", "select issue",
  "choose issue",
  "what's unblocked", "work on next feature", "pick from feature tracker",
  or wants to browse issues filtered by Arness labels, select one, and route
  it to the appropriate Arness pipeline skill for implementation. Supports
  local-first dependency resolution from a greenfield feature backlog when
  available. Requires an issue tracker (GitHub or Jira) to be configured
  for remote issue browsing. Do NOT use this for creating new issues — use
  /arn-code-create-issue for that.
version: 1.3.0
argument-hint: "[search-keywords]"

Arness Pick Issue

Browse issues filtered by Arness labels, select one for assessment, and route it to the appropriate Arness pipeline skill for implementation. When a greenfield feature backlog with a Feature Tracker exists, offers local-first dependency resolution to surface unblocked features without network calls.

---

Step 1: Check Prerequisites

If no `## Arness` section exists in the project's CLAUDE.md, inform the user: "Arness is not configured for this project yet. Run `/arn-planning` to get started — it will set everything up automatically." Do not proceed without it.

Read the **Issue tracker** field from `## Arness` config in the project's `CLAUDE.md` (values: `github`, `jira`, or `none`). If the `Issue tracker` field is not present, fall back to legacy detection: check for `GitHub: yes` and treat as `github`; otherwise treat as `none`.

If Issue tracker is github

1. `git rev-parse --is-inside-work-tree` — confirm the working directory is inside a git repository. 2. `git remote -v` — confirm a GitHub remote exists (the origin URL must contain `github.com`). 3. `gh auth status` — confirm the GitHub CLI is authenticated.

If any check fails, inform the user what is missing and suggest running `/arn-planning` to get started. Do not proceed until all prerequisites are satisfied.

If Issue tracker is jira

1. Read **Jira project** and **Jira site** from `## Arness` config 2. Verify the Atlassian MCP server is available (attempt a lightweight MCP call, e.g., list projects) 3. If the MCP server is not available: "The Atlassian MCP server is not available. Run `/mcp` to check status, or run `/arn-planning` to reconfigure."

If Issue tracker is none

Check for a greenfield feature backlog before stopping:

1. Read `## Arness` config — check if a **Vision directory** field exists (only set by `arn-spark-init`, never by core `arn-code-init`) 2. If Vision directory exists, check if `<vision-dir>/features/feature-backlog.md` exists 3. If the file exists, check if it contains a `## Feature Tracker` table

**If all three pass:** Proceed to Step 1b (Local Backlog Check). The greenfield feature backlog provides a local-only alternative to remote issue browsing. Inform the user: "No remote issue tracker is configured, but a local greenfield feature backlog was found. Showing local features."

**If any condition fails:** Inform the user: "Issue management is not configured for this project. Run `/arn-planning` to get started, or configure the issue tracker manually." STOP — do not proceed.

---

Step 1b: Local Backlog Check (Greenfield Integration)

This step is entirely optional — it activates only when a greenfield feature backlog exists. Projects without greenfield skip this step silently and proceed to Step 2. It resolves dependencies in the local Feature Tracker, presents unblocked features, validates against the remote issue tracker, and updates the tracker status.

> Read `${CLAUDE_PLUGIN_ROOT}/skills/arn-code-pick-issue/references/greenfield-backlog-resolution.md` for the full detection chain, resolution workflow, and sub-feature handling.

If the user picks a feature from the local backlog, skip Steps 2-4 and proceed to Step 5 (Assess Issue).

---

Step 2: Filter Issues

**Deferred Label Check:**

If Platform is `github`: check if Arness labels exist by running `gh label list --search "arness-"`. If fewer than 7 Arness labels are found, create the missing ones using `gh label create --force` for each label per `${CLAUDE_PLUGIN_ROOT}/skills/arn-code-init/references/platform-labels.md`. This is idempotent and safe to run on every invocation.

If Platform is `bitbucket` or Issue tracker is `jira`: no label creation needed (Jira labels are implicit, Bitbucket uses different mechanisms).

Ask the user how they want to filter issues, or infer filters from hints in the trigger message. Use `AskUserQuestion` to gather preferences.

**By type:**

• `arness-feature-issue` — Feature requests only
• `arness-bug-issue` — Bug reports only
• `arness-backlog` — Backlog items only
• All Arness-labeled — any issue with a Arness label

**By priority (optional):**

• `arness-priority-high`
• `arness-priority-medium`
• `arness-priority-low`
• Any priority

**By state:** Open (default), Closed, All

**Free text search (optional):** If the user provides keywords in their trigger message, use them as a search filter.

If Issue tracker is github

Build the label filter from the user's selections. Multiple labels are combined with AND logic in `gh issue list`.

If Issue tracker is jira

Build a JQL query from the user's selections. Labels map directly (e.g., `arness-feature-issue`). Priority maps to Jira priority values (High, Medium, Low). State maps to Jira statuses (e.g., Open excludes `Done`).

---

Step 3: Fetch and Paginate

If Issue tracker is github

Use the `gh` CLI to fetch issues matching the constructed filter:

gh issue list --label "<label1>,<label2>" --state open --limit 10 --json number,title,labels,createdAt,author

Display results as a numbered list with issue number, t