What happened
skills/implement-issue-workflow/SKILL.md, under PR Integration, prescribes:
gh pr merge <number> --rebase --delete-branch
and follows it with an explicit list of warning signs that should stop an agent
from integrating automatically:
failed or unknown checks, unresolved merge state, a diverged local branch,
unpushed local commits, uncertain PR state, or unclear branch ownership
A dependent pull request is not on that list, and it is the one warning sign
the command itself creates. --delete-branch removes the base branch; GitHub
then closes every pull request targeting it, and a closed pull request's base can
be neither retargeted nor reopened. The dependent PR must be recreated, losing
its review history.
Why it is worth a rule rather than care
Stacking is not exotic under this workflow — it is what the workflow produces.
skills/slice-issues/SKILL.md encourages splitting an issue into reviewable
slices, and a slice that names terms or types introduced by the slice below it
has to branch from that branch rather than from main. The method creates the
situation and the integration step does not mention it.
We have now paid for it twice in the same repository: once when a PR had to be
recreated, and again two weeks later, after the lesson had been written down
locally. The second time is the interesting one — the note existed and was not
read, which suggests the guidance belongs where the command is, not in a
project's own notes.
Suggested change
Two small additions to PR Integration:
- Add dependent pull requests to the warning-signs list — before integrating,
check whether any open PR targets this branch.
- State the ordering rule next to the command: retarget dependents to the base
branch first, then integrate.
Something like:
Before integrating with --delete-branch, check for pull requests that target
this branch (gh pr list --base <branch>). Deleting the branch closes them,
and a closed pull request cannot be retargeted or reopened. Retarget them
first.
skills/post-merge-sync/SKILL.md already reasons carefully about which branch is
the base; this is the same concern one step earlier.
Context
Found while using the toolkit on a private project that vendors it. Happy to open
a PR if the shape looks right.
What happened
skills/implement-issue-workflow/SKILL.md, under PR Integration, prescribes:and follows it with an explicit list of warning signs that should stop an agent
from integrating automatically:
A dependent pull request is not on that list, and it is the one warning sign
the command itself creates.
--delete-branchremoves the base branch; GitHubthen closes every pull request targeting it, and a closed pull request's base can
be neither retargeted nor reopened. The dependent PR must be recreated, losing
its review history.
Why it is worth a rule rather than care
Stacking is not exotic under this workflow — it is what the workflow produces.
skills/slice-issues/SKILL.mdencourages splitting an issue into reviewableslices, and a slice that names terms or types introduced by the slice below it
has to branch from that branch rather than from
main. The method creates thesituation and the integration step does not mention it.
We have now paid for it twice in the same repository: once when a PR had to be
recreated, and again two weeks later, after the lesson had been written down
locally. The second time is the interesting one — the note existed and was not
read, which suggests the guidance belongs where the command is, not in a
project's own notes.
Suggested change
Two small additions to PR Integration:
check whether any open PR targets this branch.
branch first, then integrate.
Something like:
skills/post-merge-sync/SKILL.mdalready reasons carefully about which branch isthe base; this is the same concern one step earlier.
Context
Found while using the toolkit on a private project that vendors it. Happy to open
a PR if the shape looks right.