Resolve GitHub Issue

Resolve GitHub Issue

Take a GitHub issue through to a verified, committed implementation on a feature branch — stopping short of the PR.

Fetch — both calls, always

gh issue view $ARGUMENTS                # title, labels, body, and a `comments: N` count
gh issue view $ARGUMENTS --comments     # the thread — this one omits the body, so it is not a swap for the first

Read the comments, not just the body. The body is the oldest artifact on an issue; comments carry scope added later, sequencing against other issues, and decisions that supersede an acceptance criterion still written in the body. An issue filed months ago and worked today is the normal case, not the exception. Run the second call unconditionally — the comments: N count sits in a metadata header that is easy to skim past, and a zero-comment issue costs one wasted call.

Plan before implementing

Right-size the ceremony to the issue:

• Small and well-scoped (a few files, an obvious approach) — state the plan in a line and proceed. Don't wait for a reply.
• Complex or ambiguous (multiple subsystems, design choices, real risk) — present the implementation plan and wait for explicit approval.

When unsure which applies, treat it as complex and ask.

Branch

Check git branch --show-current first:

• Already on a feature branch for this issue (<prefix>/gh-$ARGUMENTS-…) — reuse it, do not create a second branch. This includes re-entering this step inside an autopilot fan-out worktree.
• Otherwise — git switch -c <prefix>/gh-$ARGUMENTS-<short-description>

The prefix comes from the issue's type label. If the project defines its own branch convention, that wins.

No type label? Bug fixes are fix/, new functionality feat/, everything else chore/.