Summary
The security-advisory draft-card title template, [GHSA-xxxx-yyyy-zzzz] - <advisory summary>, contradicts the rule stated a few lines below it in the same skill: do not copy the vulnerability description onto the card, because project access and advisory access are separate permission sets, so the board's audience is wider than the advisory's.
An advisory summary routinely names the vulnerable component and the attack class ("SSRF in the proxy's …"). Putting it in the title puts exactly that detail in front of everyone with board access, including people who are not advisory collaborators. The body rule ("link and triage metadata only") is undone by the title.
Raised by Copilot on the v2.8.0 milestone-merge PR (#2456: r4079443030, r4079443077, r4079443093). Per the release procedure, a finding on the merge PR is fixed on v2/main, not on the merge branch.
Where the template appears
AGENTS.md (Issue-driven Work Style, the advisory exception): titled [GHSA-xxxx-yyyy-zzzz] - <summary>
.claude/skills/security-advisory/SKILL.md step 1: **Title:** [GHSA-xxxx-yyyy-zzzz] - <advisory summary>
.claude/skills/board-ops/SKILL.md: titled [GHSA-xxxx-yyyy-zzzz] - …
Proposed fix
Make the title generic: [GHSA-xxxx-yyyy-zzzz] - Private security advisory, the same in all three places. The [GHSA- prefix, which the board audit's draft carve-out and the board-ops title lookup both key on, is unchanged, so no query changes. The GHSA id plus the advisory link in the body are enough for anyone with advisory access to find the details.
Why not a release blocker
The boards are private to the org (so this is a wider-than-intended internal audience, not a public leak), and none of these files ship in the npm tarball.
Acceptance
Summary
The security-advisory draft-card title template,
[GHSA-xxxx-yyyy-zzzz] - <advisory summary>, contradicts the rule stated a few lines below it in the same skill: do not copy the vulnerability description onto the card, because project access and advisory access are separate permission sets, so the board's audience is wider than the advisory's.An advisory summary routinely names the vulnerable component and the attack class ("SSRF in the proxy's …"). Putting it in the title puts exactly that detail in front of everyone with board access, including people who are not advisory collaborators. The body rule ("link and triage metadata only") is undone by the title.
Raised by Copilot on the v2.8.0 milestone-merge PR (#2456: r4079443030, r4079443077, r4079443093). Per the release procedure, a finding on the merge PR is fixed on
v2/main, not on the merge branch.Where the template appears
AGENTS.md(Issue-driven Work Style, the advisory exception):titled [GHSA-xxxx-yyyy-zzzz] - <summary>.claude/skills/security-advisory/SKILL.mdstep 1:**Title:** [GHSA-xxxx-yyyy-zzzz] - <advisory summary>.claude/skills/board-ops/SKILL.md:titled [GHSA-xxxx-yyyy-zzzz] - …Proposed fix
Make the title generic:
[GHSA-xxxx-yyyy-zzzz] - Private security advisory, the same in all three places. The[GHSA-prefix, which the board audit's draft carve-out and the board-ops title lookup both key on, is unchanged, so no query changes. The GHSA id plus the advisory link in the body are enough for anyone with advisory access to find the details.Why not a release blocker
The boards are private to the org (so this is a wider-than-intended internal audience, not a public leak), and none of these files ship in the npm tarball.
Acceptance
npm run verify:skillspasses; re-runskills:eval -- security-advisoryif the description changes