Found in the adversarial review of #120.
PR body says the upstream defects are 'listed in a tracking issue here', but no such issue exists
Where: .claude/skills/update-xmech-page/SKILL.md:233
Under 'Not in this PR' the body says: 'Upstream defects found on the way are sibling-repo issues and are listed in a tracking issue here.' No issue has been filed in CultureBotAI.github.io since 2026-09-22; the newest is #119. The PR also cites no issue number. So the promised record of the defects the audit found does not exist.
Failure scenario. A reviewer or a later refresh looks for the tracking issue to see which upstream defects the 533-claim audit found. There is none, so the findings are lost. This is the outcome the global workflow ('every finding becomes a GitHub issue') and the skill's step 10 are meant to prevent.
Evidence. gh issue list --state all --limit 8 shows #119 (2026-09-22T07:24:39Z) as the newest. gh issue list --state open --json createdAt filtered to after 2026-09-24 returns nothing. The PR has no comments or reviews (gh pr view 120 --json comments,reviews is empty).
Verifier (confirmed, medium). I reproduced the finding. The PR body says in the present tense that the upstream defects "are listed in a tracking issue here", but no issue was filed in CultureBotAI/CultureBotAI.github.io after #119 (2026-09-22). The body cites no issue number, and the PR has no comments that could hold the list. I also found no sibling-repo issue tied to this refresh, so as far as GitHub shows, the defects the 533-claim audit found upstream are recorded nowhere.
The step 10 wording doesn't excuse this. These defects came from the step-5 audit, which ran before the PR was opened, not from the post-PR review. And the body describes the tracking issue as already existing, not as something planned.
Consequences:
- The PR description misleads the person who decides the merge.
- The audit's upstream findings exist only in the session scratchpad. That is the outcome the global rule ("Every finding becomes a GitHub issue") and the skill's step 10 exist to prevent.
The deployed site is not affected, and fixing this only means filing the issue and editing the body. That keeps it at medium rather than high.
Minor correction to the finding: the defect lives in the PR body, not at SKILL.md:233. That line is step 10, the rule being broken.
Separate from this finding, I noticed the body opens with "Closes #85, #107, #113.", but closingIssuesReferences lists only #85. So #107 and #113 will not auto-close, which is the exact trap SKILL.md:242 warns about.
Suggested fix. File the tracking issue and cite its number in the PR body, or reword the sentence until it exists.
Found in the adversarial review of #120.
PR body says the upstream defects are 'listed in a tracking issue here', but no such issue exists
Where:
.claude/skills/update-xmech-page/SKILL.md:233Under 'Not in this PR' the body says: 'Upstream defects found on the way are sibling-repo issues and are listed in a tracking issue here.' No issue has been filed in CultureBotAI.github.io since 2026-09-22; the newest is #119. The PR also cites no issue number. So the promised record of the defects the audit found does not exist.
Failure scenario. A reviewer or a later refresh looks for the tracking issue to see which upstream defects the 533-claim audit found. There is none, so the findings are lost. This is the outcome the global workflow ('every finding becomes a GitHub issue') and the skill's step 10 are meant to prevent.
Evidence.
gh issue list --state all --limit 8shows #119 (2026-09-22T07:24:39Z) as the newest.gh issue list --state open --json createdAtfiltered to after 2026-09-24 returns nothing. The PR has no comments or reviews (gh pr view 120 --json comments,reviewsis empty).Verifier (confirmed, medium). I reproduced the finding. The PR body says in the present tense that the upstream defects "are listed in a tracking issue here", but no issue was filed in CultureBotAI/CultureBotAI.github.io after #119 (2026-09-22). The body cites no issue number, and the PR has no comments that could hold the list. I also found no sibling-repo issue tied to this refresh, so as far as GitHub shows, the defects the 533-claim audit found upstream are recorded nowhere.
The step 10 wording doesn't excuse this. These defects came from the step-5 audit, which ran before the PR was opened, not from the post-PR review. And the body describes the tracking issue as already existing, not as something planned.
Consequences:
The deployed site is not affected, and fixing this only means filing the issue and editing the body. That keeps it at medium rather than high.
Minor correction to the finding: the defect lives in the PR body, not at SKILL.md:233. That line is step 10, the rule being broken.
Separate from this finding, I noticed the body opens with "Closes #85, #107, #113.", but
closingIssuesReferenceslists only #85. So #107 and #113 will not auto-close, which is the exact trap SKILL.md:242 warns about.Suggested fix. File the tracking issue and cite its number in the PR body, or reword the sentence until it exists.