skills/clean-branches/SKILL.md:153-158 tells the reader to check for active
work claims, and gives an empty code block to do it with:
# Look for recent "working on this" / claim comments on any linked MR/issue
The comment names a wording (working on this), the fence contains no command,
and there is no release-term handling. So the step is unrunnable as written and
each session improvises its own matcher.
Why it matters here
shared/workflow/claim-pr.md now specifies the matcher precisely: match the
invariant hold off, plus the retired paws off and back off,
case-insensitively, then exclude the comment when it also carries a release term
(unclaim|released|PR is free|now mergeable) --- because the retired release
wording ... done --- paws off released. contains paws off and would
otherwise read as a live claim.
Five other claim readers were brought onto that matcher in
#2131. This one was not,
because it names no wording, so a rename sweep cannot find it. It is a claim
reader that a grep for claim wordings is blind to by construction.
The consequence is the mild direction --- clean-branches deletes branches, and
an improvised matcher that misses a claim reads a claimed branch as unclaimed.
That is a deletion, not a skip.
Suggested fix
Replace the empty fence with the canonical query, and cite claim-pr for the
matcher rather than restating it:
gh pr view <N> --json comments \
-q '.comments[] | select(.body | test("hold off|paws off|back off"; "i"))
| select((.body | test("unclaim|released|PR is free|now mergeable"; "i")) | not)
| "\(.author.login): \(.body)"' # READ_PR_COMMENTSThe 24-hour window this skill uses is deliberately wider than claim-pr's
2-hour expiry and should stay as it is; only the matcher is missing.
Wider question
Whether any other skill reads claims without naming a wording, and so is
invisible to a wording-based sweep. grep -rln "claim comment\|working on this" skills/ is a starting point, but by construction it cannot be complete --- the
same reason this one was missed.
skills/clean-branches/SKILL.md:153-158tells the reader to check for activework claims, and gives an empty code block to do it with:
# Look for recent "working on this" / claim comments on any linked MR/issueThe comment names a wording (
working on this), the fence contains no command,and there is no release-term handling. So the step is unrunnable as written and
each session improvises its own matcher.
Why it matters here
shared/workflow/claim-pr.mdnow specifies the matcher precisely: match theinvariant
hold off, plus the retiredpaws offandback off,case-insensitively, then exclude the comment when it also carries a release term
(
unclaim|released|PR is free|now mergeable) --- because the retired releasewording
... done --- paws off released.containspaws offand wouldotherwise read as a live claim.
Five other claim readers were brought onto that matcher in
#2131. This one was not,
because it names no wording, so a rename sweep cannot find it. It is a claim
reader that a grep for claim wordings is blind to by construction.
The consequence is the mild direction ---
clean-branchesdeletes branches, andan improvised matcher that misses a claim reads a claimed branch as unclaimed.
That is a deletion, not a skip.
Suggested fix
Replace the empty fence with the canonical query, and cite
claim-prfor thematcher rather than restating it:
The 24-hour window this skill uses is deliberately wider than
claim-pr's2-hour expiry and should stay as it is; only the matcher is missing.
Wider question
Whether any other skill reads claims without naming a wording, and so is
invisible to a wording-based sweep.
grep -rln "claim comment\|working on this" skills/is a starting point, but by construction it cannot be complete --- thesame reason this one was missed.