github-do-issue

Purpose

Structured workflow for implementing a GitHub issue in any project. Fetch the issue, understand the requirements, plan the approach, implement the solution, and verify it — then stop and let the user review before any git operations happen.

When to use

• User says "work on issue #N", "do #N", "implement #N", or similar
• User provides one or more GitHub issue URLs
• User references several issue numbers at once ("do #12, #13 and #14") — that is a queue of separate jobs, not one big job

One issue, one commit, one PR

Each issue is a self-contained unit of work all the way through: its own implementation, its own review, its own commit, its own branch, its own pull request. Even when the user names five issues in a single sentence, that is five runs of this workflow, not one run covering five issues.

This matters because a pull request is the unit people review, discuss, revert and link back to an issue. A PR that closes three issues at once can't be reviewed in pieces, can't be reverted in pieces, and forces a reviewer who only cares about one of them to read all three. Interleaving the implementations is worse still: once two issues' edits are mixed in the working tree, they can no longer be split into clean commits without picking the diff apart by hand.

So when the input names more than one issue: