Document the GitHub security advisory flow as a skill, and reconcile the two rules it contradicts

Privately reported vulnerabilities arrive through GitHub's security advisory flow (see SECURITY.md), and nothing in this repo writes that procedure down. Sixteen advisories are currently open in triage, each with a hand-made draft card on board #28, and the steps from "an advisory arrived" to "the fix shipped and the advisory is published" live only in a maintainer's head.

Two rules also contradict the practice that has grown up around it, so documenting the flow alone is not enough.

What to add

1. A new security-advisory skill covering the whole flow:

• Advisory arrives in triage → a draft card on board #28 titled [GHSA-xxxx-yyyy-zzzz] - <summary>, Status Incoming plus a Priority.
• Verify the claim, including who owns the code path. #2409 is the precedent: a loopback/HTTPS-exemption finding that turned out to live in @modelcontextprotocol/client (typescript-sdk#2591), not here. The reporter withdrew it.
• Valid → accept (triage → draft). Invalid → close with a reasoned comment. Accepting is outward-facing and stays human-gated.
• Accepted → create the private fork, fix and review there.
• Merge, release, then publish — irreversible, assigns a CVE, credits the reporter, and stays human-gated.
• After release, file the public (closed) issue and convert the board card.

It also has to record the API facts that are easy to get wrong: the private-fork POST creates a fork rather than probing for one (read the advisory's private_fork field first), there is no comment API for advisories in REST or GraphQL so reporter coordination is UI-only, deleting a private fork needs a delete_repo scope a default gh token lacks, and no PROJECT_TOKEN exists in this org so the board step cannot be automated from Actions.

2. An AGENTS.md amendment. "Every board item is a real GitHub issue. No draft cards." is currently absolute, and the sixteen advisory cards violate it by design: an advisory is private and a public issue would disclose it before a fix exists. Carve them out as the one exception, and add the skill to the Skills index.

3. A board-audit carve-out in the issue-triage skill. The non-Issue on a board check counts draft cards, so it reports 16 today and will keep doing so — a check that is permanently non-zero stops carrying signal. The carve-out must be narrow enough that other drafts are still reported; matching the [GHSA- title prefix is the discriminator.

Plus eval cases for the new skill, per the skills rules in AGENTS.md.

Out of scope

Building a workflow that boards advisory cards automatically. organization projects: write is a permission GITHUB_TOKEN structurally cannot hold and this org has no PROJECT_TOKEN, so that approach is closed; the skill says so rather than leaving it to be rediscovered.

Start by reading SECURITY.md, AGENTS.md, the existing issue-triage skill, and the skills index and eval cases. Document the complete private advisory flow, add the narrow GHSA draft-card exceptions and new skill, and ensure the eval cases cover the documented rules and API limitations.