GIP — Grab Issues in Parallel

Grab a batch of open issues and work them at the same time — one subagent per issue, each in its own git worktree, each running the full grab-issue flow (claim → check history → open draft PR → implement → mark ready → ARDI to clean). Then assemble one combined report.

This is the parallel counterpart to gii, which is deliberately serial. The whole job of this skill is to safely lift that serialization — and that is only safe for issues that are provably independent. Read The independence gate before fanning anything out; it is the load-bearing part.

When this fires

• “gip”, “grab issues in parallel”, “do these issues concurrently”
• “work several issues at once”, “parallelize the backlog”, “fan out the issue queue”, “spin up a worker per issue”

It does not fire for a single issue (use gi) or when the issues are interdependent / stacked (use gii, which stacks).

Why gii is serial — and when parallel is safe

gii runs one issue at a time on purpose, for three reasons:

1. Base-branch stacking — a later issue’s branch may depend on a prior MR that hasn’t merged yet, so it must branch from that MR’s tip, not main.
2. Same-file conflicts — two issues that edit the same files produce guaranteed merge conflicts if worked in parallel.
3. Shared working tree — a single checkout can’t hold two in-progress branches at once.

Parallel is safe only when (1) and (2) don’t apply and (3) is removed by worktree isolation. So this skill fans out only the independent subset and sends everything else back to the serial path.

Procedure

0. Establish context (orchestrator, once)

Detect the forge (GitHub gh / GitLab glab) from git remote get-url origin and note the default branch. Resolve <owner>/<repo> once so you can pass it to every subagent. In a remote/web session, gh may be absent — use the GitHub MCP tools instead (e.g. mcp__github__add_issue_comment, mcp__github__create_pull_request, mcp__github__search_pull_requests).

1. Enumerate and triage (orchestrator)

List the open issues and prioritize them exactly as gi does. Decide which issues are in scope for this batch (respect any the user named).

2. The independence gate (orchestrator — do NOT skip)

Partition the in-scope issues into an independent set (safe to parallelize) and a dependent remainder (must stay serial). An issue belongs in the independent set only if all hold:

• No stacking dependency — it can branch straight from origin/main; it doesn’t need another in-flight issue’s unmerged branch as its base.
• No file overlap — its likely touched files don’t intersect any other in-batch issue’s likely files. When in doubt, read the issues and sketch each one’s probable file footprint; if two plausibly collide, treat them as dependent.
• Not blocked — no “blocked by #N” / “depends on #N” marker pointing at another open item.

Anything failing a check drops to the dependent remainder. If two issues overlap only with each other, keep one in the independent set and defer the other to the remainder — don’t fan out both.

When unsure, serialize. A false “independent” call costs a merge conflict and a confused review; a false “dependent” call only costs some wall-clock time. Bias toward the remainder.

If the independent set has 0 or 1 issues, there’s nothing to parallelize — hand off to gii (serial) and stop here.

3. Pick the concurrency cap (orchestrator)

Fan out at most N at once (default N = 3). Bound it because every subagent pushes commits, triggers a review workflow, and polls for the result — too many at once swamps shared CI runners and the review bot (the same runner-contention reason ardia processes PRs one at a time). If the independent set is larger than N, run it in waves of N.

4. Fan out — one worktree-isolated subagent per issue (concurrent)

Spawn the wave in a single message with multiple Agent calls so they run at once. Give every subagent isolation: "worktree" — that hands each one its own working directory over the shared .git, so concurrent edits, branches, and commits never collide on one checkout. (This is the subagent form of the same isolation session-lock sets up for independent top-level sessions.)

A subagent starts fresh — it sees only the prompt you hand it, not this skill file — so inline the entire per-issue procedure. Don’t point it at gi/ardi; restate the steps. Fill in <N>, <title>, <owner>, <repo>, and the default branch for each issue:

Work GitHub issue # (“