$npx -y skills add apache/magpie --skill security-issue-triageFor each open <tracker> issue carrying the needs triage label, read body + comments and classify the candidate disposition into one of six classes: VALID / DEFENSE-IN-DEPTH / INFO-ONLY / INVALID / PROBABLE-DUP / FIX-ALREADY-PUBLIC. On user confirmation, posts a triage-proposa
| 1 | <!-- Placeholder convention (see AGENTS.md#placeholder-convention-used-in-skill-files): |
| 2 | <project-config> → adopting project's `.apache-magpie/` directory |
| 3 | <tracker> → value of `tracker_repo:` in <project-config>/project.md |
| 4 | <upstream> → value of `upstream_repo:` in <project-config>/project.md |
| 5 | <security-list> → value of `security_list:` in <project-config>/project.md |
| 6 | Before running any bash command below, substitute these with the |
| 7 | concrete values from the adopting project's <project-config>/project.md. --> |
| 8 | |
| 9 | # security-issue-triage |
| 10 | |
| 11 | This skill is the **initial-triage discussion-starter** for security |
| 12 | tracker issues. For each [`<tracker>`](https://github.com/<tracker>) |
| 13 | issue carrying the `needs triage` label, it reads the body + comments, |
| 14 | applies the project's Security Model framing, classifies the candidate |
| 15 | disposition, and — on the user's explicit confirmation — posts a |
| 16 | triage-proposal comment that invites the security team to react. |
| 17 | |
| 18 | The skill **never flips `needs triage` to a scope label**, **never |
| 19 | closes**, **never allocates a CVE**, **never edits the body**. The |
| 20 | valid / invalid decision belongs to team consensus; this skill opens |
| 21 | the discussion that produces it, and the sibling skills below apply |
| 22 | the state change once consensus lands. |
| 23 | |
| 24 | It composes with: |
| 25 | |
| 26 | - [`security-issue-import`](../security-issue-import/SKILL.md) — the |
| 27 | on-ramp that creates `Needs triage` trackers; triage is the natural |
| 28 | next step after a batch lands. |
| 29 | - [`security-cve-allocate`](../security-cve-allocate/SKILL.md) — |
| 30 | invoked by hand after the team agrees a tracker is **VALID**. |
| 31 | - [`security-issue-invalidate`](../security-issue-invalidate/SKILL.md) — |
| 32 | invoked by hand after the team agrees a tracker is **INVALID** |
| 33 | or **INFO-ONLY**. |
| 34 | - [`security-issue-deduplicate`](../security-issue-deduplicate/SKILL.md) — |
| 35 | invoked by hand after the team agrees a tracker is a **PROBABLE-DUP**. |
| 36 | - [`security-issue-sync`](../security-issue-sync/SKILL.md) — picks up |
| 37 | after the team's decision lands; flips `needs triage` → scope label, |
| 38 | records the disposition in the rollup, and propagates to the project |
| 39 | board. |
| 40 | |
| 41 | --- |
| 42 | |
| 43 | ## Golden rules |
| 44 | |
| 45 | **Golden rule 1 — read-only on tracker state.** This skill posts |
| 46 | discussion comments and nothing else. No `gh issue edit`, no label |
| 47 | mutations, no body PATCH, no project-board column moves, no CVE |
| 48 | allocation. The skill's output is *text on the tracker that invites |
| 49 | reaction*; the team's reply (in subsequent comments) is what drives |
| 50 | state change, applied later by the sibling skills above. |
| 51 | |
| 52 | **Golden rule 2 — every comment is a draft until the user |
| 53 | confirms.** Triage proposals are public(-ish) comments on the |
| 54 | `<tracker>` repo, attributed to the security-team member who |
| 55 | invoked the skill. Per the "draft before send" rule in |
| 56 | [`AGENTS.md`](../../AGENTS.md), every comment is drafted, shown |
| 57 | to the user, and posted only after explicit confirmation. The fact |
| 58 | that the user invoked the skill is **not** a blanket "yes" — the |
| 59 | text of each comment is reviewed individually. |
| 60 | |
| 61 | **Golden rule 3 — standalone comments, not rollup entries.** |
| 62 | Triage proposals are discussion-starters that need to be visible |
| 63 | at-a-glance to the human reviewers. The |
| 64 | [rollup convention](../../tools/github/status-rollup.md) |
| 65 | collapses entries inside `<details>` blocks; that's the right |
| 66 | shape for bot status updates but the wrong shape for a comment |
| 67 | that says *"team, do you agree?"*. Post these as top-level |
| 68 | comments. Once the team's decision lands and a sibling skill |
| 69 | applies the state change, *that* state change goes into the rollup |
| 70 | as |