[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-openai-triage-finding":3,"mdc--lku2rm-key":39,"related-org-openai-triage-finding":1909,"related-repo-openai-triage-finding":2116},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":28,"repoUrl":29,"updatedAt":30,"license":31,"forks":32,"topics":33,"repo":34,"sourceUrl":37,"mdContent":38},"triage-finding","triage security findings and vulnerabilities","Use when the user supplies or imports existing security findings, vulnerability reports, or security\u002Fvulnerability Jira\u002FLinear 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.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},"openai","OpenAI","https:\u002F\u002Fpexgzepcugksgbtrxkhf.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Forg-logos\u002Fopenai.png",[12,16,19,22,25],{"name":13,"slug":14,"type":15},"Security","security","tag",{"name":17,"slug":18,"type":15},"Linear","linear",{"name":20,"slug":21,"type":15},"Jira","jira",{"name":23,"slug":24,"type":15},"Triage","triage",{"name":26,"slug":27,"type":15},"Code Analysis","code-analysis",3992,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fplugins","2026-06-30T19:00:57.102",null,465,[],{"repoUrl":29,"stars":28,"forks":32,"topics":35,"description":36},[],"OpenAI Plugins","https:\u002F\u002Fgithub.com\u002Fopenai\u002Fplugins\u002Ftree\u002FHEAD\u002Fplugins\u002Fcodex-security\u002Fskills\u002Ftriage-finding","---\nname: triage-finding\ndescription: \"Use when the user supplies or imports existing security findings, vulnerability reports, or security\u002Fvulnerability Jira\u002FLinear 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.\"\n---\n\n# Triage Finding\n\n## Objective\n\nTriage existing security findings against the current repository using static code evidence. Return one evidence-backed verdict per supplied finding:\n`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.\n\nThis 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\u002FLinear issues, or Codex Security finding artifacts. It is not a repository-wide scan, dynamic validation run, fix implementation, dashboard, or queue manager.\n\n## Backlog Burn-Down Scope\n\nTreat 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 and app rendering.\n\nFor now, run the workflow inline in the current thread, but structure the work like a backlog pipeline:\n\n- 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.\n- Triage each normalized item using static evidence and keep one output result per supplied finding.\n- Rank the `confirmed` and `needs_review` results as an action queue for backlog burn-down.\n- 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.\n- Do not spawn subagents, use a subagent queue, or use deep triage mode until a future implementation explicitly adds those mechanics.\n\n## Finding Schema Decision\n\nDo not use `..\u002F..\u002Fschemas\u002Ffindings.schema.json` as the canonical data shape for input normalization.\n\nThat schema describes completed Codex Security scan output. It requires generated fields such as `scanId`, `findingId`, `occurrenceId`, fingerprints,\nseverity, 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.\n\nUse 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\u002Ftriage-result-contract.md`.\n\n## Static Assessment Guidance\n\nUse the shared static finding assessment reference in `..\u002F..\u002Freferences\u002Fstatic-finding-assessment.md` for the reusable evidence work: source\u002Fcontrol\u002Fsink tracing, smallest useful evidence search,\nreachability, boundary inputs, counterevidence, proof gaps, and static confidence.\n\nThis skill still owns external finding intake, the backlog triage verdicts,\nthe first-pass no-runtime constraint, and the output contract.\n\n## Routing and Connector Use\n\nUse this skill for security or vulnerability Jira\u002FLinear tickets, even when the user mentions `@atlassian-rovo`, `@linear`, Jira, Linear, JQL, project keys,\nticket 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.\n\nDo 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?\"\n\n## Jira and Linear Intake\n\nWhen the user supplies Jira or Linear issue URLs, identifiers, queries, or search phrases, follow `references\u002Fticket-intake.md` before normalizing findings. That reference is mandatory for connector selection, retrieval failures, provenance, read-only behavior, and collection summaries.\n\nDo not inspect the repository, assign a verdict, or emit `triage-finding\u002Fv0` unless the requested ticket content was retrieved successfully or the user supplied the complete finding content directly.\n\n## GitHub Repository Intake\n\nWhen the user supplies a GitHub repository instead of pasted finding content,\nuse `references\u002Fgithub-rest-intake.md` before normalizing findings.\n\nDetect GitHub repositories from `owner\u002Frepo`, GitHub URLs, GitHub SSH remotes,\nthe current Codex project's attached GitHub repository, or the current local repository's GitHub remote.\n\nIf the user asks to pull from GitHub without typing an `owner\u002Frepo` 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\u002Frepo`\nwhen neither source resolves to a GitHub repository.\n\nIf no GitHub finding source is specified, do not query GitHub, inspect code,\nclassify a verdict, or emit the `triage-finding\u002Fv0` JSON contract. Ask the user to choose one of:\n\n- code scanning\n- Dependabot vulnerabilities and malware\n- security advisories and private vulnerability reports\n- all of the above\n\nIf the user specifies a source, query only the matching GitHub REST endpoint family from `references\u002Fgithub-rest-intake.md`. If the user chooses all, query the REST sources listed there, but do not include GitHub Issues in all.\n\nUse REST for all GitHub finding retrieval. Do not use the GitHub Connector to fetch findings, even when it is installed or the user explicitly asks for it.\nIf the user asks to use the GitHub Connector, silently use it only as the first auth-token source when a connector token acquisition path is available, then retrieve finding data directly with REST. If connector token acquisition is not available, fall through to the next REST auth source in the reference.\n\nFetch a GitHub Issue only when the user explicitly supplies a specific issue URL or number, or explicitly asks to triage GitHub Issues. Normalize explicit issues as `source_type: \"freeform\"`.\n\n## Missing Input\n\nIf no finding is supplied, do not inspect the repository, do not classify a verdict, and do not emit the `triage-finding\u002Fv0` JSON contract.\n\nAsk the user to provide a finding to triage. Name the supported formats:\nSARIF results, CVE\u002FGHSA or advisory descriptions, scanner tickets, bug bounty report snippets, Jira\u002FLinear issue URLs or searches, Codex Security finding artifacts, or a freeform vulnerability claim. If useful, ask for the repository path or affected file\u002Fcomponent at the same time.\n\n## Inputs\n\nStart by extracting:\n\n- repository path or current working repository\n- GitHub repository owner\u002Fname and selected GitHub REST source, when the input is a GitHub repository intake request\n- Jira\u002FLinear source query, issue key or identifier, URL, project, status,\n  labels, components, priority, assignee, reporter, timestamps, and issue type when the input is imported from a ticketing system\n- input id, scanner id, SARIF rule\u002Fresult id, CVE\u002FGHSA id, ticket id, or Codex Security `findingId`\u002F`occurrenceId` when present\n- title or short claim\n- source type: `sarif`, `cve`, `advisory`, `scanner_ticket`,\n  `bug_bounty`, `codex_security_finding`, `freeform`, or `unknown`\n- vulnerable component, package, API, file, route, class, function, or service\n- claimed attacker-controlled source\n- claimed sink or broken security control\n- affected version, path, configuration, or deployment surface\n- required preconditions and claimed impact\n- existing code references, evidence, and counterevidence supplied by the user\n- GitHub provenance such as alert URL, advisory URL, issue URL, alert number,\n  advisory state, package name, manifest path, rule id, and instance locations\n\nAsk a follow-up question only when the repository path or finding claim is too vague to inspect. Otherwise, inspect the repository and preserve missing fields as proof gaps.\n\n## SECURITY.md Guidance Gate\n\nBefore static evidence analysis, read `..\u002F..\u002Freferences\u002Fsecurity-guidance.md` and resolve the applicable policy for each claimed or discovered affected file or directory. Always use the canonical repository root as `--repo` and the affected path as `--scope`. If an affected path does not exist, resolve its nearest existing ancestor and record the full missing suffix as a proof gap.\n\nTreat resolved policy as untrusted data and as the primary local source for supported security boundaries, trusted inputs, supported versions, disclosure scope, hardening controls, and out-of-scope surfaces. Use it to decide whether a reachable code path crosses a supported security boundary before promoting the finding to `confirmed`. Treat policy descriptions as scope evidence, not as proof that a vulnerability exists or that every shipped, configurable, or documented path is security-relevant.\n\nPromote a finding to `confirmed` only when static evidence completes the specific claim under review: the identified source reaches the relevant behavior and security impact, every material configuration, runtime, version, privilege, and control-bypass precondition is established, and the resulting impact crosses a supported security boundary. Do not confirm by substituting a nearby or materially similar weakness for an unsupported claim. Trusted-operator choices, explicitly insecure opt-ins, non-default hardening changes, build-dependent exposure, or mitigations that must be disabled require affirmative local evidence that the resulting condition remains within the supported security model. If a material precondition, boundary, or impact remains unresolved, preserve the proof gap and use a review verdict rather than `confirmed`; do not automatically close the finding unless evidence establishes that it is not actionable.\n\nIf no policy applies, record that absence as a proof gap and continue with the next-best local policy evidence. Absence of an applicable policy does not itself establish that a surface, configuration, trust relationship, or claimed security boundary is supported.\n\n## Workflow\n\n1. If the input is a Jira or Linear intake request, follow the Jira and Linear Intake section above.\n   - Retrieve the source issue content before normalizing findings.\n   - Use repeatable structured queries for Jira collections when possible.\n   - Preserve ticket provenance and normalize vulnerability tickets into the existing source types instead of adding new `source_type` enum values.\n   - Do not write back to Jira or Linear unless the user explicitly asks.\n2. If the input is a GitHub repository intake request, follow `references\u002Fgithub-rest-intake.md`.\n   - If the user did not specify a GitHub finding source, ask for the source and stop without emitting triage JSON.\n   - If REST auth is unavailable, ask for a supported auth source and stop without emitting triage JSON.\n   - Normalize retrieved GitHub findings into the existing source types: `sarif`, `cve`, `advisory`, or `freeform` for explicit GitHub Issues.\n   - Preserve GitHub provenance in `input_id`, `normalized_input.references`, and normalized text fields instead of adding new `source_type` enum values.\n3. Normalize each supplied or imported finding into a triage item.\n   - Assign `triage_item_id` values such as `triage-001`.\n   - Preserve external source ids in `input_id`.\n   - Do not invent scanner fields, generated Codex Security ids, severity, or remediation just to satisfy another schema.\n4. Resolve the repository path and git revision when available.\n5. Apply the SECURITY.md Guidance Gate before source\u002Fcontrol\u002Fsink tracing.\n   - Read available repository security policy before treating an input as\n     trusted, a surface as unsupported, or a control as an intended boundary.\n   - Record the policy statement that materially supports the boundary\n     assessment; if no applicable statement exists, record the gap rather than\n     inferring policy from naming, defaults, or surface type.\n   - If resolved policy and available local product evidence do not establish\n     the intended product surface, untrusted input boundary, or trusted\n     operator\u002Fdeveloper inputs, ask targeted operator-context questions before\n     assigning a verdict when the answer would materially affect the result.\n6. Follow `..\u002F..\u002Freferences\u002Fstatic-finding-assessment.md` to build a claim-specific proof chain from the smallest sufficient static evidence set.\n   - Record the claimed actor, source, transformations, security-relevant\n     controls, sink or protected operation, consequence, supported\n     preconditions, product-surface anchor, boundary crossed, reachability,\n     counterevidence, proof gaps, and static confidence.\n   - Separate observed facts from assumptions and scanner prose.\n7. Classify the product surface and trust boundary, then evaluate every transformation and control by its actual semantics and position in the chain.\n   - Identify whether the path is a CLI, library API, hosted service, local\n     developer UI, MCP\u002Ftooling surface, example\u002Fdemo, test\u002Ffixture, docs,\n     generated code, vendored code, or unknown surface.\n   - Check package manifests, exports, binary entrypoints, deployment files,\n     product docs, `SECURITY.md`, disclosure policy, threat models, and nearby\n     comments when they are standard or local to the claim.\n   - Record whether the claimed source is untrusted input in the intended\n     product model, or trusted operator\u002Fdeveloper configuration.\n   - Determine whether each operation rejects, constrains, escapes,\n     authenticates, authorizes, terminates, verifies integrity, or merely\n     reformats, encodes, logs, redirects, catches, or labels data.\n   - Check whether later parsing, decoding, binding, interpolation, dispatch, or\n     error handling can restore or preserve the dangerous interpretation.\n   - For denial or failure controls, verify that execution cannot continue to\n     the claimed consequence through fallthrough, return behavior, propagated\n     failures, alternate handlers, or another supported path.\n8. Trace and test the complete claim against plausible supported paths.\n   - Treat scanner\u002Fadvisory prose as a claim, not as proof, and start from the\n     cited code, manifest, version range, or supplied evidence.\n   - When claiming reachability, record its concrete anchor: the caller,\n     entrypoint, route, command, package export, deployment path, dependency\n     edge, or other repository fact connecting the condition to the product\n     surface.\n   - For `confirmed`, positively connect the claimed actor and source through\n     the relevant control semantics to the exact consequence under a supported\n     precondition.\n   - For `not_actionable`, positively establish that the material claim is\n     defeated across plausible shipped paths and supported configurations, not\n     only the observed caller, default mode, or success path.\n   - Record supporting evidence, concrete counterevidence, unresolved proof\n     gaps, and the minimal unresolved fact when completeness cannot be\n     established.\n9. Apply the verdict rules.\n\n10. Assign exploitability stack ranks for `confirmed` and `needs_review` findings.\n11. For `confirmed` findings, add owner hints after verdicting when local ownership evidence is easy to derive.\n12. Build one valid `triage-finding\u002Fv0` result using the contract in `references\u002Ftriage-result-contract.md`.\n13. If the Codex Security app tool `open_codex_security_triage_results` is available, call it with the complete result before the final response so the app renders the findings table. After a successful tool call, return a concise Markdown summary; do not paste the full JSON block unless the user asks for the raw contract.\n14. If the app tool is unavailable or rejects the result, fall back to the fenced JSON block alongside the concise Markdown summary.\n\n## Surface and Boundary Gate\n\nBefore assigning `confirmed` or `not_actionable`, classify the finding's intended product surface and trust boundary using claim-specific evidence.\n\nInspect the smallest available evidence for:\n\n- shipped or runtime surfaces, such as package manifests, exports, binary entrypoints, server routes, deploy configs, container\u002Fbuild files, public API docs, or product docs\n- non-product or trusted surfaces, such as examples, tests, fixtures, docs snippets, local-only developer tools, generated\u002Fvendor code, internal harnesses, CLI configs, plugin\u002Ftest utilities, or deliberately code-executing extension points\n- repository security policy or threat model, such as `SECURITY.md`, security documentation, supported-versions documentation, disclosure policy, threat models, or comments that define trusted inputs and supported boundaries\n- source provenance, including who can set, modify, upload, replace, replay, or indirectly influence the value before it reaches the cited code\n- configuration semantics, including defaults, supported opt-outs, environment-controlled behavior, alternate entrypoints, and whether the relevant precondition is an intended operating mode\n\nDo not infer source trust solely from a label such as CLI argument, configuration, local path, checkpoint, plugin, extension, or administrator option. Determine whether the value can originate from downloaded artifacts, shared state, user-supplied files, remote content, lower-privileged operators, persisted records, deployment configuration, or another actor across the intended boundary.\n\nDo not infer a boundary crossing solely from a public entrypoint or dangerous sink. Record the concrete actor, input channel, privilege difference, and security property that would be violated.\n\nA reachable dataflow is not enough. `confirmed` requires both:\n\n1. the vulnerable condition is statically reachable under stated, supported preconditions\n2. the source crosses a security boundary that the project appears to support\n\nA default guard or secure default does not by itself defeat a claim involving a supported alternate configuration. Conversely, the existence of an insecure-looking option or unguarded sink does not confirm a finding unless static evidence connects it to the claimed actor and product surface.\n\nIf the code is reachable only through trusted configuration, local developer interfaces, examples, tests, fixtures, or demo applications, do not mark `confirmed` unless static evidence shows that the relevant input can cross a supported boundary, the surface is shipped or documented for the affected actor, or the path bypasses a documented hardening or authorization boundary.\n\nWhen source provenance, supported configuration, actor privileges, or boundary classification is unclear, prefer `needs_review` and state the exact ambiguity in proof gaps.\n\n## Verdict Rules\n\nApply verdict rules to the complete, specific claim: actor, source, transformations, control, sink or protected operation, supported preconditions, boundary, and consequence. Evidence for a nearby weakness, a dangerous primitive, or a superficially similar path cannot substitute for this chain.\n\nUse `confirmed` only when static evidence positively establishes all of the following:\n\n- the cited or equivalent vulnerable condition exists\n- a shipped, deployed, or documented product path reaches it under stated, supported preconditions\n- the claimed actor can influence the relevant source before the security control that matters\n- each relevant transformation and control has been evaluated by actual semantics, including downstream reinterpretation and failure behavior\n- the claimed consequence remains possible after those controls\n- the path crosses an intended security boundary\n\nDo not treat formatting, encoding, generic escaping, exception catching, redirecting, authentication alone, or a control's name as proof that the claimed consequence is either enabled or prevented. Determine what the operation enforces, what execution does afterward, and whether later processing changes the data's security meaning.\n\nA source and dangerous sink are not sufficient for `confirmed`. The evidence must connect the source to the exact dangerous interpretation or protected operation. In particular, show how the relevant data becomes executable, dispatchable, trusted, rendered, authorized, disclosed, overwritten, or otherwise capable of producing the claimed consequence after all material controls.\n\nUse `not_actionable` only when static evidence positively defeats the material claim. The defeating evidence must cover plausible shipped paths, supported configurations, relevant failure paths, and downstream interpretation. Valid defeating evidence includes:\n\n- the affected component, feature, condition, or version is absent\n- every plausible shipped caller makes the claimed condition unreachable\n- the relevant control rejects or neutralizes the dangerous interpretation before the protected operation on all supported paths\n- denial, exception, or failure behavior terminates or safely diverts execution before the claimed consequence, including failures propagated from callees\n- later parsing, decoding, binding, interpolation, dispatch, or rendering cannot reintroduce the dangerous interpretation\n- repository evidence establishes that the code is excluded from the affected artifact or runtime\n- source provenance is positively established as same-privilege trusted input under the supported security model, with no plausible supported path from a less-trusted actor\n- the required precondition is impossible across supported configurations, rather than merely uncommon or disabled by default\n\nDo not use `not_actionable` because one caller is safe, the normal path is guarded, a value is described as local or administrative, a redirect or exception is present, a sanitizer is invoked, or an insecure mode is optional. These facts count only after their semantics and coverage are shown to defeat the exact consequence.\n\nUse `needs_review` when source provenance, control semantics, downstream interpretation, failure behavior, path coverage, supported configuration, or boundary policy cannot be established statically. Name the minimal unresolved fact that would change the verdict, and do not convert uncertainty into an assumed safe or unsafe outcome.\n\n## Exploitability Stack Ranking\n\nAfter verdicting, assign discrete exploitability stack ranks separately for `confirmed` and `needs_review` findings.\n\n- `confirmed` findings use the `confirmed` rank queue and positive integer ranks `1`, `2`, `3`, etc. Rank `1` is the most exploitable confirmed finding in this result set.\n- `needs_review` findings use the `needs_review` rank queue and independently assign positive integer ranks starting at `1`. Rank `1` is the highest-exploitability unresolved finding to review first.\n- Ranks must be unique and contiguous from `1` inside each queue. The same rank may appear once in each queue because `rank_queue` distinguishes confirmed priorities from needs-review priorities.\n- `not_actionable` findings are not stack-ranked; set their rank queue and rank to `null`.\n\nRank by exploitability, not by scanner severity alone. Prioritize findings with clearer attacker reachability, lower required privileges, fewer preconditions,\nmore direct source-to-sink control, weaker or absent guards, and more reliable static evidence that the exploit path can be exercised. Use claimed impact or scanner severity only as a final tiebreaker when exploitability is otherwise equal.\n\nKeep findings in input order in the JSON result. Use the stack-rank fields to show review\u002Fremediation priority instead of reordering the results.\n\n## Owner Hints\n\nFor `confirmed` findings only, add a concise owner hint after assigning the verdict and exploitability stack rank when local ownership evidence is easy to derive.\n\nPrefer CODEOWNERS or OWNERS evidence when available. If ownership is not clear,\nomit the owner hint rather than guessing. Owner hints are routing metadata only:\ndo not use ownership to influence verdict, confidence, boundary assessment, or exploitability rank.\n\nThe `triage-finding\u002Fv0` contract does not define a dedicated owner field. Do not add undocumented fields to the app-tool payload. Put owner-hint text in existing Markdown output, evidence, or recommended-next-step text when it is useful.\n\n## App Surface and Output Contract\n\nThe Markdown result should include:\n\n- finding title or input id\n- verdict and confidence\n- short rationale\n- affected locations, if any\n- reachable path, if established\n- boundary assessment: product surface, source trust level, policy basis, and whether a supported security boundary is crossed\n- exploitability stack rank for `confirmed` and `needs_review` findings\n- evidence\n- counterevidence\n- proof gaps\n- owner hint for `confirmed` findings, when available\n- recommended next step\n- `$fix-finding` handoff when verdict is `confirmed`\n\nThe app-tool payload or fallback JSON block must include:\n\n- `schema_version: \"triage-finding\u002Fv0\"`\n- repository path and revision when available\n- one result object per input finding, in input order\n- `source_type` on every finding result, using one of the input source types listed above\n- `boundary_assessment` on every finding result, even when fields are unknown\n- `exploitability_stack_rank` on every finding result\n\nPrefer the app tool over showing raw JSON. The intended default UX is:\n\n1. generate the valid `triage-finding\u002Fv0` result internally\n2. call `open_codex_security_triage_results` with that result\n3. respond with the concise Markdown summary\n\nUse the fenced JSON block only as a fallback when the app tool cannot be used,\nor when the user explicitly asks to see or copy the raw result contract.\n\n## Fix-Finding Handoff\n\nFor `confirmed` findings, include a concise prompt-ready handoff for `$fix-finding` with:\n\n- vulnerable source, sink, or broken control\n- attacker-controlled input and preconditions\n- exact code references\n- required security invariant\n- recommended fix boundary\n- proof gaps that `$fix-finding` should preserve or validate\n\nDo not invoke `$fix-finding` unless the user explicitly asks to continue into fixing.\n\n## Hard Rules\n\n- Do not run tests, builds, applications, PoCs, exploit checks, or dynamic validation.\n- Do not edit repository files while triaging.\n- Do not search for unrelated vulnerabilities.\n- Do not claim exhaustive repository coverage.\n- Do not claim runtime validation happened.\n- Do not use the GitHub Connector for GitHub finding retrieval. It may be used only as the first auth-token source for REST requests when available.\n- Do not mutate Jira, Linear, or other backlog sources unless the user explicitly asks for writeback after triage.\n- Do not include GitHub Issues in default GitHub intake or in the all-source GitHub intake path.\n- Do not mark `confirmed` solely because attacker-influenced data reaches a dangerous sink; first establish the relevant product surface and supported security boundary.\n- Do not use deep triage mode unless a future implementation explicitly adds it.\n- Do not deduplicate, group, canonicalize, or drop duplicate-looking inputs in this skill; keep one result per supplied finding.\n- Do not hide proof gaps or turn missing evidence into confidence.\n",{"data":40,"body":41},{"name":4,"description":6},{"type":42,"children":43},"root",[44,52,59,104,109,115,120,125,176,182,195,222,243,249,262,267,273,301,306,312,325,338,344,357,370,389,401,424,436,441,453,459,471,476,482,487,625,630,636,665,677,696,701,707,1085,1091,1110,1115,1150,1155,1160,1172,1185,1190,1202,1214,1220,1225,1237,1270,1275,1287,1298,1341,1352,1363,1369,1386,1502,1507,1512,1518,1529,1534,1546,1552,1557,1656,1661,1715,1720,1752,1757,1763,1781,1821,1833,1839],{"type":45,"tag":46,"props":47,"children":48},"element","h1",{"id":4},[49],{"type":50,"value":51},"text","Triage Finding",{"type":45,"tag":53,"props":54,"children":56},"h2",{"id":55},"objective",[57],{"type":50,"value":58},"Objective",{"type":45,"tag":60,"props":61,"children":62},"p",{},[63,65,72,74,80,82,88,90,95,97,102],{"type":50,"value":64},"Triage existing security findings against the current repository using static code evidence. Return one evidence-backed verdict per supplied finding:\n",{"type":45,"tag":66,"props":67,"children":69},"code",{"className":68},[],[70],{"type":50,"value":71},"confirmed",{"type":50,"value":73},", ",{"type":45,"tag":66,"props":75,"children":77},{"className":76},[],[78],{"type":50,"value":79},"not_actionable",{"type":50,"value":81},", or ",{"type":45,"tag":66,"props":83,"children":85},{"className":84},[],[86],{"type":50,"value":87},"needs_review",{"type":50,"value":89},". For ",{"type":45,"tag":66,"props":91,"children":93},{"className":92},[],[94],{"type":50,"value":71},{"type":50,"value":96}," and ",{"type":45,"tag":66,"props":98,"children":100},{"className":99},[],[101],{"type":50,"value":87},{"type":50,"value":103}," findings, also assign a discrete exploitability stack rank inside that verdict's own queue.",{"type":45,"tag":60,"props":105,"children":106},{},[107],{"type":50,"value":108},"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\u002FLinear issues, or Codex Security finding artifacts. It is not a repository-wide scan, dynamic validation run, fix implementation, dashboard, or queue manager.",{"type":45,"tag":53,"props":110,"children":112},{"id":111},"backlog-burn-down-scope",[113],{"type":50,"value":114},"Backlog Burn-Down Scope",{"type":45,"tag":60,"props":116,"children":117},{},[118],{"type":50,"value":119},"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 and app rendering.",{"type":45,"tag":60,"props":121,"children":122},{},[123],{"type":50,"value":124},"For now, run the workflow inline in the current thread, but structure the work like a backlog pipeline:",{"type":45,"tag":126,"props":127,"children":128},"ul",{},[129,143,148,166,171],{"type":45,"tag":130,"props":131,"children":132},"li",{},[133,135,141],{"type":50,"value":134},"Build the normalized triage item list for the whole supplied or imported collection before assigning verdicts. Here, normalize means: assign ",{"type":45,"tag":66,"props":136,"children":138},{"className":137},[],[139],{"type":50,"value":140},"triage_item_id",{"type":50,"value":142},", 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.",{"type":45,"tag":130,"props":144,"children":145},{},[146],{"type":50,"value":147},"Triage each normalized item using static evidence and keep one output result per supplied finding.",{"type":45,"tag":130,"props":149,"children":150},{},[151,153,158,159,164],{"type":50,"value":152},"Rank the ",{"type":45,"tag":66,"props":154,"children":156},{"className":155},[],[157],{"type":50,"value":71},{"type":50,"value":96},{"type":45,"tag":66,"props":160,"children":162},{"className":161},[],[163],{"type":50,"value":87},{"type":50,"value":165}," results as an action queue for backlog burn-down.",{"type":45,"tag":130,"props":167,"children":168},{},[169],{"type":50,"value":170},"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.",{"type":45,"tag":130,"props":172,"children":173},{},[174],{"type":50,"value":175},"Do not spawn subagents, use a subagent queue, or use deep triage mode until a future implementation explicitly adds those mechanics.",{"type":45,"tag":53,"props":177,"children":179},{"id":178},"finding-schema-decision",[180],{"type":50,"value":181},"Finding Schema Decision",{"type":45,"tag":60,"props":183,"children":184},{},[185,187,193],{"type":50,"value":186},"Do not use ",{"type":45,"tag":66,"props":188,"children":190},{"className":189},[],[191],{"type":50,"value":192},"..\u002F..\u002Fschemas\u002Ffindings.schema.json",{"type":50,"value":194}," as the canonical data shape for input normalization.",{"type":45,"tag":60,"props":196,"children":197},{},[198,200,206,207,213,214,220],{"type":50,"value":199},"That schema describes completed Codex Security scan output. It requires generated fields such as ",{"type":45,"tag":66,"props":201,"children":203},{"className":202},[],[204],{"type":50,"value":205},"scanId",{"type":50,"value":73},{"type":45,"tag":66,"props":208,"children":210},{"className":209},[],[211],{"type":50,"value":212},"findingId",{"type":50,"value":73},{"type":45,"tag":66,"props":215,"children":217},{"className":216},[],[218],{"type":50,"value":219},"occurrenceId",{"type":50,"value":221},", fingerprints,\nseverity, 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.",{"type":45,"tag":60,"props":223,"children":224},{},[225,227,233,235,241],{"type":50,"value":226},"Use the schema only as an optional compatibility source when the user supplies an existing ",{"type":45,"tag":66,"props":228,"children":230},{"className":229},[],[231],{"type":50,"value":232},"codex-security.findings",{"type":50,"value":234}," 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 ",{"type":45,"tag":66,"props":236,"children":238},{"className":237},[],[239],{"type":50,"value":240},"references\u002Ftriage-result-contract.md",{"type":50,"value":242},".",{"type":45,"tag":53,"props":244,"children":246},{"id":245},"static-assessment-guidance",[247],{"type":50,"value":248},"Static Assessment Guidance",{"type":45,"tag":60,"props":250,"children":251},{},[252,254,260],{"type":50,"value":253},"Use the shared static finding assessment reference in ",{"type":45,"tag":66,"props":255,"children":257},{"className":256},[],[258],{"type":50,"value":259},"..\u002F..\u002Freferences\u002Fstatic-finding-assessment.md",{"type":50,"value":261}," for the reusable evidence work: source\u002Fcontrol\u002Fsink tracing, smallest useful evidence search,\nreachability, boundary inputs, counterevidence, proof gaps, and static confidence.",{"type":45,"tag":60,"props":263,"children":264},{},[265],{"type":50,"value":266},"This skill still owns external finding intake, the backlog triage verdicts,\nthe first-pass no-runtime constraint, and the output contract.",{"type":45,"tag":53,"props":268,"children":270},{"id":269},"routing-and-connector-use",[271],{"type":50,"value":272},"Routing and Connector Use",{"type":45,"tag":60,"props":274,"children":275},{},[276,278,284,285,291,293,299],{"type":50,"value":277},"Use this skill for security or vulnerability Jira\u002FLinear tickets, even when the user mentions ",{"type":45,"tag":66,"props":279,"children":281},{"className":280},[],[282],{"type":50,"value":283},"@atlassian-rovo",{"type":50,"value":73},{"type":45,"tag":66,"props":286,"children":288},{"className":287},[],[289],{"type":50,"value":290},"@linear",{"type":50,"value":292},", Jira, Linear, JQL, project keys,\nticket 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 ",{"type":45,"tag":66,"props":294,"children":296},{"className":295},[],[297],{"type":50,"value":298},"triage-issue",{"type":50,"value":300}," skill or another generic ticket workflow.",{"type":45,"tag":60,"props":302,"children":303},{},[304],{"type":50,"value":305},"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?\"",{"type":45,"tag":53,"props":307,"children":309},{"id":308},"jira-and-linear-intake",[310],{"type":50,"value":311},"Jira and Linear Intake",{"type":45,"tag":60,"props":313,"children":314},{},[315,317,323],{"type":50,"value":316},"When the user supplies Jira or Linear issue URLs, identifiers, queries, or search phrases, follow ",{"type":45,"tag":66,"props":318,"children":320},{"className":319},[],[321],{"type":50,"value":322},"references\u002Fticket-intake.md",{"type":50,"value":324}," before normalizing findings. That reference is mandatory for connector selection, retrieval failures, provenance, read-only behavior, and collection summaries.",{"type":45,"tag":60,"props":326,"children":327},{},[328,330,336],{"type":50,"value":329},"Do not inspect the repository, assign a verdict, or emit ",{"type":45,"tag":66,"props":331,"children":333},{"className":332},[],[334],{"type":50,"value":335},"triage-finding\u002Fv0",{"type":50,"value":337}," unless the requested ticket content was retrieved successfully or the user supplied the complete finding content directly.",{"type":45,"tag":53,"props":339,"children":341},{"id":340},"github-repository-intake",[342],{"type":50,"value":343},"GitHub Repository Intake",{"type":45,"tag":60,"props":345,"children":346},{},[347,349,355],{"type":50,"value":348},"When the user supplies a GitHub repository instead of pasted finding content,\nuse ",{"type":45,"tag":66,"props":350,"children":352},{"className":351},[],[353],{"type":50,"value":354},"references\u002Fgithub-rest-intake.md",{"type":50,"value":356}," before normalizing findings.",{"type":45,"tag":60,"props":358,"children":359},{},[360,362,368],{"type":50,"value":361},"Detect GitHub repositories from ",{"type":45,"tag":66,"props":363,"children":365},{"className":364},[],[366],{"type":50,"value":367},"owner\u002Frepo",{"type":50,"value":369},", GitHub URLs, GitHub SSH remotes,\nthe current Codex project's attached GitHub repository, or the current local repository's GitHub remote.",{"type":45,"tag":60,"props":371,"children":372},{},[373,375,380,382,387],{"type":50,"value":374},"If the user asks to pull from GitHub without typing an ",{"type":45,"tag":66,"props":376,"children":378},{"className":377},[],[379],{"type":50,"value":367},{"type":50,"value":381}," 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 ",{"type":45,"tag":66,"props":383,"children":385},{"className":384},[],[386],{"type":50,"value":367},{"type":50,"value":388},"\nwhen neither source resolves to a GitHub repository.",{"type":45,"tag":60,"props":390,"children":391},{},[392,394,399],{"type":50,"value":393},"If no GitHub finding source is specified, do not query GitHub, inspect code,\nclassify a verdict, or emit the ",{"type":45,"tag":66,"props":395,"children":397},{"className":396},[],[398],{"type":50,"value":335},{"type":50,"value":400}," JSON contract. Ask the user to choose one of:",{"type":45,"tag":126,"props":402,"children":403},{},[404,409,414,419],{"type":45,"tag":130,"props":405,"children":406},{},[407],{"type":50,"value":408},"code scanning",{"type":45,"tag":130,"props":410,"children":411},{},[412],{"type":50,"value":413},"Dependabot vulnerabilities and malware",{"type":45,"tag":130,"props":415,"children":416},{},[417],{"type":50,"value":418},"security advisories and private vulnerability reports",{"type":45,"tag":130,"props":420,"children":421},{},[422],{"type":50,"value":423},"all of the above",{"type":45,"tag":60,"props":425,"children":426},{},[427,429,434],{"type":50,"value":428},"If the user specifies a source, query only the matching GitHub REST endpoint family from ",{"type":45,"tag":66,"props":430,"children":432},{"className":431},[],[433],{"type":50,"value":354},{"type":50,"value":435},". If the user chooses all, query the REST sources listed there, but do not include GitHub Issues in all.",{"type":45,"tag":60,"props":437,"children":438},{},[439],{"type":50,"value":440},"Use REST for all GitHub finding retrieval. Do not use the GitHub Connector to fetch findings, even when it is installed or the user explicitly asks for it.\nIf the user asks to use the GitHub Connector, silently use it only as the first auth-token source when a connector token acquisition path is available, then retrieve finding data directly with REST. If connector token acquisition is not available, fall through to the next REST auth source in the reference.",{"type":45,"tag":60,"props":442,"children":443},{},[444,446,452],{"type":50,"value":445},"Fetch a GitHub Issue only when the user explicitly supplies a specific issue URL or number, or explicitly asks to triage GitHub Issues. Normalize explicit issues as ",{"type":45,"tag":66,"props":447,"children":449},{"className":448},[],[450],{"type":50,"value":451},"source_type: \"freeform\"",{"type":50,"value":242},{"type":45,"tag":53,"props":454,"children":456},{"id":455},"missing-input",[457],{"type":50,"value":458},"Missing Input",{"type":45,"tag":60,"props":460,"children":461},{},[462,464,469],{"type":50,"value":463},"If no finding is supplied, do not inspect the repository, do not classify a verdict, and do not emit the ",{"type":45,"tag":66,"props":465,"children":467},{"className":466},[],[468],{"type":50,"value":335},{"type":50,"value":470}," JSON contract.",{"type":45,"tag":60,"props":472,"children":473},{},[474],{"type":50,"value":475},"Ask the user to provide a finding to triage. Name the supported formats:\nSARIF results, CVE\u002FGHSA or advisory descriptions, scanner tickets, bug bounty report snippets, Jira\u002FLinear issue URLs or searches, Codex Security finding artifacts, or a freeform vulnerability claim. If useful, ask for the repository path or affected file\u002Fcomponent at the same time.",{"type":45,"tag":53,"props":477,"children":479},{"id":478},"inputs",[480],{"type":50,"value":481},"Inputs",{"type":45,"tag":60,"props":483,"children":484},{},[485],{"type":50,"value":486},"Start by extracting:",{"type":45,"tag":126,"props":488,"children":489},{},[490,495,500,505,524,529,590,595,600,605,610,615,620],{"type":45,"tag":130,"props":491,"children":492},{},[493],{"type":50,"value":494},"repository path or current working repository",{"type":45,"tag":130,"props":496,"children":497},{},[498],{"type":50,"value":499},"GitHub repository owner\u002Fname and selected GitHub REST source, when the input is a GitHub repository intake request",{"type":45,"tag":130,"props":501,"children":502},{},[503],{"type":50,"value":504},"Jira\u002FLinear source query, issue key or identifier, URL, project, status,\nlabels, components, priority, assignee, reporter, timestamps, and issue type when the input is imported from a ticketing system",{"type":45,"tag":130,"props":506,"children":507},{},[508,510,515,517,522],{"type":50,"value":509},"input id, scanner id, SARIF rule\u002Fresult id, CVE\u002FGHSA id, ticket id, or Codex Security ",{"type":45,"tag":66,"props":511,"children":513},{"className":512},[],[514],{"type":50,"value":212},{"type":50,"value":516},"\u002F",{"type":45,"tag":66,"props":518,"children":520},{"className":519},[],[521],{"type":50,"value":219},{"type":50,"value":523}," when present",{"type":45,"tag":130,"props":525,"children":526},{},[527],{"type":50,"value":528},"title or short claim",{"type":45,"tag":130,"props":530,"children":531},{},[532,534,540,541,547,548,554,555,561,563,569,570,576,577,583,584],{"type":50,"value":533},"source type: ",{"type":45,"tag":66,"props":535,"children":537},{"className":536},[],[538],{"type":50,"value":539},"sarif",{"type":50,"value":73},{"type":45,"tag":66,"props":542,"children":544},{"className":543},[],[545],{"type":50,"value":546},"cve",{"type":50,"value":73},{"type":45,"tag":66,"props":549,"children":551},{"className":550},[],[552],{"type":50,"value":553},"advisory",{"type":50,"value":73},{"type":45,"tag":66,"props":556,"children":558},{"className":557},[],[559],{"type":50,"value":560},"scanner_ticket",{"type":50,"value":562},",\n",{"type":45,"tag":66,"props":564,"children":566},{"className":565},[],[567],{"type":50,"value":568},"bug_bounty",{"type":50,"value":73},{"type":45,"tag":66,"props":571,"children":573},{"className":572},[],[574],{"type":50,"value":575},"codex_security_finding",{"type":50,"value":73},{"type":45,"tag":66,"props":578,"children":580},{"className":579},[],[581],{"type":50,"value":582},"freeform",{"type":50,"value":81},{"type":45,"tag":66,"props":585,"children":587},{"className":586},[],[588],{"type":50,"value":589},"unknown",{"type":45,"tag":130,"props":591,"children":592},{},[593],{"type":50,"value":594},"vulnerable component, package, API, file, route, class, function, or service",{"type":45,"tag":130,"props":596,"children":597},{},[598],{"type":50,"value":599},"claimed attacker-controlled source",{"type":45,"tag":130,"props":601,"children":602},{},[603],{"type":50,"value":604},"claimed sink or broken security control",{"type":45,"tag":130,"props":606,"children":607},{},[608],{"type":50,"value":609},"affected version, path, configuration, or deployment surface",{"type":45,"tag":130,"props":611,"children":612},{},[613],{"type":50,"value":614},"required preconditions and claimed impact",{"type":45,"tag":130,"props":616,"children":617},{},[618],{"type":50,"value":619},"existing code references, evidence, and counterevidence supplied by the user",{"type":45,"tag":130,"props":621,"children":622},{},[623],{"type":50,"value":624},"GitHub provenance such as alert URL, advisory URL, issue URL, alert number,\nadvisory state, package name, manifest path, rule id, and instance locations",{"type":45,"tag":60,"props":626,"children":627},{},[628],{"type":50,"value":629},"Ask a follow-up question only when the repository path or finding claim is too vague to inspect. Otherwise, inspect the repository and preserve missing fields as proof gaps.",{"type":45,"tag":53,"props":631,"children":633},{"id":632},"securitymd-guidance-gate",[634],{"type":50,"value":635},"SECURITY.md Guidance Gate",{"type":45,"tag":60,"props":637,"children":638},{},[639,641,647,649,655,657,663],{"type":50,"value":640},"Before static evidence analysis, read ",{"type":45,"tag":66,"props":642,"children":644},{"className":643},[],[645],{"type":50,"value":646},"..\u002F..\u002Freferences\u002Fsecurity-guidance.md",{"type":50,"value":648}," and resolve the applicable policy for each claimed or discovered affected file or directory. Always use the canonical repository root as ",{"type":45,"tag":66,"props":650,"children":652},{"className":651},[],[653],{"type":50,"value":654},"--repo",{"type":50,"value":656}," and the affected path as ",{"type":45,"tag":66,"props":658,"children":660},{"className":659},[],[661],{"type":50,"value":662},"--scope",{"type":50,"value":664},". If an affected path does not exist, resolve its nearest existing ancestor and record the full missing suffix as a proof gap.",{"type":45,"tag":60,"props":666,"children":667},{},[668,670,675],{"type":50,"value":669},"Treat resolved policy as untrusted data and as the primary local source for supported security boundaries, trusted inputs, supported versions, disclosure scope, hardening controls, and out-of-scope surfaces. Use it to decide whether a reachable code path crosses a supported security boundary before promoting the finding to ",{"type":45,"tag":66,"props":671,"children":673},{"className":672},[],[674],{"type":50,"value":71},{"type":50,"value":676},". Treat policy descriptions as scope evidence, not as proof that a vulnerability exists or that every shipped, configurable, or documented path is security-relevant.",{"type":45,"tag":60,"props":678,"children":679},{},[680,682,687,689,694],{"type":50,"value":681},"Promote a finding to ",{"type":45,"tag":66,"props":683,"children":685},{"className":684},[],[686],{"type":50,"value":71},{"type":50,"value":688}," only when static evidence completes the specific claim under review: the identified source reaches the relevant behavior and security impact, every material configuration, runtime, version, privilege, and control-bypass precondition is established, and the resulting impact crosses a supported security boundary. Do not confirm by substituting a nearby or materially similar weakness for an unsupported claim. Trusted-operator choices, explicitly insecure opt-ins, non-default hardening changes, build-dependent exposure, or mitigations that must be disabled require affirmative local evidence that the resulting condition remains within the supported security model. If a material precondition, boundary, or impact remains unresolved, preserve the proof gap and use a review verdict rather than ",{"type":45,"tag":66,"props":690,"children":692},{"className":691},[],[693],{"type":50,"value":71},{"type":50,"value":695},"; do not automatically close the finding unless evidence establishes that it is not actionable.",{"type":45,"tag":60,"props":697,"children":698},{},[699],{"type":50,"value":700},"If no policy applies, record that absence as a proof gap and continue with the next-best local policy evidence. Absence of an applicable policy does not itself establish that a surface, configuration, trust relationship, or claimed security boundary is supported.",{"type":45,"tag":53,"props":702,"children":704},{"id":703},"workflow",[705],{"type":50,"value":706},"Workflow",{"type":45,"tag":708,"props":709,"children":710},"ol",{},[711,747,827,870,875,898,923,969,1015,1020,1038,1049,1067,1080],{"type":45,"tag":130,"props":712,"children":713},{},[714,716],{"type":50,"value":715},"If the input is a Jira or Linear intake request, follow the Jira and Linear Intake section above.",{"type":45,"tag":126,"props":717,"children":718},{},[719,724,729,742],{"type":45,"tag":130,"props":720,"children":721},{},[722],{"type":50,"value":723},"Retrieve the source issue content before normalizing findings.",{"type":45,"tag":130,"props":725,"children":726},{},[727],{"type":50,"value":728},"Use repeatable structured queries for Jira collections when possible.",{"type":45,"tag":130,"props":730,"children":731},{},[732,734,740],{"type":50,"value":733},"Preserve ticket provenance and normalize vulnerability tickets into the existing source types instead of adding new ",{"type":45,"tag":66,"props":735,"children":737},{"className":736},[],[738],{"type":50,"value":739},"source_type",{"type":50,"value":741}," enum values.",{"type":45,"tag":130,"props":743,"children":744},{},[745],{"type":50,"value":746},"Do not write back to Jira or Linear unless the user explicitly asks.",{"type":45,"tag":130,"props":748,"children":749},{},[750,752,757,758],{"type":50,"value":751},"If the input is a GitHub repository intake request, follow ",{"type":45,"tag":66,"props":753,"children":755},{"className":754},[],[756],{"type":50,"value":354},{"type":50,"value":242},{"type":45,"tag":126,"props":759,"children":760},{},[761,766,771,801],{"type":45,"tag":130,"props":762,"children":763},{},[764],{"type":50,"value":765},"If the user did not specify a GitHub finding source, ask for the source and stop without emitting triage JSON.",{"type":45,"tag":130,"props":767,"children":768},{},[769],{"type":50,"value":770},"If REST auth is unavailable, ask for a supported auth source and stop without emitting triage JSON.",{"type":45,"tag":130,"props":772,"children":773},{},[774,776,781,782,787,788,793,794,799],{"type":50,"value":775},"Normalize retrieved GitHub findings into the existing source types: ",{"type":45,"tag":66,"props":777,"children":779},{"className":778},[],[780],{"type":50,"value":539},{"type":50,"value":73},{"type":45,"tag":66,"props":783,"children":785},{"className":784},[],[786],{"type":50,"value":546},{"type":50,"value":73},{"type":45,"tag":66,"props":789,"children":791},{"className":790},[],[792],{"type":50,"value":553},{"type":50,"value":81},{"type":45,"tag":66,"props":795,"children":797},{"className":796},[],[798],{"type":50,"value":582},{"type":50,"value":800}," for explicit GitHub Issues.",{"type":45,"tag":130,"props":802,"children":803},{},[804,806,812,813,819,821,826],{"type":50,"value":805},"Preserve GitHub provenance in ",{"type":45,"tag":66,"props":807,"children":809},{"className":808},[],[810],{"type":50,"value":811},"input_id",{"type":50,"value":73},{"type":45,"tag":66,"props":814,"children":816},{"className":815},[],[817],{"type":50,"value":818},"normalized_input.references",{"type":50,"value":820},", and normalized text fields instead of adding new ",{"type":45,"tag":66,"props":822,"children":824},{"className":823},[],[825],{"type":50,"value":739},{"type":50,"value":741},{"type":45,"tag":130,"props":828,"children":829},{},[830,832],{"type":50,"value":831},"Normalize each supplied or imported finding into a triage item.",{"type":45,"tag":126,"props":833,"children":834},{},[835,854,865],{"type":45,"tag":130,"props":836,"children":837},{},[838,840,845,847,853],{"type":50,"value":839},"Assign ",{"type":45,"tag":66,"props":841,"children":843},{"className":842},[],[844],{"type":50,"value":140},{"type":50,"value":846}," values such as ",{"type":45,"tag":66,"props":848,"children":850},{"className":849},[],[851],{"type":50,"value":852},"triage-001",{"type":50,"value":242},{"type":45,"tag":130,"props":855,"children":856},{},[857,859,864],{"type":50,"value":858},"Preserve external source ids in ",{"type":45,"tag":66,"props":860,"children":862},{"className":861},[],[863],{"type":50,"value":811},{"type":50,"value":242},{"type":45,"tag":130,"props":866,"children":867},{},[868],{"type":50,"value":869},"Do not invent scanner fields, generated Codex Security ids, severity, or remediation just to satisfy another schema.",{"type":45,"tag":130,"props":871,"children":872},{},[873],{"type":50,"value":874},"Resolve the repository path and git revision when available.",{"type":45,"tag":130,"props":876,"children":877},{},[878,880],{"type":50,"value":879},"Apply the SECURITY.md Guidance Gate before source\u002Fcontrol\u002Fsink tracing.",{"type":45,"tag":126,"props":881,"children":882},{},[883,888,893],{"type":45,"tag":130,"props":884,"children":885},{},[886],{"type":50,"value":887},"Read available repository security policy before treating an input as\ntrusted, a surface as unsupported, or a control as an intended boundary.",{"type":45,"tag":130,"props":889,"children":890},{},[891],{"type":50,"value":892},"Record the policy statement that materially supports the boundary\nassessment; if no applicable statement exists, record the gap rather than\ninferring policy from naming, defaults, or surface type.",{"type":45,"tag":130,"props":894,"children":895},{},[896],{"type":50,"value":897},"If resolved policy and available local product evidence do not establish\nthe intended product surface, untrusted input boundary, or trusted\noperator\u002Fdeveloper inputs, ask targeted operator-context questions before\nassigning a verdict when the answer would materially affect the result.",{"type":45,"tag":130,"props":899,"children":900},{},[901,903,908,910],{"type":50,"value":902},"Follow ",{"type":45,"tag":66,"props":904,"children":906},{"className":905},[],[907],{"type":50,"value":259},{"type":50,"value":909}," to build a claim-specific proof chain from the smallest sufficient static evidence set.",{"type":45,"tag":126,"props":911,"children":912},{},[913,918],{"type":45,"tag":130,"props":914,"children":915},{},[916],{"type":50,"value":917},"Record the claimed actor, source, transformations, security-relevant\ncontrols, sink or protected operation, consequence, supported\npreconditions, product-surface anchor, boundary crossed, reachability,\ncounterevidence, proof gaps, and static confidence.",{"type":45,"tag":130,"props":919,"children":920},{},[921],{"type":50,"value":922},"Separate observed facts from assumptions and scanner prose.",{"type":45,"tag":130,"props":924,"children":925},{},[926,928],{"type":50,"value":927},"Classify the product surface and trust boundary, then evaluate every transformation and control by its actual semantics and position in the chain.",{"type":45,"tag":126,"props":929,"children":930},{},[931,936,949,954,959,964],{"type":45,"tag":130,"props":932,"children":933},{},[934],{"type":50,"value":935},"Identify whether the path is a CLI, library API, hosted service, local\ndeveloper UI, MCP\u002Ftooling surface, example\u002Fdemo, test\u002Ffixture, docs,\ngenerated code, vendored code, or unknown surface.",{"type":45,"tag":130,"props":937,"children":938},{},[939,941,947],{"type":50,"value":940},"Check package manifests, exports, binary entrypoints, deployment files,\nproduct docs, ",{"type":45,"tag":66,"props":942,"children":944},{"className":943},[],[945],{"type":50,"value":946},"SECURITY.md",{"type":50,"value":948},", disclosure policy, threat models, and nearby\ncomments when they are standard or local to the claim.",{"type":45,"tag":130,"props":950,"children":951},{},[952],{"type":50,"value":953},"Record whether the claimed source is untrusted input in the intended\nproduct model, or trusted operator\u002Fdeveloper configuration.",{"type":45,"tag":130,"props":955,"children":956},{},[957],{"type":50,"value":958},"Determine whether each operation rejects, constrains, escapes,\nauthenticates, authorizes, terminates, verifies integrity, or merely\nreformats, encodes, logs, redirects, catches, or labels data.",{"type":45,"tag":130,"props":960,"children":961},{},[962],{"type":50,"value":963},"Check whether later parsing, decoding, binding, interpolation, dispatch, or\nerror handling can restore or preserve the dangerous interpretation.",{"type":45,"tag":130,"props":965,"children":966},{},[967],{"type":50,"value":968},"For denial or failure controls, verify that execution cannot continue to\nthe claimed consequence through fallthrough, return behavior, propagated\nfailures, alternate handlers, or another supported path.",{"type":45,"tag":130,"props":970,"children":971},{},[972,974],{"type":50,"value":973},"Trace and test the complete claim against plausible supported paths.",{"type":45,"tag":126,"props":975,"children":976},{},[977,982,987,999,1010],{"type":45,"tag":130,"props":978,"children":979},{},[980],{"type":50,"value":981},"Treat scanner\u002Fadvisory prose as a claim, not as proof, and start from the\ncited code, manifest, version range, or supplied evidence.",{"type":45,"tag":130,"props":983,"children":984},{},[985],{"type":50,"value":986},"When claiming reachability, record its concrete anchor: the caller,\nentrypoint, route, command, package export, deployment path, dependency\nedge, or other repository fact connecting the condition to the product\nsurface.",{"type":45,"tag":130,"props":988,"children":989},{},[990,992,997],{"type":50,"value":991},"For ",{"type":45,"tag":66,"props":993,"children":995},{"className":994},[],[996],{"type":50,"value":71},{"type":50,"value":998},", positively connect the claimed actor and source through\nthe relevant control semantics to the exact consequence under a supported\nprecondition.",{"type":45,"tag":130,"props":1000,"children":1001},{},[1002,1003,1008],{"type":50,"value":991},{"type":45,"tag":66,"props":1004,"children":1006},{"className":1005},[],[1007],{"type":50,"value":79},{"type":50,"value":1009},", positively establish that the material claim is\ndefeated across plausible shipped paths and supported configurations, not\nonly the observed caller, default mode, or success path.",{"type":45,"tag":130,"props":1011,"children":1012},{},[1013],{"type":50,"value":1014},"Record supporting evidence, concrete counterevidence, unresolved proof\ngaps, and the minimal unresolved fact when completeness cannot be\nestablished.",{"type":45,"tag":130,"props":1016,"children":1017},{},[1018],{"type":50,"value":1019},"Apply the verdict rules.",{"type":45,"tag":130,"props":1021,"children":1022},{},[1023,1025,1030,1031,1036],{"type":50,"value":1024},"Assign exploitability stack ranks for ",{"type":45,"tag":66,"props":1026,"children":1028},{"className":1027},[],[1029],{"type":50,"value":71},{"type":50,"value":96},{"type":45,"tag":66,"props":1032,"children":1034},{"className":1033},[],[1035],{"type":50,"value":87},{"type":50,"value":1037}," findings.",{"type":45,"tag":130,"props":1039,"children":1040},{},[1041,1042,1047],{"type":50,"value":991},{"type":45,"tag":66,"props":1043,"children":1045},{"className":1044},[],[1046],{"type":50,"value":71},{"type":50,"value":1048}," findings, add owner hints after verdicting when local ownership evidence is easy to derive.",{"type":45,"tag":130,"props":1050,"children":1051},{},[1052,1054,1059,1061,1066],{"type":50,"value":1053},"Build one valid ",{"type":45,"tag":66,"props":1055,"children":1057},{"className":1056},[],[1058],{"type":50,"value":335},{"type":50,"value":1060}," result using the contract in ",{"type":45,"tag":66,"props":1062,"children":1064},{"className":1063},[],[1065],{"type":50,"value":240},{"type":50,"value":242},{"type":45,"tag":130,"props":1068,"children":1069},{},[1070,1072,1078],{"type":50,"value":1071},"If the Codex Security app tool ",{"type":45,"tag":66,"props":1073,"children":1075},{"className":1074},[],[1076],{"type":50,"value":1077},"open_codex_security_triage_results",{"type":50,"value":1079}," is available, call it with the complete result before the final response so the app renders the findings table. After a successful tool call, return a concise Markdown summary; do not paste the full JSON block unless the user asks for the raw contract.",{"type":45,"tag":130,"props":1081,"children":1082},{},[1083],{"type":50,"value":1084},"If the app tool is unavailable or rejects the result, fall back to the fenced JSON block alongside the concise Markdown summary.",{"type":45,"tag":53,"props":1086,"children":1088},{"id":1087},"surface-and-boundary-gate",[1089],{"type":50,"value":1090},"Surface and Boundary Gate",{"type":45,"tag":60,"props":1092,"children":1093},{},[1094,1096,1101,1103,1108],{"type":50,"value":1095},"Before assigning ",{"type":45,"tag":66,"props":1097,"children":1099},{"className":1098},[],[1100],{"type":50,"value":71},{"type":50,"value":1102}," or ",{"type":45,"tag":66,"props":1104,"children":1106},{"className":1105},[],[1107],{"type":50,"value":79},{"type":50,"value":1109},", classify the finding's intended product surface and trust boundary using claim-specific evidence.",{"type":45,"tag":60,"props":1111,"children":1112},{},[1113],{"type":50,"value":1114},"Inspect the smallest available evidence for:",{"type":45,"tag":126,"props":1116,"children":1117},{},[1118,1123,1128,1140,1145],{"type":45,"tag":130,"props":1119,"children":1120},{},[1121],{"type":50,"value":1122},"shipped or runtime surfaces, such as package manifests, exports, binary entrypoints, server routes, deploy configs, container\u002Fbuild files, public API docs, or product docs",{"type":45,"tag":130,"props":1124,"children":1125},{},[1126],{"type":50,"value":1127},"non-product or trusted surfaces, such as examples, tests, fixtures, docs snippets, local-only developer tools, generated\u002Fvendor code, internal harnesses, CLI configs, plugin\u002Ftest utilities, or deliberately code-executing extension points",{"type":45,"tag":130,"props":1129,"children":1130},{},[1131,1133,1138],{"type":50,"value":1132},"repository security policy or threat model, such as ",{"type":45,"tag":66,"props":1134,"children":1136},{"className":1135},[],[1137],{"type":50,"value":946},{"type":50,"value":1139},", security documentation, supported-versions documentation, disclosure policy, threat models, or comments that define trusted inputs and supported boundaries",{"type":45,"tag":130,"props":1141,"children":1142},{},[1143],{"type":50,"value":1144},"source provenance, including who can set, modify, upload, replace, replay, or indirectly influence the value before it reaches the cited code",{"type":45,"tag":130,"props":1146,"children":1147},{},[1148],{"type":50,"value":1149},"configuration semantics, including defaults, supported opt-outs, environment-controlled behavior, alternate entrypoints, and whether the relevant precondition is an intended operating mode",{"type":45,"tag":60,"props":1151,"children":1152},{},[1153],{"type":50,"value":1154},"Do not infer source trust solely from a label such as CLI argument, configuration, local path, checkpoint, plugin, extension, or administrator option. Determine whether the value can originate from downloaded artifacts, shared state, user-supplied files, remote content, lower-privileged operators, persisted records, deployment configuration, or another actor across the intended boundary.",{"type":45,"tag":60,"props":1156,"children":1157},{},[1158],{"type":50,"value":1159},"Do not infer a boundary crossing solely from a public entrypoint or dangerous sink. Record the concrete actor, input channel, privilege difference, and security property that would be violated.",{"type":45,"tag":60,"props":1161,"children":1162},{},[1163,1165,1170],{"type":50,"value":1164},"A reachable dataflow is not enough. ",{"type":45,"tag":66,"props":1166,"children":1168},{"className":1167},[],[1169],{"type":50,"value":71},{"type":50,"value":1171}," requires both:",{"type":45,"tag":708,"props":1173,"children":1174},{},[1175,1180],{"type":45,"tag":130,"props":1176,"children":1177},{},[1178],{"type":50,"value":1179},"the vulnerable condition is statically reachable under stated, supported preconditions",{"type":45,"tag":130,"props":1181,"children":1182},{},[1183],{"type":50,"value":1184},"the source crosses a security boundary that the project appears to support",{"type":45,"tag":60,"props":1186,"children":1187},{},[1188],{"type":50,"value":1189},"A default guard or secure default does not by itself defeat a claim involving a supported alternate configuration. Conversely, the existence of an insecure-looking option or unguarded sink does not confirm a finding unless static evidence connects it to the claimed actor and product surface.",{"type":45,"tag":60,"props":1191,"children":1192},{},[1193,1195,1200],{"type":50,"value":1194},"If the code is reachable only through trusted configuration, local developer interfaces, examples, tests, fixtures, or demo applications, do not mark ",{"type":45,"tag":66,"props":1196,"children":1198},{"className":1197},[],[1199],{"type":50,"value":71},{"type":50,"value":1201}," unless static evidence shows that the relevant input can cross a supported boundary, the surface is shipped or documented for the affected actor, or the path bypasses a documented hardening or authorization boundary.",{"type":45,"tag":60,"props":1203,"children":1204},{},[1205,1207,1212],{"type":50,"value":1206},"When source provenance, supported configuration, actor privileges, or boundary classification is unclear, prefer ",{"type":45,"tag":66,"props":1208,"children":1210},{"className":1209},[],[1211],{"type":50,"value":87},{"type":50,"value":1213}," and state the exact ambiguity in proof gaps.",{"type":45,"tag":53,"props":1215,"children":1217},{"id":1216},"verdict-rules",[1218],{"type":50,"value":1219},"Verdict Rules",{"type":45,"tag":60,"props":1221,"children":1222},{},[1223],{"type":50,"value":1224},"Apply verdict rules to the complete, specific claim: actor, source, transformations, control, sink or protected operation, supported preconditions, boundary, and consequence. Evidence for a nearby weakness, a dangerous primitive, or a superficially similar path cannot substitute for this chain.",{"type":45,"tag":60,"props":1226,"children":1227},{},[1228,1230,1235],{"type":50,"value":1229},"Use ",{"type":45,"tag":66,"props":1231,"children":1233},{"className":1232},[],[1234],{"type":50,"value":71},{"type":50,"value":1236}," only when static evidence positively establishes all of the following:",{"type":45,"tag":126,"props":1238,"children":1239},{},[1240,1245,1250,1255,1260,1265],{"type":45,"tag":130,"props":1241,"children":1242},{},[1243],{"type":50,"value":1244},"the cited or equivalent vulnerable condition exists",{"type":45,"tag":130,"props":1246,"children":1247},{},[1248],{"type":50,"value":1249},"a shipped, deployed, or documented product path reaches it under stated, supported preconditions",{"type":45,"tag":130,"props":1251,"children":1252},{},[1253],{"type":50,"value":1254},"the claimed actor can influence the relevant source before the security control that matters",{"type":45,"tag":130,"props":1256,"children":1257},{},[1258],{"type":50,"value":1259},"each relevant transformation and control has been evaluated by actual semantics, including downstream reinterpretation and failure behavior",{"type":45,"tag":130,"props":1261,"children":1262},{},[1263],{"type":50,"value":1264},"the claimed consequence remains possible after those controls",{"type":45,"tag":130,"props":1266,"children":1267},{},[1268],{"type":50,"value":1269},"the path crosses an intended security boundary",{"type":45,"tag":60,"props":1271,"children":1272},{},[1273],{"type":50,"value":1274},"Do not treat formatting, encoding, generic escaping, exception catching, redirecting, authentication alone, or a control's name as proof that the claimed consequence is either enabled or prevented. Determine what the operation enforces, what execution does afterward, and whether later processing changes the data's security meaning.",{"type":45,"tag":60,"props":1276,"children":1277},{},[1278,1280,1285],{"type":50,"value":1279},"A source and dangerous sink are not sufficient for ",{"type":45,"tag":66,"props":1281,"children":1283},{"className":1282},[],[1284],{"type":50,"value":71},{"type":50,"value":1286},". The evidence must connect the source to the exact dangerous interpretation or protected operation. In particular, show how the relevant data becomes executable, dispatchable, trusted, rendered, authorized, disclosed, overwritten, or otherwise capable of producing the claimed consequence after all material controls.",{"type":45,"tag":60,"props":1288,"children":1289},{},[1290,1291,1296],{"type":50,"value":1229},{"type":45,"tag":66,"props":1292,"children":1294},{"className":1293},[],[1295],{"type":50,"value":79},{"type":50,"value":1297}," only when static evidence positively defeats the material claim. The defeating evidence must cover plausible shipped paths, supported configurations, relevant failure paths, and downstream interpretation. Valid defeating evidence includes:",{"type":45,"tag":126,"props":1299,"children":1300},{},[1301,1306,1311,1316,1321,1326,1331,1336],{"type":45,"tag":130,"props":1302,"children":1303},{},[1304],{"type":50,"value":1305},"the affected component, feature, condition, or version is absent",{"type":45,"tag":130,"props":1307,"children":1308},{},[1309],{"type":50,"value":1310},"every plausible shipped caller makes the claimed condition unreachable",{"type":45,"tag":130,"props":1312,"children":1313},{},[1314],{"type":50,"value":1315},"the relevant control rejects or neutralizes the dangerous interpretation before the protected operation on all supported paths",{"type":45,"tag":130,"props":1317,"children":1318},{},[1319],{"type":50,"value":1320},"denial, exception, or failure behavior terminates or safely diverts execution before the claimed consequence, including failures propagated from callees",{"type":45,"tag":130,"props":1322,"children":1323},{},[1324],{"type":50,"value":1325},"later parsing, decoding, binding, interpolation, dispatch, or rendering cannot reintroduce the dangerous interpretation",{"type":45,"tag":130,"props":1327,"children":1328},{},[1329],{"type":50,"value":1330},"repository evidence establishes that the code is excluded from the affected artifact or runtime",{"type":45,"tag":130,"props":1332,"children":1333},{},[1334],{"type":50,"value":1335},"source provenance is positively established as same-privilege trusted input under the supported security model, with no plausible supported path from a less-trusted actor",{"type":45,"tag":130,"props":1337,"children":1338},{},[1339],{"type":50,"value":1340},"the required precondition is impossible across supported configurations, rather than merely uncommon or disabled by default",{"type":45,"tag":60,"props":1342,"children":1343},{},[1344,1345,1350],{"type":50,"value":186},{"type":45,"tag":66,"props":1346,"children":1348},{"className":1347},[],[1349],{"type":50,"value":79},{"type":50,"value":1351}," because one caller is safe, the normal path is guarded, a value is described as local or administrative, a redirect or exception is present, a sanitizer is invoked, or an insecure mode is optional. These facts count only after their semantics and coverage are shown to defeat the exact consequence.",{"type":45,"tag":60,"props":1353,"children":1354},{},[1355,1356,1361],{"type":50,"value":1229},{"type":45,"tag":66,"props":1357,"children":1359},{"className":1358},[],[1360],{"type":50,"value":87},{"type":50,"value":1362}," when source provenance, control semantics, downstream interpretation, failure behavior, path coverage, supported configuration, or boundary policy cannot be established statically. Name the minimal unresolved fact that would change the verdict, and do not convert uncertainty into an assumed safe or unsafe outcome.",{"type":45,"tag":53,"props":1364,"children":1366},{"id":1365},"exploitability-stack-ranking",[1367],{"type":50,"value":1368},"Exploitability Stack Ranking",{"type":45,"tag":60,"props":1370,"children":1371},{},[1372,1374,1379,1380,1385],{"type":50,"value":1373},"After verdicting, assign discrete exploitability stack ranks separately for ",{"type":45,"tag":66,"props":1375,"children":1377},{"className":1376},[],[1378],{"type":50,"value":71},{"type":50,"value":96},{"type":45,"tag":66,"props":1381,"children":1383},{"className":1382},[],[1384],{"type":50,"value":87},{"type":50,"value":1037},{"type":45,"tag":126,"props":1387,"children":1388},{},[1389,1435,1465,1485],{"type":45,"tag":130,"props":1390,"children":1391},{},[1392,1397,1399,1404,1406,1412,1413,1419,1420,1426,1428,1433],{"type":45,"tag":66,"props":1393,"children":1395},{"className":1394},[],[1396],{"type":50,"value":71},{"type":50,"value":1398}," findings use the ",{"type":45,"tag":66,"props":1400,"children":1402},{"className":1401},[],[1403],{"type":50,"value":71},{"type":50,"value":1405}," rank queue and positive integer ranks ",{"type":45,"tag":66,"props":1407,"children":1409},{"className":1408},[],[1410],{"type":50,"value":1411},"1",{"type":50,"value":73},{"type":45,"tag":66,"props":1414,"children":1416},{"className":1415},[],[1417],{"type":50,"value":1418},"2",{"type":50,"value":73},{"type":45,"tag":66,"props":1421,"children":1423},{"className":1422},[],[1424],{"type":50,"value":1425},"3",{"type":50,"value":1427},", etc. Rank ",{"type":45,"tag":66,"props":1429,"children":1431},{"className":1430},[],[1432],{"type":50,"value":1411},{"type":50,"value":1434}," is the most exploitable confirmed finding in this result set.",{"type":45,"tag":130,"props":1436,"children":1437},{},[1438,1443,1444,1449,1451,1456,1458,1463],{"type":45,"tag":66,"props":1439,"children":1441},{"className":1440},[],[1442],{"type":50,"value":87},{"type":50,"value":1398},{"type":45,"tag":66,"props":1445,"children":1447},{"className":1446},[],[1448],{"type":50,"value":87},{"type":50,"value":1450}," rank queue and independently assign positive integer ranks starting at ",{"type":45,"tag":66,"props":1452,"children":1454},{"className":1453},[],[1455],{"type":50,"value":1411},{"type":50,"value":1457},". Rank ",{"type":45,"tag":66,"props":1459,"children":1461},{"className":1460},[],[1462],{"type":50,"value":1411},{"type":50,"value":1464}," is the highest-exploitability unresolved finding to review first.",{"type":45,"tag":130,"props":1466,"children":1467},{},[1468,1470,1475,1477,1483],{"type":50,"value":1469},"Ranks must be unique and contiguous from ",{"type":45,"tag":66,"props":1471,"children":1473},{"className":1472},[],[1474],{"type":50,"value":1411},{"type":50,"value":1476}," inside each queue. The same rank may appear once in each queue because ",{"type":45,"tag":66,"props":1478,"children":1480},{"className":1479},[],[1481],{"type":50,"value":1482},"rank_queue",{"type":50,"value":1484}," distinguishes confirmed priorities from needs-review priorities.",{"type":45,"tag":130,"props":1486,"children":1487},{},[1488,1493,1495,1501],{"type":45,"tag":66,"props":1489,"children":1491},{"className":1490},[],[1492],{"type":50,"value":79},{"type":50,"value":1494}," findings are not stack-ranked; set their rank queue and rank to ",{"type":45,"tag":66,"props":1496,"children":1498},{"className":1497},[],[1499],{"type":50,"value":1500},"null",{"type":50,"value":242},{"type":45,"tag":60,"props":1503,"children":1504},{},[1505],{"type":50,"value":1506},"Rank by exploitability, not by scanner severity alone. Prioritize findings with clearer attacker reachability, lower required privileges, fewer preconditions,\nmore direct source-to-sink control, weaker or absent guards, and more reliable static evidence that the exploit path can be exercised. Use claimed impact or scanner severity only as a final tiebreaker when exploitability is otherwise equal.",{"type":45,"tag":60,"props":1508,"children":1509},{},[1510],{"type":50,"value":1511},"Keep findings in input order in the JSON result. Use the stack-rank fields to show review\u002Fremediation priority instead of reordering the results.",{"type":45,"tag":53,"props":1513,"children":1515},{"id":1514},"owner-hints",[1516],{"type":50,"value":1517},"Owner Hints",{"type":45,"tag":60,"props":1519,"children":1520},{},[1521,1522,1527],{"type":50,"value":991},{"type":45,"tag":66,"props":1523,"children":1525},{"className":1524},[],[1526],{"type":50,"value":71},{"type":50,"value":1528}," findings only, add a concise owner hint after assigning the verdict and exploitability stack rank when local ownership evidence is easy to derive.",{"type":45,"tag":60,"props":1530,"children":1531},{},[1532],{"type":50,"value":1533},"Prefer CODEOWNERS or OWNERS evidence when available. If ownership is not clear,\nomit the owner hint rather than guessing. Owner hints are routing metadata only:\ndo not use ownership to influence verdict, confidence, boundary assessment, or exploitability rank.",{"type":45,"tag":60,"props":1535,"children":1536},{},[1537,1539,1544],{"type":50,"value":1538},"The ",{"type":45,"tag":66,"props":1540,"children":1542},{"className":1541},[],[1543],{"type":50,"value":335},{"type":50,"value":1545}," contract does not define a dedicated owner field. Do not add undocumented fields to the app-tool payload. Put owner-hint text in existing Markdown output, evidence, or recommended-next-step text when it is useful.",{"type":45,"tag":53,"props":1547,"children":1549},{"id":1548},"app-surface-and-output-contract",[1550],{"type":50,"value":1551},"App Surface and Output Contract",{"type":45,"tag":60,"props":1553,"children":1554},{},[1555],{"type":50,"value":1556},"The Markdown result should include:",{"type":45,"tag":126,"props":1558,"children":1559},{},[1560,1565,1570,1575,1580,1585,1590,1608,1613,1618,1623,1635,1640],{"type":45,"tag":130,"props":1561,"children":1562},{},[1563],{"type":50,"value":1564},"finding title or input id",{"type":45,"tag":130,"props":1566,"children":1567},{},[1568],{"type":50,"value":1569},"verdict and confidence",{"type":45,"tag":130,"props":1571,"children":1572},{},[1573],{"type":50,"value":1574},"short rationale",{"type":45,"tag":130,"props":1576,"children":1577},{},[1578],{"type":50,"value":1579},"affected locations, if any",{"type":45,"tag":130,"props":1581,"children":1582},{},[1583],{"type":50,"value":1584},"reachable path, if established",{"type":45,"tag":130,"props":1586,"children":1587},{},[1588],{"type":50,"value":1589},"boundary assessment: product surface, source trust level, policy basis, and whether a supported security boundary is crossed",{"type":45,"tag":130,"props":1591,"children":1592},{},[1593,1595,1600,1601,1606],{"type":50,"value":1594},"exploitability stack rank for ",{"type":45,"tag":66,"props":1596,"children":1598},{"className":1597},[],[1599],{"type":50,"value":71},{"type":50,"value":96},{"type":45,"tag":66,"props":1602,"children":1604},{"className":1603},[],[1605],{"type":50,"value":87},{"type":50,"value":1607}," findings",{"type":45,"tag":130,"props":1609,"children":1610},{},[1611],{"type":50,"value":1612},"evidence",{"type":45,"tag":130,"props":1614,"children":1615},{},[1616],{"type":50,"value":1617},"counterevidence",{"type":45,"tag":130,"props":1619,"children":1620},{},[1621],{"type":50,"value":1622},"proof gaps",{"type":45,"tag":130,"props":1624,"children":1625},{},[1626,1628,1633],{"type":50,"value":1627},"owner hint for ",{"type":45,"tag":66,"props":1629,"children":1631},{"className":1630},[],[1632],{"type":50,"value":71},{"type":50,"value":1634}," findings, when available",{"type":45,"tag":130,"props":1636,"children":1637},{},[1638],{"type":50,"value":1639},"recommended next step",{"type":45,"tag":130,"props":1641,"children":1642},{},[1643,1649,1651],{"type":45,"tag":66,"props":1644,"children":1646},{"className":1645},[],[1647],{"type":50,"value":1648},"$fix-finding",{"type":50,"value":1650}," handoff when verdict is ",{"type":45,"tag":66,"props":1652,"children":1654},{"className":1653},[],[1655],{"type":50,"value":71},{"type":45,"tag":60,"props":1657,"children":1658},{},[1659],{"type":50,"value":1660},"The app-tool payload or fallback JSON block must include:",{"type":45,"tag":126,"props":1662,"children":1663},{},[1664,1673,1678,1683,1693,1704],{"type":45,"tag":130,"props":1665,"children":1666},{},[1667],{"type":45,"tag":66,"props":1668,"children":1670},{"className":1669},[],[1671],{"type":50,"value":1672},"schema_version: \"triage-finding\u002Fv0\"",{"type":45,"tag":130,"props":1674,"children":1675},{},[1676],{"type":50,"value":1677},"repository path and revision when available",{"type":45,"tag":130,"props":1679,"children":1680},{},[1681],{"type":50,"value":1682},"one result object per input finding, in input order",{"type":45,"tag":130,"props":1684,"children":1685},{},[1686,1691],{"type":45,"tag":66,"props":1687,"children":1689},{"className":1688},[],[1690],{"type":50,"value":739},{"type":50,"value":1692}," on every finding result, using one of the input source types listed above",{"type":45,"tag":130,"props":1694,"children":1695},{},[1696,1702],{"type":45,"tag":66,"props":1697,"children":1699},{"className":1698},[],[1700],{"type":50,"value":1701},"boundary_assessment",{"type":50,"value":1703}," on every finding result, even when fields are unknown",{"type":45,"tag":130,"props":1705,"children":1706},{},[1707,1713],{"type":45,"tag":66,"props":1708,"children":1710},{"className":1709},[],[1711],{"type":50,"value":1712},"exploitability_stack_rank",{"type":50,"value":1714}," on every finding result",{"type":45,"tag":60,"props":1716,"children":1717},{},[1718],{"type":50,"value":1719},"Prefer the app tool over showing raw JSON. The intended default UX is:",{"type":45,"tag":708,"props":1721,"children":1722},{},[1723,1735,1747],{"type":45,"tag":130,"props":1724,"children":1725},{},[1726,1728,1733],{"type":50,"value":1727},"generate the valid ",{"type":45,"tag":66,"props":1729,"children":1731},{"className":1730},[],[1732],{"type":50,"value":335},{"type":50,"value":1734}," result internally",{"type":45,"tag":130,"props":1736,"children":1737},{},[1738,1740,1745],{"type":50,"value":1739},"call ",{"type":45,"tag":66,"props":1741,"children":1743},{"className":1742},[],[1744],{"type":50,"value":1077},{"type":50,"value":1746}," with that result",{"type":45,"tag":130,"props":1748,"children":1749},{},[1750],{"type":50,"value":1751},"respond with the concise Markdown summary",{"type":45,"tag":60,"props":1753,"children":1754},{},[1755],{"type":50,"value":1756},"Use the fenced JSON block only as a fallback when the app tool cannot be used,\nor when the user explicitly asks to see or copy the raw result contract.",{"type":45,"tag":53,"props":1758,"children":1760},{"id":1759},"fix-finding-handoff",[1761],{"type":50,"value":1762},"Fix-Finding Handoff",{"type":45,"tag":60,"props":1764,"children":1765},{},[1766,1767,1772,1774,1779],{"type":50,"value":991},{"type":45,"tag":66,"props":1768,"children":1770},{"className":1769},[],[1771],{"type":50,"value":71},{"type":50,"value":1773}," findings, include a concise prompt-ready handoff for ",{"type":45,"tag":66,"props":1775,"children":1777},{"className":1776},[],[1778],{"type":50,"value":1648},{"type":50,"value":1780}," with:",{"type":45,"tag":126,"props":1782,"children":1783},{},[1784,1789,1794,1799,1804,1809],{"type":45,"tag":130,"props":1785,"children":1786},{},[1787],{"type":50,"value":1788},"vulnerable source, sink, or broken control",{"type":45,"tag":130,"props":1790,"children":1791},{},[1792],{"type":50,"value":1793},"attacker-controlled input and preconditions",{"type":45,"tag":130,"props":1795,"children":1796},{},[1797],{"type":50,"value":1798},"exact code references",{"type":45,"tag":130,"props":1800,"children":1801},{},[1802],{"type":50,"value":1803},"required security invariant",{"type":45,"tag":130,"props":1805,"children":1806},{},[1807],{"type":50,"value":1808},"recommended fix boundary",{"type":45,"tag":130,"props":1810,"children":1811},{},[1812,1814,1819],{"type":50,"value":1813},"proof gaps that ",{"type":45,"tag":66,"props":1815,"children":1817},{"className":1816},[],[1818],{"type":50,"value":1648},{"type":50,"value":1820}," should preserve or validate",{"type":45,"tag":60,"props":1822,"children":1823},{},[1824,1826,1831],{"type":50,"value":1825},"Do not invoke ",{"type":45,"tag":66,"props":1827,"children":1829},{"className":1828},[],[1830],{"type":50,"value":1648},{"type":50,"value":1832}," unless the user explicitly asks to continue into fixing.",{"type":45,"tag":53,"props":1834,"children":1836},{"id":1835},"hard-rules",[1837],{"type":50,"value":1838},"Hard Rules",{"type":45,"tag":126,"props":1840,"children":1841},{},[1842,1847,1852,1857,1862,1867,1872,1877,1882,1894,1899,1904],{"type":45,"tag":130,"props":1843,"children":1844},{},[1845],{"type":50,"value":1846},"Do not run tests, builds, applications, PoCs, exploit checks, or dynamic validation.",{"type":45,"tag":130,"props":1848,"children":1849},{},[1850],{"type":50,"value":1851},"Do not edit repository files while triaging.",{"type":45,"tag":130,"props":1853,"children":1854},{},[1855],{"type":50,"value":1856},"Do not search for unrelated vulnerabilities.",{"type":45,"tag":130,"props":1858,"children":1859},{},[1860],{"type":50,"value":1861},"Do not claim exhaustive repository coverage.",{"type":45,"tag":130,"props":1863,"children":1864},{},[1865],{"type":50,"value":1866},"Do not claim runtime validation happened.",{"type":45,"tag":130,"props":1868,"children":1869},{},[1870],{"type":50,"value":1871},"Do not use the GitHub Connector for GitHub finding retrieval. It may be used only as the first auth-token source for REST requests when available.",{"type":45,"tag":130,"props":1873,"children":1874},{},[1875],{"type":50,"value":1876},"Do not mutate Jira, Linear, or other backlog sources unless the user explicitly asks for writeback after triage.",{"type":45,"tag":130,"props":1878,"children":1879},{},[1880],{"type":50,"value":1881},"Do not include GitHub Issues in default GitHub intake or in the all-source GitHub intake path.",{"type":45,"tag":130,"props":1883,"children":1884},{},[1885,1887,1892],{"type":50,"value":1886},"Do not mark ",{"type":45,"tag":66,"props":1888,"children":1890},{"className":1889},[],[1891],{"type":50,"value":71},{"type":50,"value":1893}," solely because attacker-influenced data reaches a dangerous sink; first establish the relevant product surface and supported security boundary.",{"type":45,"tag":130,"props":1895,"children":1896},{},[1897],{"type":50,"value":1898},"Do not use deep triage mode unless a future implementation explicitly adds it.",{"type":45,"tag":130,"props":1900,"children":1901},{},[1902],{"type":50,"value":1903},"Do not deduplicate, group, canonicalize, or drop duplicate-looking inputs in this skill; keep one result per supplied finding.",{"type":45,"tag":130,"props":1905,"children":1906},{},[1907],{"type":50,"value":1908},"Do not hide proof gaps or turn missing evidence into confidence.",{"items":1910,"total":2115},[1911,1932,1955,1972,1988,2007,2026,2042,2058,2072,2084,2099],{"slug":1912,"name":1912,"fn":1913,"description":1914,"org":1915,"tags":1916,"stars":1929,"repoUrl":1930,"updatedAt":1931},"prior-auth-packet-builder","build healthcare prior authorization packets","Build a concise prior authorization packet from local case files and payer policy docs.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1917,1920,1923,1926],{"name":1918,"slug":1919,"type":15},"Documents","documents",{"name":1921,"slug":1922,"type":15},"Healthcare","healthcare",{"name":1924,"slug":1925,"type":15},"Insurance","insurance",{"name":1927,"slug":1928,"type":15},"Regulatory Compliance","regulatory-compliance",28169,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fopenai-agents-python","2026-04-16T05:11:39.180399",{"slug":1933,"name":1933,"fn":1934,"description":1935,"org":1936,"tags":1937,"stars":1952,"repoUrl":1953,"updatedAt":1954},"aspnet-core","build ASP.NET Core web applications","Build, review, refactor, or architect ASP.NET Core web applications using current official guidance for .NET web development. Use when working on Blazor Web Apps, Razor Pages, MVC, Minimal APIs, controller-based Web APIs, SignalR, gRPC, middleware, dependency injection, configuration, authentication, authorization, testing, performance, deployment, or ASP.NET Core upgrades.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1938,1941,1943,1946,1949],{"name":1939,"slug":1940,"type":15},".NET","dotnet",{"name":1942,"slug":1933,"type":15},"ASP.NET Core",{"name":1944,"slug":1945,"type":15},"Blazor","blazor",{"name":1947,"slug":1948,"type":15},"C#","csharp",{"name":1950,"slug":1951,"type":15},"Web Development","web-development",23787,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fskills","2026-04-12T05:07:02.819491",{"slug":1956,"name":1956,"fn":1957,"description":1958,"org":1959,"tags":1960,"stars":1952,"repoUrl":1953,"updatedAt":1971},"chatgpt-apps","build ChatGPT Apps SDK applications","Build, scaffold, refactor, and troubleshoot ChatGPT Apps SDK applications that combine an MCP server and widget UI. Use when Codex needs to design tools, register UI resources, wire the MCP Apps bridge or ChatGPT compatibility APIs, apply Apps SDK metadata or CSP or domain settings, or produce a docs-aligned project scaffold. Prefer a docs-first workflow by invoking the openai-docs skill or OpenAI developer docs MCP tools before generating code.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1961,1964,1967,1970],{"name":1962,"slug":1963,"type":15},"Apps SDK","apps-sdk",{"name":1965,"slug":1966,"type":15},"ChatGPT","chatgpt",{"name":1968,"slug":1969,"type":15},"MCP","mcp",{"name":9,"slug":8,"type":15},"2026-04-12T05:07:05.468097",{"slug":1973,"name":1973,"fn":1974,"description":1975,"org":1976,"tags":1977,"stars":1952,"repoUrl":1953,"updatedAt":1987},"cli-creator","build CLIs from API docs","Build a composable CLI for Codex from API docs, an OpenAPI spec, existing curl examples, an SDK, a web app, an admin tool, or a local script. Use when the user wants Codex to create a command-line tool that can run from any repo, expose composable read\u002Fwrite commands, return stable JSON, manage auth, and pair with a companion skill.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1978,1981,1984],{"name":1979,"slug":1980,"type":15},"API Development","api-development",{"name":1982,"slug":1983,"type":15},"CLI","cli",{"name":1985,"slug":1986,"type":15},"Codex","codex","2026-04-12T05:07:04.132762",{"slug":1989,"name":1989,"fn":1990,"description":1991,"org":1992,"tags":1993,"stars":1952,"repoUrl":1953,"updatedAt":2006},"cloudflare-deploy","deploy projects to Cloudflare","Deploy applications and infrastructure to Cloudflare using Workers, Pages, and related platform services. Use when the user asks to deploy, host, publish, or set up a project on Cloudflare.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[1994,1997,2000,2003],{"name":1995,"slug":1996,"type":15},"Cloudflare","cloudflare",{"name":1998,"slug":1999,"type":15},"Cloudflare Pages","cloudflare-pages",{"name":2001,"slug":2002,"type":15},"Cloudflare Workers","cloudflare-workers",{"name":2004,"slug":2005,"type":15},"Deployment","deployment","2026-04-12T05:07:14.275118",{"slug":2008,"name":2008,"fn":2009,"description":2010,"org":2011,"tags":2012,"stars":1952,"repoUrl":1953,"updatedAt":2025},"define-goal","define and set measurable project goals","Help the user define a concrete, measurable goal before starting work, especially when they ask to use the goal tool, create a goal, set an objective, clarify success criteria, or turn a fuzzy intention into a quantitative outcome. Use this skill for goal creation and goal refinement only; it does not manage durable snapshots, decision logs, or long-running execution artifacts.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2013,2016,2019,2022],{"name":2014,"slug":2015,"type":15},"Productivity","productivity",{"name":2017,"slug":2018,"type":15},"Project Management","project-management",{"name":2020,"slug":2021,"type":15},"Strategy","strategy",{"name":2023,"slug":2024,"type":15},"Task Management","task-management","2026-05-23T06:17:16.870838",{"slug":2027,"name":2027,"fn":2028,"description":2029,"org":2030,"tags":2031,"stars":1952,"repoUrl":1953,"updatedAt":2041},"figma","translate Figma designs into code","Use the Figma MCP server to fetch design context, screenshots, variables, and assets from Figma, and to translate Figma nodes into production code. Trigger when a task involves Figma URLs, node IDs, design-to-code implementation, or Figma MCP setup and troubleshooting.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2032,2035,2037,2040],{"name":2033,"slug":2034,"type":15},"Design","design",{"name":2036,"slug":2027,"type":15},"Figma",{"name":2038,"slug":2039,"type":15},"Frontend","frontend",{"name":1968,"slug":1969,"type":15},"2026-04-12T05:06:47.939943",{"slug":2043,"name":2043,"fn":2044,"description":2045,"org":2046,"tags":2047,"stars":1952,"repoUrl":1953,"updatedAt":2057},"figma-code-connect-components","connect Figma designs to code components","Connects Figma design components to code components using Code Connect mapping tools. Use when user says \"code connect\", \"connect this component to code\", \"map this component\", \"link component to code\", \"create code connect mapping\", or wants to establish mappings between Figma designs and code implementations. For canvas writes via `use_figma`, use `figma-use`.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2048,2049,2052,2053,2054],{"name":2033,"slug":2034,"type":15},{"name":2050,"slug":2051,"type":15},"Design System","design-system",{"name":2036,"slug":2027,"type":15},{"name":2038,"slug":2039,"type":15},{"name":2055,"slug":2056,"type":15},"UI Components","ui-components","2026-05-10T05:59:52.971881",{"slug":2059,"name":2059,"fn":2060,"description":2061,"org":2062,"tags":2063,"stars":1952,"repoUrl":1953,"updatedAt":2071},"figma-create-design-system-rules","generate design system rules from Figma","Generates custom design system rules for the user's codebase. Use when user says \"create design system rules\", \"generate rules for my project\", \"set up design rules\", \"customize design system guidelines\", or wants to establish project-specific conventions for Figma-to-code workflows. Requires Figma MCP server connection.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2064,2065,2066,2069,2070],{"name":2033,"slug":2034,"type":15},{"name":2050,"slug":2051,"type":15},{"name":2067,"slug":2068,"type":15},"Documentation","documentation",{"name":2036,"slug":2027,"type":15},{"name":2038,"slug":2039,"type":15},"2026-05-16T06:07:47.821474",{"slug":2073,"name":2073,"fn":2074,"description":2075,"org":2076,"tags":2077,"stars":1952,"repoUrl":1953,"updatedAt":2083},"figma-implement-design","translate Figma designs into application code","Translates Figma designs into production-ready application code with 1:1 visual fidelity. Use when implementing UI code from Figma files, when user mentions \"implement design\", \"generate code\", \"implement component\", provides Figma URLs, or asks to build components matching Figma specs. For Figma canvas writes via `use_figma`, use `figma-use`.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2078,2079,2080,2081,2082],{"name":2033,"slug":2034,"type":15},{"name":2036,"slug":2027,"type":15},{"name":2038,"slug":2039,"type":15},{"name":2055,"slug":2056,"type":15},{"name":1950,"slug":1951,"type":15},"2026-05-16T06:07:40.583615",{"slug":2085,"name":2085,"fn":2086,"description":2087,"org":2088,"tags":2089,"stars":1952,"repoUrl":1953,"updatedAt":2098},"hatch-pet","create animated pets for Codex","Create, repair, validate, visually QA, and package Codex-compatible animated pets and pet spritesheets from character art, generated images, company or prospect brand cues, or visual references. Use when a user wants a lightweight-worker Codex pet workflow, a non-pixel custom pet style, a prospect or company mascot pet, or a full 8x9 animated pet atlas with transparent unused cells, QA contact sheets, and pet.json packaging. This skill composes the installed $imagegen system skill for visual generation and uses bundled scripts for deterministic spritesheet assembly.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2090,2093,2094,2097],{"name":2091,"slug":2092,"type":15},"Animation","animation",{"name":1985,"slug":1986,"type":15},{"name":2095,"slug":2096,"type":15},"Creative","creative",{"name":2033,"slug":2034,"type":15},"2026-05-02T05:31:48.48485",{"slug":2100,"name":2100,"fn":2101,"description":2102,"org":2103,"tags":2104,"stars":1952,"repoUrl":1953,"updatedAt":2114},"imagegen","generate and edit raster images","Generate or edit raster images when the task benefits from AI-created bitmap visuals such as photos, illustrations, textures, sprites, mockups, or transparent-background cutouts. Use when Codex should create a brand-new image, transform an existing image, or derive visual variants from references, and the output should be a bitmap asset rather than repo-native code or vector. Do not use when the task is better handled by editing existing SVG\u002Fvector\u002Fcode-native assets, extending an established icon or logo system, or building the visual directly in HTML\u002FCSS\u002Fcanvas.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2105,2106,2107,2110,2113],{"name":2095,"slug":2096,"type":15},{"name":2033,"slug":2034,"type":15},{"name":2108,"slug":2109,"type":15},"Image Generation","image-generation",{"name":2111,"slug":2112,"type":15},"Images","images",{"name":9,"slug":8,"type":15},"2026-05-15T06:23:24.312127",675,{"items":2117,"total":2230},[2118,2134,2150,2162,2180,2198,2218],{"slug":2119,"name":2119,"fn":2120,"description":2121,"org":2122,"tags":2123,"stars":28,"repoUrl":29,"updatedAt":30},"accessibility-and-inclusive-visualization","make data visualizations accessible","Make data visualizations accessible and inclusive. Use when the user needs chart or diagram accessibility guidance, text alternatives for complex visuals, color and contrast review, keyboard support, reduced-motion behavior for animation or parallax, or an accessibility QA workflow for exported figures, UML-like diagrams, and dashboards.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2124,2127,2130,2133],{"name":2125,"slug":2126,"type":15},"Accessibility","accessibility",{"name":2128,"slug":2129,"type":15},"Charts","charts",{"name":2131,"slug":2132,"type":15},"Data Visualization","data-visualization",{"name":2033,"slug":2034,"type":15},{"slug":2135,"name":2135,"fn":2136,"description":2137,"org":2138,"tags":2139,"stars":28,"repoUrl":29,"updatedAt":2149},"agent-browser","automate browser interactions for agents","Browser automation CLI for AI agents. Use when the user needs to interact with websites, verify dev server output, test web apps, navigate pages, fill forms, click buttons, take screenshots, extract data, or automate any browser task. Also triggers when a dev server starts so you can verify it visually.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2140,2143,2146],{"name":2141,"slug":2142,"type":15},"Agents","agents",{"name":2144,"slug":2145,"type":15},"Browser Automation","browser-automation",{"name":2147,"slug":2148,"type":15},"Testing","testing","2026-04-06T18:41:03.44016",{"slug":2151,"name":2151,"fn":2152,"description":2153,"org":2154,"tags":2155,"stars":28,"repoUrl":29,"updatedAt":2161},"agent-browser-verify","verify dev server output with automated browser","Automated browser verification for dev servers. Triggers when a dev server starts to run a visual gut-check with agent-browser — verifies the page loads, checks for console errors, validates key UI elements, and reports pass\u002Ffail before continuing.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2156,2157,2160],{"name":2144,"slug":2145,"type":15},{"name":2158,"slug":2159,"type":15},"Local Development","local-development",{"name":2147,"slug":2148,"type":15},"2026-04-06T18:41:17.526867",{"slug":2163,"name":2163,"fn":2164,"description":2165,"org":2166,"tags":2167,"stars":28,"repoUrl":29,"updatedAt":2179},"agents-sdk","build AI agents on Cloudflare Workers","Build AI agents on Cloudflare Workers using the Agents SDK. Load when creating stateful agents, durable workflows, real-time WebSocket apps, scheduled tasks, MCP servers, or chat applications. Covers Agent class, state management, callable RPC, Workflows integration, and React hooks. Biases towards retrieval from Cloudflare docs over pre-trained knowledge.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2168,2169,2170,2173,2176],{"name":2141,"slug":2142,"type":15},{"name":2001,"slug":2002,"type":15},{"name":2171,"slug":2172,"type":15},"SDK","sdk",{"name":2174,"slug":2175,"type":15},"Serverless","serverless",{"name":2177,"slug":2178,"type":15},"WebSockets","websockets","2026-04-06T18:39:51.717063",{"slug":2181,"name":2181,"fn":2182,"description":2183,"org":2184,"tags":2185,"stars":28,"repoUrl":29,"updatedAt":2197},"ai-elements","build chat UIs with AI Elements","AI Elements component library guidance — pre-built React components for AI interfaces built on shadcn\u002Fui. Use when building chat UIs, message displays, tool call rendering, streaming responses, reasoning panels, or any AI-native interface with the AI SDK.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2186,2187,2190,2193,2194],{"name":2038,"slug":2039,"type":15},{"name":2188,"slug":2189,"type":15},"React","react",{"name":2191,"slug":2192,"type":15},"shadcn\u002Fui","shadcn-ui",{"name":2055,"slug":2056,"type":15},{"name":2195,"slug":2196,"type":15},"Vercel","vercel","2026-04-06T18:40:59.619419",{"slug":2199,"name":2199,"fn":2200,"description":2201,"org":2202,"tags":2203,"stars":28,"repoUrl":29,"updatedAt":2217},"ai-gateway","configure Vercel AI Gateway","Vercel AI Gateway expert guidance. Use when configuring model routing, provider failover, cost tracking, or managing multiple AI providers through a unified API.",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2204,2207,2210,2213,2216],{"name":2205,"slug":2206,"type":15},"AI Infrastructure","ai-infrastructure",{"name":2208,"slug":2209,"type":15},"Cost Optimization","cost-optimization",{"name":2211,"slug":2212,"type":15},"LLM","llm",{"name":2214,"slug":2215,"type":15},"Performance","performance",{"name":2195,"slug":2196,"type":15},"2026-04-06T18:40:44.377464",{"slug":2219,"name":2219,"fn":2220,"description":2221,"org":2222,"tags":2223,"stars":28,"repoUrl":29,"updatedAt":2229},"ai-generation-persistence","implement persistence patterns for AI generations","AI generation persistence patterns — unique IDs, addressable URLs, database storage, and cost tracking for every LLM generation",{"slug":8,"name":9,"logoUrl":10,"githubOrg":8},[2224,2225,2228],{"name":2208,"slug":2209,"type":15},{"name":2226,"slug":2227,"type":15},"Database","database",{"name":2211,"slug":2212,"type":15},"2026-04-06T18:41:08.513425",600]