git:20261025.ce024ed to git:20261025.17ee844

---

description: Use when the user wants GitHub issue(s) turned into pull request(s) — fixing, implementing, or addressing an issue and opening a PR for it, whether or not the superpowers skills are installed yet. Triggers on requests like "fix issue #N and open a PR", "turn these issues into PRs", or an issue URL plus a PR request.

---

## Overview

Turn GitHub issue(s) into PR(s) the superpowers way: make sure the superpowers

skills are present (installing them if missing), read the issues, then hand the

work to the normal interactive superpowers flow — brainstorming dialogue with

the human, written plan, TDD implementation, code review, branch finishing —

untouched, and land each issue as its own PR that says `Closes #N`. This skill

orchestrates; it never replaces, shortens, or interrupts the skills it calls.

Merging stays a human call.

## Preflight

1. **Ensure superpowers.** Follow [runtime-detection.md](references/runtime-detection.md):

detect whether the superpowers skills are installed; if not, install them

with `npx skills add https://github.com/obra/superpowers`; if newly installed

skills are not loadable this session, follow them from disk exactly as

written. Do not proceed past this step without superpowers available.

2. **Ensure GitHub access.** Run `gh auth status`. If it fails, have your human

partner authenticate (`gh auth login`) before continuing — issue reading,

pushing, and PR creation all need it.

## Read the issues

For each issue number or URL the user gave:

```bash

gh issue view N --repo OWNER/REPO --json number,title,body,labels,comments,url

```

If the user gave no issue, ask which one(s). One run handles one issue or a

batch — whichever the user asked for.

## Get into the repo

- Already inside the issue's repository checkout: use it.

- Anywhere else: clone it (`gh repo clone OWNER/REPO`), then work from there.

- Check push access once per repo: `gh repo view OWNER/REPO --json viewerPermission`.

`ADMIN`, `MAINTAIN`, or `WRITE` → branch on origin. `TRIAGE`, `READ`, or `NONE`

(or a push later denied) → fork with `gh repo fork --remote` and push the fork.

## Per issue, in order

Work issues strictly one at a time, each fully finished before the next starts.

If the user gave several and no order, propose an order and let them confirm.

For each issue:

1. **Branch.** Cut `issue-N-short-slug` from the default branch — never from

another issue's branch, never commit on the default branch.

2. **Superpowers flow, with the issue as input.** Enter the normal flow and let

each skill run exactly as its own SKILL.md directs. The skills below are the

flow's gates, not an exhaustive list — where superpowers leads beyond them

(using-git-worktrees, executing-plans, receiving-code-review, ...), follow:

- **brainstorming** — a dialogue with the human partner about the issue,

before any implementation. Not a caveat for ambiguous issues: a step,

every time. The human approves the design.

- **writing-plans** — the approved design becomes an implementation plan.

- **test-driven-development** — the implementation happens under TDD:

failing test first, minimal code, refactor. Every change, every time.

- **requesting-code-review** — the finished work gets reviewed before the PR

exists, not after.

- **finishing-a-development-branch** — integration is decided by that skill's

process with the human.

```bash

gh pr create --title "<change summary>" --body "Closes #N

```

## Report

List each issue with its PR URL. Then stop. Never merge, never rebase onto the

default branch, never delete branches **on your own initiative** — those are

human calls. If the human partner explicitly directs an integration action

(merge, branch cleanup), carry it out at their direction through

finishing-a-development-branch's process — this skill's deliverable is the PR,

and unbidden it ends there.

## Rationalizations

| Pressure | Reality |

|---|---|

| "Just make the quick fix, don't overthink it" | The superpowers gates scale down (a smaller design doc, a shorter plan); they are never skipped. "Quick" changes how much process, not whether there is any. |

| "The issue is clear, no need to brainstorm" | Clear to you ≠ agreed with the human. Brainstorming runs; its first question may be its last. |

| "Reproduction is heavy, skip to the fix" | TDD's failing test is the reproduction. Write the smallest test that fails for the issue's reason. |

| "Tests only if the project makes it trivial" | test-driven-development requires the failing-test-first cycle. Difficulty changes the test's size, not its existence. |

| "I'll fork to be safe" | Check `viewerPermission` first; fork only without write access. Forking with access leaves PRs on the wrong remote. |

| "I'll open the PR, review can happen there" | Review comes before the PR opens — that is requesting-code-review's gate, not GitHub's. |

| "Two issues overlap, I'll do them together" | One issue, one branch, one PR — always. Overlap is a question for the human during brainstorming, not a merge of work. |

| "I'll merge it since CI is green" | Merging is a human call. Report the PR and stop. |

## Non-goals

This skill does not triage or pick issues, does not modify any superpowers

skill, and has no fully-autonomous mode: the human partner is in the loop

wherever the superpowers flow puts them.