/triage-finding

name: triage-finding
description: "Use when the user supplies or imports existing security findings, vulnerability reports, or security/vulnerability Jira/Linear tickets from scanners, advisories, GitHub, Atlassian Rovo, Linear, or similar backlog sources and wants static repo-impact triage. Do not use for discovery, duplicate-bug triage, validation, or fixes."

Triage Finding

Objective

Triage existing security findings against the current repository using static code evidence. Return one evidence-backed verdict per supplied finding: `confirmed`, `not_actionable`, or `needs_review`. For `confirmed` and `needs_review` findings, also assign a discrete exploitability stack rank inside that verdict's own queue.

This skill is for backlog burn-down. It starts from findings the user already has, such as SARIF results, CVEs, advisories, scanner tickets, bug bounty reports, Jira/Linear issues, or Codex Security finding artifacts. It is not a repository-wide scan, dynamic validation run, fix implementation, dashboard, or queue manager.

Backlog Burn-Down Scope

Treat multiple supplied findings as one backlog-reduction problem, not as a set of unrelated one-off triages. The goal is to turn noisy existing finding sources into a ranked, evidence-backed action queue while preserving one result per input for auditability.

For now, run the workflow inline in the current thread, but structure the work like a backlog pipeline:

• Build the normalized triage item list for the whole supplied or imported collection before assigning verdicts. Here, normalize means: assign `triage_item_id`, preserve source ids and references, extract the fields in the Inputs section below, and record missing fields as proof gaps without inventing scanner, severity, remediation, or generated Codex Security fields.
• Triage each normalized item using static evidence and keep one output result per supplied finding.
• Rank the `confirmed` and `needs_review` results as an action queue for backlog burn-down.
• Do not perform deduplication in this skill. If duplicate-looking inputs are present, keep one result per supplied finding; deduplication belongs in a separate workflow.
• Do not spawn subagents, use a subagent queue, or use deep triage mode until a future implementation explicitly adds those mechanics.

Finding Schema Decision

Do not use `../../schemas/findings.schema.json` as the canonical data shape for input normalization.

That schema describes completed Codex Security scan output. It requires generated fields such as `scanId`, `findingId`, `occurrenceId`, fingerprints, severity, remediation, provenance, and at least one location. Most triage inputs are incomplete external claims, and forcing them into that schema before investigation would require inventing stable IDs, severity, remediation, or locations.

Use the schema only as an optional compatibility source when the user supplies an existing `codex-security.findings` JSON artifact. In that case, extract the available fields into the triage normalization record and preserve the original IDs as source identifiers. The triage result contract is defined in `references/triage-result-contract.md`.

Static Assessment Guidance

Use the shared static finding assessment reference in `../../references/static-finding-assessment.md` for the reusable evidence work: source/control/sink tracing, smallest useful evidence search, reachability, boundary inputs, counterevidence, proof gaps, and static confidence.

This skill still owns external finding intake, the backlog triage verdicts, the first-pass no-runtime constraint, and the output contract.

Routing and Connector Use

Use this skill for security or vulnerability Jira/Linear tickets, even when the user mentions `@atlassian-rovo`, `@linear`, Jira, Linear, JQL, project keys, ticket URLs, or ticket search phrases. Treat Atlassian Rovo and Linear mentions as connector hints for importing ticket content, not as a reason to switch to Atlassian Rovo's `triage-issue` skill or another generic ticket workflow.

Do not run duplicate-bug triage instead of security-impact triage. Generic Jira duplicate triage answers "is this already filed?" This skill answers "does this existing security claim affect this repository, and how should it rank for backlog burn-down?"

Jira and Linear Intake

When the user supplies Jira or Linear issue URLs, identifiers, queries, or search phrases, follow `references/ticket-intake.md` before normalizing findings. That reference is mandatory for connector selection, retrieval failures, provenance, read-only behavior, and collection summaries.

Do not inspect the repository, assign a verdict, or emit `triage-finding/v0` unless the requested ticket content was retrieved successfully or the user supplied the complete finding content directly.

GitHub Repository Intake

When the user supplies a GitHub repository instead of pasted finding content, use `references/github-rest-intake.md` before normalizing findings.

Detect GitHub repositories from `owner/repo`, GitHub URLs, GitHub SSH remotes, the current Codex project's attached GitHub repository, or the current local repository's GitHub remote.

If the user asks to pull from GitHub without typing an `owner/repo` or URL, first infer the GitHub repository from the current Codex project attachment when that metadata is available. Prefer that attached repository over a local path or local git remote. If no Codex project attachment is visible, fall back to the current repository's GitHub remote. Only ask for a repository URL or `owner/repo` when neither source resolves to a GitHub repository.

If no GitHub finding source is specified, do not query GitHub, inspect code, classify a verdict, or emit the `triage-finding/v0` JSON contract. Ask the user to choose one of:

• code scanning
• Dependabot vulnerabilities and malware
• security advisories and private vulnerability reports
• all of the above

If the user specifies a source, query on