backlog-burndown "Grouping and File Claims" now names one gap in its branch enumeration: a branch in the standalone clone repo-worktree allows as a fallback is reached only once it is pushed, since git branch -r inventories the remote rather than this repository's checkouts. Naming the gap is not the same as handling it, and the same scoping defeats the content read one layer further in.
The gap has no prescribed handling. No bullet says what the orchestrator does about an unpushed standalone-clone branch. In practice it only bites on a hand-driven clone, since this skill's own workers always leave a claim comment, but a hand-driven clone is exactly the case with no claim comment either.
The claim-comment fallback cannot be reached for such a group. The bullet says to check "the claim comments of every group still holding a branch", and nothing in the skill enumerates claim comments independently of a branch: the three reads are the only enumeration given, and "Run State" says working notes hold the group list and do not survive the session. So for a cross-session unpushed group the orchestrator has no read that finds the claim comment at all, since it would have to already know the group exists in order to look it up. A closing fix would be an issue-side enumeration, scanning open issues for unreleased claim comments; the text supplies none.
The uncommitted-work read is scoped out too. The next bullet reads a branch directly with git diff --name-only origin/develop...<branch> for committed work "and, for a registered worktree, git -C <worktree> status --porcelain for what it holds uncommitted", with "Where neither read is available the set is unknown rather than empty" as the escape. A standalone clone is not a registered worktree, so for a live standalone clone's pushed branch only the committed read is available. Because that one read is available, the unknown-rather-than-empty escape never fires, and the branch silently records a narrower file set than it actually holds.
One smaller item in the same bullet: it gives an exact command for the per-pull-request read (gh pr diff <number> --name-only) and none for the enumeration it iterates over, so "the files changed by every open feature pull request on this repository" is not reachable from the unit alone.
Partially adjacent to #1275, which covers other defects in the same bullet, but this is the opposite traversal direction: #1275 is about walking from a branch to its claim, and this is about a group that no branch read reaches at all.
Raised by the local-strict-review carried-content passes on the pull request that added this skill, and deferred there under that skill's own review-round budget.
backlog-burndown"Grouping and File Claims" now names one gap in its branch enumeration: a branch in the standalone clonerepo-worktreeallows as a fallback is reached only once it is pushed, sincegit branch -rinventories the remote rather than this repository's checkouts. Naming the gap is not the same as handling it, and the same scoping defeats the content read one layer further in.The gap has no prescribed handling. No bullet says what the orchestrator does about an unpushed standalone-clone branch. In practice it only bites on a hand-driven clone, since this skill's own workers always leave a claim comment, but a hand-driven clone is exactly the case with no claim comment either.
The claim-comment fallback cannot be reached for such a group. The bullet says to check "the claim comments of every group still holding a branch", and nothing in the skill enumerates claim comments independently of a branch: the three reads are the only enumeration given, and "Run State" says working notes hold the group list and do not survive the session. So for a cross-session unpushed group the orchestrator has no read that finds the claim comment at all, since it would have to already know the group exists in order to look it up. A closing fix would be an issue-side enumeration, scanning open issues for unreleased claim comments; the text supplies none.
The uncommitted-work read is scoped out too. The next bullet reads a branch directly with
git diff --name-only origin/develop...<branch>for committed work "and, for a registered worktree,git -C <worktree> status --porcelainfor what it holds uncommitted", with "Where neither read is available the set is unknown rather than empty" as the escape. A standalone clone is not a registered worktree, so for a live standalone clone's pushed branch only the committed read is available. Because that one read is available, the unknown-rather-than-empty escape never fires, and the branch silently records a narrower file set than it actually holds.One smaller item in the same bullet: it gives an exact command for the per-pull-request read (
gh pr diff <number> --name-only) and none for the enumeration it iterates over, so "the files changed by every open feature pull request on this repository" is not reachable from the unit alone.Partially adjacent to #1275, which covers other defects in the same bullet, but this is the opposite traversal direction: #1275 is about walking from a branch to its claim, and this is about a group that no branch read reaches at all.
Raised by the local-strict-review carried-content passes on the pull request that added this skill, and deferred there under that skill's own review-round budget.