Found in the adversarial review of #120.
'Closes #113' is false: the nightly card check stays red after merge, which is exactly what #113 tracks; and only #85 is actually linked
Where: .claude/skills/update-xmech-page/SKILL.md:241
The PR body says Closes #85, #107, #113. #113 was filed to track that the scheduled check_cards.py run is red ('This issue tracks that the nightly is expected red until then'). This PR ships with two cards drifted (CellStructureMech and TraitMech), and the PR body says so. check_cards.py still exits 1, so the nightly stays red and #113's title stays true. Separately, GitHub links only the first number after a closing keyword. closingIssuesReferences is [85], so #107 and #113 will not auto-close. Step 10 of the skill then says to close by hand every issue the PR 'resolved' that GitHub did not auto-close. Following it would close #113 while its condition still holds. It would also be done without the per-issue confirmation that review-open-issues requires for closing issues.
Failure scenario. The PR is merged and the scheduled run at 07:23 UTC fails on the two drifted cards. The agent follows step 10, reads the PR's 'Closes' list and closes #113 by hand. The only record that the red nightly is known and expected is gone. Meanwhile the next person sees a closed #113 next to a failing workflow.
Evidence. python3 scripts/fleet/check_cards.py on the branch prints DRIFTED CellStructureMech card 542, site 545 and DRIFTED TraitMech card 763, site 764, then 8 match, 2 drifted, 0 unreadable. with exit=1. gh run list --workflow fleet-page.yml shows the schedule runs on main failing on 09-22, 09-23 and 09-24. gh pr view 120 --json closingIssuesReferences returns [85]. The #113 body says: 'This issue tracks that the nightly is expected red until then… The refresh belongs with the full pipeline rerun owed for #84 and #87', and this PR leaves #84 and #87 open. SKILL.md:241-242 reads '…close issues the PR resolved that GitHub did not auto-close. GitHub honours only the first number after a closing keyword.' review-open-issues SKILL.md:317 reads 'closing an issue or touching a tracker requires explicit confirmation.'
Verifier (partly, low). "Closes #85, #107, #113" links only #85 on GitHub. The skill tells the agent to close #107 and #113 by hand after merge. #113 should not be closed that way. Its specific figures were refreshed, but the condition it records still holds after merge: the nightly check_cards.py run is red because CellStructureMech is 542 vs 545 and TraitMech is 763 vs 764. No other open issue tracks that. The fix is to keep #113 open with a comment updating it to the two remaining drifts, or to file a replacement before closing it. It is also cleaner to write a keyword before each issue, as in "Closes #85. Closes #107." The part about per-issue confirmation does not apply. The review-open-issues rule governs that skill's triage sweep, not a post-merge close of issues listed in an approved PR.
Suggested fix. Drop #113 from the closing list, or comment on it with the two remaining drifts and keep it open. Write the keyword before each issue (Closes #85. Closes #107.). In step 10, ask for confirmation of each manual close and require the issue's condition to be re-checked first.
Found in the adversarial review of #120.
'Closes #113' is false: the nightly card check stays red after merge, which is exactly what #113 tracks; and only #85 is actually linked
Where:
.claude/skills/update-xmech-page/SKILL.md:241The PR body says
Closes #85, #107, #113.#113 was filed to track that the scheduled check_cards.py run is red ('This issue tracks that the nightly is expected red until then'). This PR ships with two cards drifted (CellStructureMech and TraitMech), and the PR body says so. check_cards.py still exits 1, so the nightly stays red and #113's title stays true. Separately, GitHub links only the first number after a closing keyword. closingIssuesReferences is [85], so #107 and #113 will not auto-close. Step 10 of the skill then says to close by hand every issue the PR 'resolved' that GitHub did not auto-close. Following it would close #113 while its condition still holds. It would also be done without the per-issue confirmation that review-open-issues requires for closing issues.Failure scenario. The PR is merged and the scheduled run at 07:23 UTC fails on the two drifted cards. The agent follows step 10, reads the PR's 'Closes' list and closes #113 by hand. The only record that the red nightly is known and expected is gone. Meanwhile the next person sees a closed #113 next to a failing workflow.
Evidence.
python3 scripts/fleet/check_cards.pyon the branch printsDRIFTED CellStructureMech card 542, site 545andDRIFTED TraitMech card 763, site 764, then8 match, 2 drifted, 0 unreadable.with exit=1.gh run list --workflow fleet-page.ymlshows the schedule runs on main failing on 09-22, 09-23 and 09-24.gh pr view 120 --json closingIssuesReferencesreturns[85]. The #113 body says: 'This issue tracks that the nightly is expected red until then… The refresh belongs with the full pipeline rerun owed for #84 and #87', and this PR leaves #84 and #87 open. SKILL.md:241-242 reads '…close issues the PR resolved that GitHub did not auto-close. GitHub honours only the first number after a closing keyword.' review-open-issues SKILL.md:317 reads 'closing an issue or touching a tracker requires explicit confirmation.'Verifier (partly, low). "Closes #85, #107, #113" links only #85 on GitHub. The skill tells the agent to close #107 and #113 by hand after merge. #113 should not be closed that way. Its specific figures were refreshed, but the condition it records still holds after merge: the nightly check_cards.py run is red because CellStructureMech is 542 vs 545 and TraitMech is 763 vs 764. No other open issue tracks that. The fix is to keep #113 open with a comment updating it to the two remaining drifts, or to file a replacement before closing it. It is also cleaner to write a keyword before each issue, as in "Closes #85. Closes #107." The part about per-issue confirmation does not apply. The review-open-issues rule governs that skill's triage sweep, not a post-merge close of issues listed in an approved PR.
Suggested fix. Drop #113 from the closing list, or comment on it with the two remaining drifts and keep it open. Write the keyword before each issue (
Closes #85. Closes #107.). In step 10, ask for confirmation of each manual close and require the issue's condition to be re-checked first.