Next Parent

---
name: next-parent
description: >
  Land one GitHub parent issue's remaining open sub-issues
  by running next-issue once per child. Default is the
  parent of the next ready sub-issue. Use when the user
  runs /next-parent or asks to land a parent issue. Do
  not use this for a single sub-issue; that is /next-issue.
user-invocable: true
argument-hint: "[parent issue number or title substring]"
---

# /next-parent

Orchestrator only. It does not replace `/next-issue`.
That skill still lands **one** sub-issue. This skill
picks one parent GitHub issue, then runs `/next-issue`
once per remaining open sub-issue.

The live queue is GitHub Issues. A `parent` issue is a
category. Each sub-issue is one PR. `TODO.md` is an
archive, not the picker.

The project's CLAUDE.md is the architecture contract.
If this skill conflicts with that file or the **Rules**
binding, follow those files.

## Input

Parent: $ARGUMENTS

- Empty → the parent of the next ready or in-progress
  sub-issue (§1).
- A parent issue number, or a unique title substring →
  that parent.

## Binding

Same seven values as `/next-issue`. Read `## Next issue
binding` in the project's CLAUDE.md. If that heading is
missing, read `## Next TODO binding`. If both are
missing, stop and tell the user to run
`/next-issue-init`.

This skill uses **Backlog**, **Plan**, **CI**, and
**Rules**. Plan, TDD, and patch review stay in
`/next-issue`.

## Overlay (every next-issue run)

Pass these into each `/next-issue` invocation. They
override that skill's "one slice then stop" and "branch
from `origin/main`" steps for this session only:

1. GitHub PR base is `main`. Never a feature branch.
2. The first sub-issue branches from `origin/main`. Each
   later sub-issue branches from the previous slice
   HEAD. Later branches may contain earlier slice
   commits. That is a commit stack, not a stacked-PR
   base.
3. Do not open a second PR for a sub-issue that already
   has an open PR against `main`.
4. In the PR body, name predecessor PRs in this stack
   and the slice-only range as two SHAs
   (`<prev-tip>..<slice-tip>`), not a symbolic `HEAD`.
   The first push creates the branch before the draft
   PR exists; write the range into the body when the PR
   opens. Update that range before every later push of
   the slice, including a patch-review or drain fix
   pushed by `next-issue`. The PR body is the recovery
   record. Stop and report if an open PR has no range.
5. Patch review (`next-issue` §4b) reviews the
   slice-only range `<prev-tip>..HEAD` against this
   slice's plan, not `origin/main...HEAD`. Gates still
   run on the whole branch. The same range applies when
   a drain fix triggers patch review again.
6. Do not merge. Do not enqueue on the merge queue
   unless the user asks.

## 1. Choose the parent

1. Fetch `origin/main` when the local default branch may
   be stale.
2. Pick the parent issue:
   - **Default** — no name given. In **Backlog**, find
     the next sub-issue with `ready` or `in-progress`
     (not `blocked`, not a `parent` issue), using each
     parent's Children list, else GitHub sub-issue
     order. A local Plan at **Plan** may refine that
     order for this session. Use that child's parent.
   - **Named** — match a unique substring or issue
     number. If zero names match or several match, stop
     and report. Do not guess.
3. Open that parent. Stop if it carries `blocked`.
4. List every remaining open sub-issue of that parent,
   in Children order. Keep a `blocked` sub-issue in the
   list; §2 evaluates it in turn and stops there. Do not
   filter the list by label. Stop if the list is empty
   and no open PRs remain for this parent.
5. List open PRs against `main` that claim those
   sub-issues.

Then pick a mode:

- **Drain** — every remaining sub-issue already has an
  open PR against `main`, or the user asked only to fix
  review comments. Go to §3.
- **Resume** — some have open PRs and later ones do
  not. Go to §2 for every remaining sub-issue, from the
  first. §2 reuses an existing PR and creates a missing
  one. Do not jump to the first missing sub-issue.
- **Create** — none have an open PR against `main`.
  Confirm local `main` matches `origin/main`. Go to §2.

## Blockers

Before each remaining sub-issue H, in list order, stop
and report if any of these hold. Do not skip H. Do not
start later sub-issues. A parent ordered A (`ready`),
B (`blocked`), C (`ready`) lands A, then stops at B. The
same holds on Resume: A (open PR), B (open PR, now
`blocked`), C (no PR) stops at B and does not create C.

- H or the parent carries `blocked`.
- A Depends-on clause names a predecessor that is not
  closed, or whose change is not on `origin/main`. An
  open PR is not a landing.

## 2. Run next-issue once per sub-issue

For each remaining sub-issue, in order, including one
that already has an open PR:

1. Evaluate blockers. If one holds, stop and report.
2. If an open PR against `main` already claims this
   sub-issue, record its URL and tip SHA. Read the
   range `<recorded-prev-tip>..<recorded-slice-tip>`
   from the PR body and check two things. First,
   `<recorded-slice-tip>` equals the remote slice tip;
   if it does not, the body describes a push that did
   not land, so stop and report. Second,
   `<recorded-prev-tip>` equals the previous slice's
   current tip; an ancestry test alone is not enough,
   because a rewound predecessor still passes it. If
   the two differ, rebase the recorded range onto the
   current tip, run **Gates**, update the range in the
   PR body with the new slice tip, then push with
   `--force-with-lease`. Stop and report if that rebase
   conflicts. Then continue to the next sub-issue from
   that tip. Do not open a second PR.
3. Load `next-issue`. Pass the sub-issue number, that
   this is one slice in a `/next-parent` session, and
   the overlay above. Do not tell it to pick from
   `TODO.md`.
4. Let it plan, review, implement, and open a **draft**
   PR against `main`.
5. Do not wait for human review before the next
   sub-issue. If you push a fix to slice k, rebase the
   later slices in order, each onto the new tip of its
   immediate predecessor
   (`git rebase --onto <new-prev-tip> <old-prev-tip>`),
   run **Gates** on each, update each PR body range, and
   push each with `--force-with-lease` before you
   continue. Stop on a conflict or a failed gate.
6. Record the PR URL and the slice tip SHA, then run
   `next-issue` for the next sub-issue.

After the last sub-issue has a PR, report every PR URL
and the child issue. Stop. Do not merge. Do not start
the next parent.

When a review event arrives, or when the user runs
`/next-parent` again, go to §3.

## 3. Drain through next-issue

Pick the parent the same way as §1. For each open PR in
that parent, in listed order, first run the ancestry
check from §2 step 2, so a stale slice is rebased before
its comments are read. Then load `next-issue` and run
its comment drain (§5 of that skill) on that PR.

After a drain push to slice k, rebase the later slices
in order, each onto the new tip of its immediate
predecessor (`git rebase --onto <new-prev-tip>
<old-prev-tip>`), run **Gates** on each, update each PR
body range, and push each with `--force-with-lease`.
Stop on a conflict or a failed gate.

Stop when the `next-issue` all-clear holds on every
open PR in this parent. Report the URLs. Do not merge
unless the user asks.

## What not to do

- Do not name this skill `next-issue`. That name is the
  one-sub-issue skill.
- Do not pick work from `TODO.md`.
- Do not reimplement plan, TDD, or patch review.
  `next-issue` does that work.
- Do not set PR base to a feature branch.
- Do not combine two sub-issues into one PR.
- Do not start a second parent in this session unless
  the user names it.
- Do not merge or enqueue unless the user asks.