git:20260928.2be8667 to git:20260928.daf6b27

---

# SPDX-License-Identifier: Apache-2.0

# https://www.apache.org/licenses/LICENSE-2.0

name: issue-triage

family: security

mode: Triage

requires_config:

- project.md

- scope-labels.md

- security-model.md

- release-trains.md

- canned-responses.md

description: |

Classify each `needs triage` tracker as VALID / DEFENSE-IN-DEPTH /

INFO-ONLY / INVALID / PROBABLE-DUP / FIX-ALREADY-PUBLIC and, on

confirmation, post a triage-proposal comment for the team.

Read-only on tracker state. `--retriage` reopens a decided case after

new activity.

when_to_use: |

"triage open issues", "propose dispositions for the needs-triage

queue", or after an import. Once the team has decided, go straight

to cve-allocate, invalidate or deduplicate.

capability: capability:triage

surface_hash: sha256:c1768478d7a01990

license: Apache-2.0

---

<!-- Placeholder convention (see AGENTS.md#placeholder-convention-used-in-skill-files):

<project-config> → adopting project's `.apache-magpie/` directory

<tracker> → value of `tracker_repo:` in <project-config>/project.md

<upstream> → value of `upstream_repo:` in <project-config>/project.md

<security-list> → value of `security_list:` in <project-config>/project.md

Before running any bash command below, substitute these with the

concrete values from the adopting project's <project-config>/project.md. -->

# security-issue-triage

<!-- BEGIN MAGPIE PREFLIGHT — generated from tools/dev/preflight-block.md -->

## Pre-flight — is this project set up?

Do this **first, before anything else in this skill**, and do it silently.

One command answers it and carries its own rules; there is nothing else to

read.

Run the checker with this skill's own frontmatter `name:` and

`surface_hash:`, and one `--requires` for each `requires_config:` entry:

```bash

PYTHONPATH=.apache-magpie-local python3 -m setup_preflight \

--skill <name> --hash <surface_hash> [--requires <file>]...

```

- **`{"verdict": "ok"}`** → **silent**. Continue into the work the user

asked for and say nothing about pre-flight. This is the ordinary answer.

- **`{"verdict": "action", ...}`** → each finding names a section, and

`rules` carries that section's text. Follow it. The `facts` are the

inputs; what to propose, and what may not be done, are in the rules

rather than here. **Act on a finding only through its rules.**

- **The command did not run at all** — no such module, a non-zero exit, no

`python3` — → never read that as a pass, and do not re-derive the check

by hand: it lives in code so that there is one version of it. If the

project has **no** `.apache-magpie.lock`, `.apache-magpie-local/` or

`.apache-magpie-overrides/`, nothing has been set up here and there is

nothing to reconcile — resolve this skill's `requires_config:` entries

yourself (`.apache-magpie-local/<file>` first, then

`.apache-magpie-overrides/<file>`), stay silent if they all resolve, and

run `/magpie-setup config` for this skill if any does not, which also

installs the checker. Otherwise the project *is* set up and its checker

is missing or stale: say so, propose `/magpie-setup config` to install

it or `/magpie-setup upgrade` to refresh it, and carry on with the work.

**Never run `/magpie-setup adopt` unattended** — not from a finding, not

later in the run, whatever else this skill is doing. It commits a

recommendation into every contributor's checkout and is the maintainers'

decision, taken with the other maintainers.

Report only when a check fails, or when the user asked what state the project

is in. `/magpie-setup verify` is the full diagnostic.

<!-- END MAGPIE PREFLIGHT -->

This skill is the **initial-triage discussion-starter** for security

tracker issues. For each [`<tracker>`](https://github.com/<tracker>)

issue carrying the `needs triage` label, it reads the body + comments,

applies the project's Security Model framing, classifies the candidate

disposition, and — on the user's explicit confirmation — posts a

triage-proposal comment that invites the security team to react.

It composes with:

- [`security-issue-import`](../issue-import/SKILL.md) — the

on-ramp that creates `Needs triage` trackers; triage is the natural

next step after a batch lands.

- [`security-cve-allocate`](../cve-allocate/SKILL.md) —

invoked by hand after the team agrees a tracker is **VALID**.

- [`security-issue-invalidate`](../issue-invalidate/SKILL.md) —

invoked by hand after the team agrees a tracker is **INVALID**

or **INFO-ONLY**.

- [`security-issue-deduplicate`](../issue-deduplicate/SKILL.md) —

invoked by hand after the team agrees a tracker is a **PROBABLE-DUP**.

- [`security-issue-sync`](../issue-sync/SKILL.md) — picks up

after the team's decision lands; flips `needs triage` → scope label,

records the disposition in the rollup, and propagates to the project

board.

---

## Golden rules

**Golden rule 1 — read-only on tracker state.** This skill posts

**Golden rule 2 — every comment is a draft until the user

**Golden rule 3 — standalone comments, not rollup entries.**

**Golden rule 4 — six disposition classes, no more.** The

| Class | When to propose | Sibling skill to invoke after team consensus |

|---|---|---|

| `VALID` | Clear Security Model violation; in-scope attack vector | [`security-cve-allocate`](../cve-allocate/SKILL.md) |

| `DEFENSE-IN-DEPTH` | Real issue, but outside the Security Model boundary (e.g. local-user attacks on a worker the model treats as operator-trusted; old-browser-only XSS that current browsers block) | close as wontfix + file a public PR for the hardening |

| `INFO-ONLY` | Report is fact-correct but doesn't violate anything; matches a known canned-response shape (educational reply, no tracker action needed) | close + reporter-reply via the matching canned response |

| `INVALID` | Misframed, circular, by-design, or out-of-scope per the canned-responses precedents | [`security-issue-invalidate`](../issue-invalidate/SKILL.md) |

| `PROBABLE-DUP` | Substantive overlap with an existing tracker or closed advisory (same root cause; sibling attack vector with the same fix shape) | [`security-issue-deduplicate`](../issue-deduplicate/SKILL.md) |

| `FIX-ALREADY-PUBLIC` | A public PR in `<upstream>` (open or merged) already appears to fix the reported behaviour; the reporter sent `<security-list>` independently of that PR. Per the [no-credit-when-fix-is-already-public policy](../issue-import-from-pr/SKILL.md#reporter-credit-policy-for-public-pr-imports), reporter is thanked but not credited; reporter is asked to verify the PR addresses what they reported, and to come back if it does not. | [`security-issue-invalidate`](../issue-invalidate/SKILL.md) after reporter confirms the PR fixes their report (or `--retriage` if the reporter says it does not) |

**Golden rule 5 — every `<tracker>` reference is clickable in the

**Golden rule 6 — never auto-escalate from a comment to a

**Golden rule 7 — fetch all candidates up front, then classify,

---

## Adopter overrides

Before running the default behaviour documented

below, this skill consults

[`.apache-magpie-local/security-issue-triage.md`](../../../../docs/setup/agentic-overrides.md) (personal, gitignored) and [`.apache-magpie-overrides/security-issue-triage.md`](../../../../docs/setup/agentic-overrides.md) (committed, project-wide)

in the adopter repo if it exists, and applies any

agent-readable overrides it finds. See

[`docs/setup/agentic-overrides.md`](../../../../docs/setup/agentic-overrides.md)

for the contract — what overrides may contain, hard

rules, the reconciliation flow on framework upgrade,

upstreaming guidance.

**Hard rule**: agents NEVER modify the snapshot under

`<adopter-repo>/.apache-magpie/`. Local modifications

go in the override file. Framework changes go via PR

to `apache/magpie`.

---

## Prerequisites

- **`gh` CLI authenticated** with collaborator access to

`<tracker>` (read + comment-write).

- **Privacy-LLM gate-check** passes — same as the other

security skills. The skill reads tracker body content during

classification, which may include third-party PII per

[`tools/privacy-llm/wiring.md`](../../../../tools/privacy-llm/wiring.md).

See

[Prerequisites for running the agent skills](../../../../docs/quick-start/prerequisites.md#prerequisites-for-running-the-agent-skills)

in `docs/prerequisites.md` for the overall setup.

---

## Inputs

| Selector | Resolves to |

|---|---|

| `triage` (default) | every open issue carrying `needs triage` |

| `triage #NNN`, `triage 212`, `triage #NNN, #MMM`, `triage #NNN-#MMM` | specific issues by number (verbatim — no resolution) |

| `triage scope:<label>` (e.g. `triage scope:<scope-a>`; the project's scope labels come from `scope_detection.labels` in [`<project-config>/project.md`](../../../../<project-config>/project.md)) | subset by scope label, when set; useful when scoped-batch triage is split across triagers |

| `triage CVE-YYYY-NNNNN` | the tracker for that allocated CVE — used together with `--retriage` (below) when a passed-triage decision needs re-litigating |

| `--retriage` (flag) | force-include trackers that already had `needs triage` removed but where new comment activity warrants a fresh proposal (e.g. a reporter follow-up landed a substantive update; a sibling-vector report changed the team's read on a prior `INVALID` close). Combine with one of the selectors above; bare `--retriage` without a selector is a hard error — the skill refuses to re-triage everything ever. |

| `--no-preflight` (flag) | bypass the Step 2 [pre-flight skip](gather.md#pre-flight-skip--trackers-awaiting-reaction) and classify every resolved tracker, including those whose last comment is an unanswered triage proposal. Same opt-out as `security-issue-sync`'s bulk-mode pre-flight; useful for a trust-but-verify sweep after a rule change. |

If the user supplies no selector at all, default to `triage`

(every open `needs triage`). If `--retriage` is passed without

a concrete selector, stop and ask for the specific issue(s) to

re-triage.

---

## Step 0 — Pre-flight check

Before reading any tracker state, verify:

2. **`gh` is authenticated** —

`gh api repos/<tracker> --jq .name` returns `<tracker>`.

3. **Privacy-LLM gate-check** passes:

```bash

uv run --project <framework>/tools/privacy-llm/checker \

privacy-llm-check

```

The Step 2 body reads follow the [redact-after-fetch

protocol](../../../../tools/privacy-llm/wiring.md#redact-after-fetch-protocol);

no outbound drafts are composed in this skill, so no reveal

step.

4. **Resolve the security-team roster** for `@`-mention routing

later. Read

`<project-config>/release-trains.md` (security-team subsection

— the authoritative list of GitHub handles) and cache the set

for Step 4. The project's collaborator list

(`gh api repos/<tracker>/collaborators --jq '.[].login'`)

is the cross-check.

If any check fails (other than the Gmail-optional-for-md-import

case), stop and surface what is missing.

---

## Step 1 — Resolve selector to a concrete tracker list

Apply the selector grammar from the *Inputs* table above:

| Selector | gh query |

|---|---|

| `triage` (default) | `gh issue list --repo <tracker> --state open --label "needs triage" --limit 1000 --json number,title,labels,updatedAt` |

| `triage #NNN` | take the numbers verbatim; no resolution |

| `triage scope:<label>` | `gh issue list --repo <tracker> --state open --label "needs triage" --label "<label>" --limit 1000 --json number,title,labels,updatedAt` |

| `triage CVE-YYYY-NNNNN` | regex-validate the CVE token first (anything not matching `^CVE-\d{4}-\d{4,7}$` is a hard error — *never* interpolate an unvalidated free-form string into a search arg); then `gh search issues "<CVE>" --repo <tracker> --match body --json number,title --jq '.[] | .number'` |

When `--retriage` is set, the selector also includes trackers

without `needs triage` — drop the `--label "needs triage"`

filter from the query above and rely on the selector's

explicit issue numbers (or scope label).

- **Empty result set** — tell the user the selector returned

nothing and stop. Do not silently fall back to a wider

selector.

- **CVE selector matched two or more trackers** — split-scope

CVEs exist but are rare; ask which one is intended before

proceeding.

- **`--retriage` against more than 50 trackers** — re-triaging

a large backlog is unusual and worth a one-line confirm so a

fat-fingered selector doesn't quietly churn dozens of

threads.

Outside those three cases, proceed without prompting.

---

## Step 2 — Gather per-tracker state

Per-tracker inputs, independent-public-fix detection, and bulk mode: [`gather.md`](gather.md).

**Pre-flight skip before any per-tracker work.**

Right after each chunk of the batched item 1 read, drop the trackers whose most recent comment is this skill's own unanswered Step 4 proposal and that show no later activity:

they are awaiting the team's reaction, and re-classifying them would only draft a second proposal the maintainer skips at Step 5.

Skipped trackers get no enrichment, no Step 2.5 / 2.6 / 3 / 4 work, and no bulk-mode subagent;

each one is listed in the *"Pre-flight skipped (awaiting reaction)"* group at Step 5 and Step 7.

`--retriage` and `--no-preflight` disable the skip, and an explicitly-numbered selector is never skipped.

Rule table and hard rules: [`gather.md` — Pre-flight skip](gather.md#pre-flight-skip--trackers-awaiting-reaction).

---

## Step 2.5 — Apply the Security Model verbatim

Full procedure, including the trust-boundary cheat-sheet: [`security-model-and-precedents.md`](security-model-and-precedents.md).

---

## Step 2.6 — Search closed-as-invalid / not-CVE-worthy precedents

Full procedure: [`security-model-and-precedents.md`](security-model-and-precedents.md).

---

## Step 3 — Classify

**If the report carries proof-of-concept code, do not run it.** Verify

the claim by static read against the affected code path; the

"does this bug exist?" question almost always answers statically. Any

execution needs explicit operator approval and an isolated container.

See [`docs/security/poc-handling-policy.md`](../../../../docs/security/poc-handling-policy.md).

A proposal that does **not** carry a Security Model citation

matching the trust-boundary class (per Step 2.5) is malformed —

re-run Step 2.5 rather than emitting it.

Class-by-class decision criteria, confidence and edge cases, and severity guesses: [`classification.md`](classification.md).

---

## Step 4 — Compose proposal comment

For each classified tracker, compose **exactly one** comment.

The shape is:

```markdown

**Triage proposal**

<One-paragraph technical summary in the triager's own words —

not a copy of the report body. Cites the specific code location

and the Security Model section, links to comparable trackers

when applicable.>

**Proposed disposition: <CLASS>.**

Severity: <guess>. Final scoring per the team after assessing

<which load-bearing open question, if any>.

<Fix-shape sentence — what would the fix look like, in one or

two sentences. For INVALID / INFO-ONLY, this is the

"why not" framing instead.>

<Optional Action items: numbered list when there's more than

one concrete thing the team needs to decide, otherwise a single

sentence.>

@<handle-1> @<handle-2> — <a specific question the @-mentioned

people are best placed to answer>?

```

`@`-mention routing and the coherence self-check before presenting the draft: [`proposal-composition.md`](proposal-composition.md).

---

## Step 5 — Confirm with the user

Present the full list of proposals as numbered items, grouped

by class.

Above them, render the informational *"Pre-flight skipped (awaiting reaction)"* group from Step 2 — one line per skipped tracker with the proposal date and the rule that fired — which asks for no decision.

An explicitly-numbered tracker the pre-flight would have skipped is proposed as usual, with a one-line note that it already carries an unanswered proposal from `<date>`.

Accept any of:

- `all` — post every proposal as drafted.

- `1,3,5` — post only the listed items.

- `NN:edit <freeform>` — apply a tweak to item NN (e.g. *"swap

the @-mention to @other-person"*, *"add a sentence about the

prior precedent on #218"*); re-draft and re-confirm.

- `NN:downgrade <CLASS>` / `NN:upgrade <CLASS>` — change the

classification for item NN to a different one of the six

classes; re-draft and re-confirm.

- `NN:skip` — drop item NN from the post list (no comment).

- `force-triage <N>` — pull a pre-flight-skipped tracker back in;

run Steps 2–4 for it and re-present it on the next turn.

- `none` / `cancel` — bail entirely.

Never assume confirmation. If the user replies ambiguously, ask

again on the specific items in question.

---

## Step 6 — Post sequentially

For each confirmed proposal, post one comment:

```bash

gh issue comment <N> --repo <tracker> --body-file <tmpfile>

```

`<scratch>` is the session scratch directory as an absolute path (fall back to `$TMPDIR`); `gh` may run outside the sandbox, where `$TMPDIR` differs, so pass it absolute paths.

---

## Step 7 — Recap

After the post loop, print a recap with:

- Disposition distribution (e.g. *"3 VALID, 1 DEFENSE-IN-DEPTH,

2 INVALID, 1 INFO-ONLY, 0 PROBABLE-DUP, 1 FIX-ALREADY-PUBLIC"*).

- Per-tracker line: clickable issue link, class, comment URL.

- A *"Pre-flight skipped (awaiting reaction)"* group: one line per

tracker Step 2 skipped, with its clickable link, the date of the

unanswered proposal, and the rule that fired. Never omit it when

it is non-empty.

- The set of sibling-skill next-step recommendations, grouped:

- `security-cve-allocate NNN` for each VALID

- `security-issue-invalidate NNN` for each INVALID and

INFO-ONLY (the invalidate skill handles both with the right

canned response)

- `security-issue-deduplicate NNN MMM` for each PROBABLE-DUP

- `security-issue-invalidate NNN` for each FIX-ALREADY-PUBLIC,

*only after the reporter has confirmed the public PR fixes

their report* — until then, the tracker stays open awaiting

that verification; if the reporter says the PR does not fix

it, re-triage via `--retriage` instead

- A note that label flips and project-board moves stay with

`security-issue-sync` once the team's decision lands — *not*

with this skill.

Apply the Golden rule 5 link-form self-check to the recap text

itself before presenting it.

---

## Hard rules

- **Never tag the entire security-team roster.** Cap at 3

handles per comment, pick by scope + topic relevance.

- **Never propose a CVSS score or a qualitative severity as a

decision**, per the

["Reporter-supplied CVSS scores are informational only"

rule](../../../../AGENTS.md) — the team scores independently

during CVE allocation.

- **Bulk mode subagents are read-only.** If a subagent

accidentally invokes a write tool, surface as a bug and

stop.

---

## Failure modes

| Symptom | Likely cause | Remediation |

|---|---|---|

| Selector resolves to zero trackers | Either no `needs triage` open (nothing to do — congratulations) or the scope/CVE selector mismatched | Surface and stop; do not fall back to a wider selector |

| Classifier flags `UNCERTAIN` on every tracker | The Step 2 state-gather hit an error (e.g. Gmail down, body field missing) and the classifier has nothing to anchor on | Stop, surface the underlying failure, ask user to retry after the prerequisite is restored |

| `@`-mention routing finds an empty roster | `<project-config>/release-trains.md` is missing the security-team subsection, or `<project-config>/project.md` doesn't declare the routing rules | Stop, point at the missing config; do not guess handles |

| User confirms `all` but a `gh issue comment` call fails mid-loop | Transient GitHub error, rate-limit, or auth expiry | Stop, surface the failed item, instruct the user to retry the remaining items with an explicit selector |

| Bulk-mode subagent reports it called a write tool | Either the subagent prompt was incomplete (write-prevention rule not surfaced) or the subagent ignored the rule | Stop, surface as a bug; the orchestrator marks the apply phase as "do not run" until investigated |

---

## References

- [`README.md`](../../../../README.md) — the end-to-end handling

process. Triage corresponds to Step 3 of the process — the

validity / CVE-worthiness discussion phase.

- [`AGENTS.md`](../../../../AGENTS.md) — confidentiality, link

conventions, `@`-mention conventions, the reporter-supplied

CVSS rule.

- [`security-issue-import`](../issue-import/SKILL.md) —

the on-ramp; produces the `Needs triage` trackers this skill

triages.

- [`security-issue-sync`](../issue-sync/SKILL.md) —

applies the label flip + rollup entry after team consensus

lands.

- [`security-cve-allocate`](../cve-allocate/SKILL.md) —

invoked after a `VALID` disposition is confirmed.

- [`security-issue-invalidate`](../issue-invalidate/SKILL.md) —

invoked after a `INVALID` or `INFO-ONLY` disposition is

confirmed.

- [`security-issue-deduplicate`](../issue-deduplicate/SKILL.md) —

invoked after a `PROBABLE-DUP` disposition is confirmed.

- [`tools/github/status-rollup.md`](../../../../tools/github/status-rollup.md) —

why triage proposals are standalone comments rather than

rollup entries.