security-advisory skill: allow full advisory details on the GHSA draft card (board audience is managed) #2851

Summary

The security-advisory skill tells a maintainer to keep a GHSA draft card to the advisory link and triage metadata only. It forbids copying the vulnerability description, reproduction, or PoC onto the card. The stated reason is that project access and advisory access are separate permission sets, so the board's audience might be wider than the advisory's.

That premise does not hold in practice: access to board #28 is managed, so the people who can read a card are the people who should be handling the advisory. The rule therefore costs something real and buys nothing:

• The analysis has nowhere useful to live. Security advisories have no comment API (REST or GraphQL), so research, repro results, an ownership verdict and a fix plan cannot be scripted into the advisory thread. The card is the one place the team can see them.
• It strips the reasoning out of the Priority score. Step 1 deliberately records the score as "numbers and rubric names only" and pushes the justification into the private advisory, because the justification is the impact. So a card's Priority reads as a bare number nobody can argue with.
• Following it was already overridden in practice to put a full verification write-up on a card, which leaves the skill describing a practice the team does not follow.

Change

In .claude/skills/security-advisory/SKILL.md:

• Step 1, the "Do not copy the vulnerability description onto the card" warning: replace it with guidance that the card may carry the full analysis. That covers the description, reproduction, ownership verdict, affected lines and fix plan. State the premise this rests on (board access is managed), so that if board access is ever widened, the rule has an obvious trigger to revisit.
• Step 1, the score note: drop the "numbers and rubric names only — deliberately not the comment form" restriction. The score can carry its free-text justification, like an ordinary /issue-triage score comment.
• Keep the parts that are about publication, not the board. Nothing on the card changes the rules that a public issue is created only after the advisory is published (step 6), and that an upstream finding goes through the upstream's private channel. A card is still private; a converted issue is not. Say explicitly that converting the card in step 6 makes its body public, so the body must be reviewed or trimmed before conversion, even though publication has already disclosed the vulnerability.

Check board-ops and AGENTS.md for any restatement of the old rule, and update them in the same change.

Out of scope

• The draft-card title template. A generic title was proposed and closed as not planned in security-advisory: the GHSA draft-card title copies the advisory summary onto the board #2457, and this change does not reopen it.
• Board placement, affected versions and reporter on the card, which GHSA draft cards: place on the board for the affected line, and include affected versions + reporter #2462 tracks.

Acceptance

• The skill no longer forbids details on the card, and it states the managed-audience premise
• Step 1's score note allows a justified score
• Step 6 warns that converting makes the card body public
• No other file restates the old rule
• npm run verify:skills passes, and skills:eval -- security-advisory is re-run if the description changes