Coder/deepseek-harness
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

docs: check dependents per-branch with --base, not a capped sweep

Browse Source 
Review comment on the verify step: dumping every open PR under
--limit 1000 wastes agent context and re-truncates past 1000. Ask the
exact question server-side instead: gh pr list --state open
--base <branch> --json number --jq length, whose output is a single
count that is exact at any number of open PRs. Skill, checklist, and
the cookbook dependent-check line all use the per-branch form.
This commit is contained in:
Tianyi Cui
2026-07-06 01:15:32 +08:00
parent 60f7a592b3
commit 3b145bff5c
2 changed files with 5 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

8
.agents/skills/dsh-merging-stacked-prs/SKILL.md
View File

@@ -32,13 +32,13 @@ Each retarget step merges the freshly-updated master back into the dependent bra
## Verify before deleting anything ## Verify before deleting anything
Before *any* branch delete, confirm nothing still depends on it: Before deleting a branch, ask GitHub directly whether any open PR still bases on it:
```sh ```sh
gh pr list --state open --limit 1000 --json number,baseRefName gh pr list --state open --base <branch> --json number --jq length
``` ```
The explicit `--limit` matters: without it the list is paginated, and a dependent past the first page would make deletion look safe when it is not. If any open PR's `baseRefName` is a branch you're about to delete, **do not delete it** — that PR will auto-close. Default to merging without `--delete-branch` throughout, and do the deletions as a separate final pass once the list shows no open dependents. Anything other than `0` means deleting `<branch>` auto-closes that many open PRs — do not delete it. The `--base` filter is applied server-side, so the answer is exact no matter how many PRs are open, and the output is a single number. Default to merging without `--delete-branch` throughout, and do the deletions as a separate final pass once every branch you're about to delete reports `0`.
## Longer chains ## Longer chains
@@ -48,5 +48,5 @@ The pattern extends to any depth. For `A ← B ← C ← D ← …`, walk the st
- [ ] Merge bottom PR first, `--merge`, no `--delete-branch`; wait until `gh pr view <n> --json state` shows `MERGED`. - [ ] Merge bottom PR first, `--merge`, no `--delete-branch`; wait until `gh pr view <n> --json state` shows `MERGED`.
- [ ] For each dependent: `gh pr edit <n> --base master` → fetch and merge `origin/master` into the branch (resolve conflicts there, push) → `gh pr merge <n> --merge`, no `--delete-branch`; again wait for `MERGED`. - [ ] For each dependent: `gh pr edit <n> --base master` → fetch and merge `origin/master` into the branch (resolve conflicts there, push) → `gh pr merge <n> --merge`, no `--delete-branch`; again wait for `MERGED`.
- [ ] Run `gh pr list --state open --limit 1000 --json number,baseRefName` to confirm no open dependents remain. - [ ] Before each branch delete: `gh pr list --state open --base <branch> --json number --jq length` prints `0`.
- [ ] Delete all branches (local + remote) only as a final pass. - [ ] Delete all branches (local + remote) only as a final pass.

2
docs/cookbook/responding-to-pr-review-on-a-stack.md
View File

@@ -15,7 +15,7 @@ A wave of review comments lands across several PRs in a dependent stack (`A ←
2. Map each accepted finding to its originating PR, fix it there, then merge down the chain in order. 2. Map each accepted finding to its originating PR, fix it there, then merge down the chain in order.
3. Delegated fixes are trust-but-verify: a sub-agent's report describes intent, not necessarily what landed. Re-run the gates yourself on the actual tree, and for a regression guard, prove it FAILS on the unfixed code (introduce the regression, watch red, revert) — a guard that passes both ways guards nothing. A sub-agent that reframes a problem as already-handled is a signal to dig in personally. 3. Delegated fixes are trust-but-verify: a sub-agent's report describes intent, not necessarily what landed. Re-run the gates yourself on the actual tree, and for a regression guard, prove it FAILS on the unfixed code (introduce the regression, watch red, revert) — a guard that passes both ways guards nothing. A sub-agent that reframes a problem as already-handled is a signal to dig in personally.
4. Reply in the review thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level comment, stating the fix and the commit that carries it. 4. Reply in the review thread (`gh api repos/{owner}/{repo}/pulls/{pr}/comments/{id}/replies`), not as a top-level comment, stating the fix and the commit that carries it.
5. Before merging the stack, check dependents: deleting a PR's base branch auto-closes the dependent PR — `gh pr list --state open --limit 1000 --json number,baseRefName` first (the explicit `--limit` defeats pagination), and merge without `--delete-branch` where a child still bases on the branch. The full landing procedure is the [dsh-merging-stacked-prs](../../.agents/skills/dsh-merging-stacked-prs/SKILL.md) skill. 5. Before merging the stack, check dependents: deleting a PR's base branch auto-closes the dependent PR — check each branch with `gh pr list --state open --base <branch> --json number --jq length` (non-zero = open dependents), and merge without `--delete-branch` where a child still bases on the branch. The full landing procedure is the [dsh-merging-stacked-prs](../../.agents/skills/dsh-merging-stacked-prs/SKILL.md) skill.
## Verify ## Verify