GitHub issues to pull requests

Use this workflow for issue-to-PR work. Use gh for GitHub data and mutations, git for the local checkout, and delegate_task only when an isolated subtask is genuinely useful.

Read the bundled github Skill before executing this workflow. GitHub writes, commits, pushes, PR creation, and review replies must stay within the outcome the user requested.

Inputs

• Repository: accept owner/repo or infer it from git remote get-url origin.
• Optional filters: label, milestone, assignee, state, and limit.
• Optional fork: push a branch to a named fork and open the PR against the source repository.
• Dry run: list candidates and planned actions without changing local or remote state.
• Reviews only: skip issue selection and process explicitly scoped PR feedback.

If the user asked only to inspect, triage, or plan, stop before changing files, branches, issues, or PRs.

1. Resolve and verify the repository

git remote get-url origin
git status --short
gh auth status
gh repo view OWNER/REPO --json nameWithOwner,defaultBranchRef

Derive and keep explicit:

• SOURCE_REPO: repository containing the issue.
• PUSH_REPO: fork when explicitly requested, otherwise the source.
• BASE_BRANCH: source default branch unless the user named another.
• PUSH_REMOTE: configured fork remote or origin.

Stop if GitHub authentication is unavailable. Never search local configuration files for tokens, print gh auth token, or ask the user to paste a token into chat.

Do not mix issue work with unrelated uncommitted changes. If the checkout is dirty, preserve those changes and either ask the user how to proceed or create a dedicated git worktree after confirming the repository and base branch.

In fork mode, show the exact source, fork, base branch, and remote before adding or changing a git remote.

2. Fetch candidates