arn-code-pick-issue

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, title, labels, and age:

1. #42 — Add WebSocket support [arness-feature-issue, arness-priority-high] (3 days ago)
2. #38 — Fix checkout 500 error [arness-bug-issue, arness-priority-medium] (1 week ago)
3. #35 — Refactor auth middleware [arness-backlog, arness-priority-low] (2 weeks ago)
...

If more than 10 results exist, offer "Show more" to fetch the next page.

If no results match the filters, inform the user and suggest either adjusting the filters or creating a new issue via /arn-code-create-issue.

If Issue tracker is jira

Use the Atlassian MCP server to search Jira issues with JQL:

project = <JIRA_PROJECT>
  AND labels in (<selected-arness-labels>)
  AND status != Done
  ORDER BY created DESC

Request fields: key, summary, labels, created, assignee, status, priority.

Display results as a numbered list:

1. PROJ-42 — Add WebSocket support [Story, High] (3 days ago)
2. PROJ-38 — Fix checkout error [Bug, Medium] (1 week ago)
3. PROJ-35 — Refactor auth middleware [Task, Low] (2 weeks ago)
...

Paginate: show 10 results at a time, offer "Show more" option.

If no results match the filters, inform the user and suggest either adjusting the filters or creating a new issue via /arn-code-create-issue.

Step 4: Select Issue

Wait for the user to select an issue by number from the displayed list.

If Issue tracker is github

Fetch the full issue details:

gh issue view <number> --json number,title,body,labels,comments,assignees,createdAt,author

Display the full issue to the user: title, body, labels, comments, assignees, and author.

If Issue tracker is jira

Use the Atlassian MCP server to get full issue details by key (e.g., PROJ-42).

Display the full issue to the user: summary, description, issue type, labels, priority, status, assignee, and comments.

Step 5: Assess Issue

Invoke the most appropriate agent for a brief assessment based on the issue's labels:

• arness-feature-issue (GitHub) or Story (Jira) — invoke the arn-code-architect agent to assess feasibility, scope, and architectural impact.
• arness-bug-issue (GitHub) or Bug (Jira) — invoke the arn-code-investigator agent to do a quick diagnostic assessment (likely cause, affected components, reproduction steps if available).
• arness-backlog (GitHub) or Task (Jira) — choose the agent based on issue content:
• If the content describes a feature or enhancement, invoke arn-code-architect.
• If the content describes a defect or error, invoke arn-code-investigator.
• If unclear, default to arn-code-architect.

The agent receives the issue title, body (or backlog entry content if coming from the local Feature Tracker path), and relevant codebase context. It provides a brief assessment covering:

• Is the issue valid and actionable?
• Estimated complexity (sma