From f368be40c42aa5a6501dc090f66209dff656467b Mon Sep 17 00:00:00 2001 From: Claude Date: Sat, 1 Aug 2026 05:28:29 +0000 Subject: [PATCH] fix(gip): spell the base branch as throughout PR #1008 parameterized the base branch across this file but left two prescriptive instances reading the literal `main`, so one file now gave the same instruction two ways. Deferred there rather than fixed, correctly: both lines were byte-identical to `main`, so editing them on that branch would have put it out of step. #1008 has since merged, which is the follow-up its own rule prescribes. Line 71 read `origin/main` where the surrounding steps prescribe `origin/`; line 40 named `main` as the base an issue branches from. Both now name the parameter. Left alone: the two occurrences that are evidence rather than instruction -- the sentence naming the literal string `main` as the thing not to hard-code, and the verbatim `fatal: invalid reference: origin/main` a reader will match against their own terminal. Line 71's em-dash became this diff's to fix once the line was edited, so it is now `--`. --- skills/gip/SKILL.md | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/skills/gip/SKILL.md b/skills/gip/SKILL.md index b5c14ba27..3b977b1ea 100644 --- a/skills/gip/SKILL.md +++ b/skills/gip/SKILL.md @@ -37,7 +37,8 @@ issues are interdependent / stacked (use [`gii`](../gii/SKILL.md), which stacks) `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`. + that hasn't merged yet, so it must branch from that MR's tip, not + ``. 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 @@ -68,8 +69,9 @@ 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 stacking dependency** -- it can branch straight from + `origin/`; 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