github-issue

GitHub Issue Workflow

Full lifecycle skill for working on a GitHub issue: scaffolding, planning, implementation, PR creation, and teardown.

The issue tracker is GitHub itself, driven entirely through the gh CLI — there is no separate tracker to keep in sync. Everything the workflow records (plans, decisions, completion notes) goes on the issue or the PR.

---

Phase 0 — Issue & Worktree Setup

Phase 0 is mandatory and sequential. Execute Steps 1 → 6 in order, and finish all of them before any Phase 1 exploration or planning.

• At the start of Phase 0, create one task per step (Steps 1, 1.5, 2, 3, 4, 5, 6) with TaskCreate, and flip each to in_progress then completed as you go. A skipped step must be visibly impossible.
• Never silently skip a step. If a step genuinely does not apply, name the step and state why before continuing (e.g. "Step 5: no env setup needed, this repo has no flake").
• The user supplying context up front — base branch, approach, constraints — feeds Step 1.5. It does not authorize jumping ahead to planning; you still run Steps 2 → 6.
• Step 6 is easy to skip. Run herdr-workspace-layout open before leaving Phase 0. It is a no-op outside herdr, so there is no condition to evaluate first.

Step 1: Resolve the issue

If $ARGUMENTS contains an issue number (123, #123) or an issue URL:

gh issue view {number} --json number,title,body,state,labels,assignees,url

• For a URL from another repo, pass --repo {owner}/{repo} and carry that --repo through every later gh call.
• Display the issue title and state, and confirm with the user before proceeding.
• If the issue is already closed, say so and ask whether to continue.

If no argument is provided:

• Ask the user for a title and brief description.
• Confirm the target repo (gh repo view --json nameWithOwner for the current one).
• Create it, assigned to the user:

  gh issue create --title "{title}" --body "{description}" --assignee @me
  

• Confirm the new issue number and URL before continuing.