Triage finding

Return one static-evidence verdict per supplied finding: confirmed, not_actionable, or needs_review. Rank confirmed and needs_review findings separately by exploitability. Preserve input order and duplicate-looking inputs.

Work inline. Do not delegate, use deep triage mode, search for unrelated vulnerabilities, edit repository files, or run tests, builds, applications, PoCs, or dynamic validation. State the limits of static evidence; do not claim runtime validation or exhaustive coverage.

Intake

Accept SARIF results, CVEs, advisories, scanner tickets, bug bounty reports, Codex Security artifacts, and freeform vulnerability claims. If no finding is supplied, ask for one before inspecting code or emitting triage-finding/v0. Ask about the repository or claim only when it is too vague to inspect; otherwise record missing facts as proof gaps.

Jira and Linear intake

Use this skill for security or vulnerability Jira/Linear tickets. Atlassian and Linear mentions are connector hints for importing claims, not a reason to switch to generic ticket or duplicate triage.

Read references/ticket-intake.md for issue URLs, identifiers, queries, or search phrases. Retrieve the requested content before normalizing findings or inspecting code. Inaccessible tickets cannot support a verdict or result contract unless the user supplies their complete finding content.

GitHub intake

Read references/github-rest-intake.md before repository intake. It owns repository and source selection, authorized transport and credentials, retrieval, and revision alignment. Retrieve the selected findings before inspecting code or emitting the contract.

Normalize the inputs

Read references/triage-result-contract.md and normalize the supplied collection before assigning verdicts. Assign triage_item_id, preserve external identifiers in input_id, and extract: