[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-openai-security-scan":3,"mdc--fmzvos-key":36,"related-org-openai-security-scan":1563,"related-repo-openai-security-scan":1768},{"slug":4,"name":4,"fn":5,"description":6,"org":7,"tags":11,"stars":25,"repoUrl":26,"updatedAt":27,"license":28,"forks":29,"topics":30,"repo":31,"sourceUrl":34,"mdContent":35},"security-scan","run comprehensive security scans on repositories","Use for a standard, single-pass security audit of an entire repository or a scoped path, package folder, or submodule with no diff to review.  This is the default repository scan.  Do not use for PR\u002Fcommit\u002Fbranch\u002Fworking-tree diffs, or for deep, multi-pass, or variance-reducing scans.",{"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],{"name":13,"slug":14,"type":15},"Security","security","tag",{"name":17,"slug":18,"type":15},"Code Review","code-review",{"name":20,"slug":21,"type":15},"Audit","audit",{"name":23,"slug":24,"type":15},"Codex","codex",3992,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fplugins","2026-05-01T06:02:26.78875",null,465,[],{"repoUrl":26,"stars":25,"forks":29,"topics":32,"description":33},[],"OpenAI Plugins","https:\u002F\u002Fgithub.com\u002Fopenai\u002Fplugins\u002Ftree\u002FHEAD\u002Fplugins\u002Fcodex-security\u002Fskills\u002Fsecurity-scan","---\nname: security-scan\ndescription: \"Use for a standard, single-pass security audit of an entire repository or a scoped path, package folder, or submodule with no diff to review.  This is the default repository scan.  Do not use for PR\u002Fcommit\u002Fbranch\u002Fworking-tree diffs, or for deep, multi-pass, or variance-reducing scans.\"\n---\n\n# Security Scan\n\nUsed when a user wants to audit an entire repository or a user-specified path, package, folder, or submodule-like scope for security vulnerabilities. Keep the scan phases separate and produce the final markdown report.\n\n## Setup Workspace Routing\n\nWhen this skill is the active top-level workflow, use the setup workspace only when the host context explicitly says it is running inside the Codex desktop app and both required setup continuation tools are available. Tool availability alone does not identify the app host. Otherwise, including Codex CLI interactive and headless runs, use the prompt-only terminal\u002Fchat workflow: do not call Codex Security app setup tools, ask the user to press Start scan, or wait for an app-generated `scanId`.\n\nTreat goal creation as scan execution, not setup. In the app setup path, do not create or adopt scan goals before the user presses Start scan, the authoritative scan context has been loaded from a `status: \"started\"` wait result or a direct continuation with a `scanId`, and the capability preflight has returned `ready`.\n\nFor an app continuation that already includes a `scanId` and optional `handoffClaimToken`, do not open another workspace: call `get_codex_security_scan_context` with the `scanId`, pass its `handoffClaimToken` when present, route elsewhere only if its validated mode differs, and use its target, scope, optional `userContext`, and `scanDir`.\n\nOtherwise, in a host that renders MCP Apps and exposes the Codex Security setup continuation tools:\n\n1. Resolve setup arguments directly from the user's initial prompt and known thread context: local `targetPath`, `mode: \"standard\"`, target-relative `scope` (`\".\"` for the whole target), and only user-supplied security focus as `userContext`.\n2. Perform only the minimal path resolution needed to construct those arguments. Do not run capability preflight, inspect the repository, threat model, discover findings, or create workers before setup opens.\n3. Immediately call `open_codex_security_workspace` with the resolved arguments. Do not search for or substitute a separate scan command.\n4. Immediately call `await_codex_security_scan_start` with the `sessionId` from the workspace returned by `open_codex_security_workspace`. A returned workspace with `setup.submitted=false` is the expected wait state. Keep the tool call pending while waiting for the user to review setup and press Start scan; do not create or adopt a scan goal, run preflight, or pivot to terminal\u002Fchat fallback while waiting.\n5. If the wait returns `status: \"started\"`, require its `scanId`, call `get_codex_security_scan_context` with that `scanId`, and pass its `handoffClaimToken` when present. Then run the preflight in `..\u002F..\u002Freferences\u002Fconfig-preflight.md` for the selected target and `security_scan` profile before goal setup, threat modeling, or other substantive scan work.\n6. If the wait returns `status: \"already_delivered\"`, end the current turn without loading scan context or starting scan work. Another continuation already owns the scan.\n7. If the wait returns `status: \"timed_out\"`, end the current turn and tell the user to finish setup and use **Continue in Codex** after pressing Start scan. Do not run preflight, create or adopt a scan goal, open another workspace, or pivot to terminal\u002Fchat fallback.\n8. Continue after a `ready` result, explaining material warn or suggest limitations. If preflight is `blocked` or `incomplete` with actionable remediation, present the exact reasons and config delta, ask whether to apply the remediation, and stop for the user's answer before creating or adopting a scan goal or calling `fail_codex_security_scan`. Do not fail automatically for declined or unavailable remediation, helper errors, or a non-ready rerun. Preserve the running scan and retry or hand off while recovery may still be possible. If the user declines required remediation, ask whether to cancel or leave the scan running for a later retry. Call `fail_codex_security_scan` with the exact reason only after documented recovery is exhausted and the blocker is confirmed unrecoverable, or when the user explicitly cancels.\n\nIn Codex CLI, including interactive and headless runs, or hosts without those capabilities, use the existing prompt-only terminal\u002Fchat preflight and scan workflow and shared artifact paths. Do not call `open_codex_security_workspace` or `await_codex_security_scan_start` on this path. Once `open_codex_security_workspace` succeeds in an MCP Apps-capable host, remain on the app path: immediately call `await_codex_security_scan_start`; a `status: \"timed_out\"` result means end the turn and point the user to **Continue in Codex**, while `status: \"already_delivered\"` means stop because another continuation owns the scan. Do not start a terminal\u002Fchat fallback for either result.\n\n## Capability Preflight\n\nRead `..\u002F..\u002Freferences\u002Fconfig-preflight.md` and dispatch and await the preflight execution described there with the `security_scan` capability profile before substantive scan work, including after an app wait or direct continuation has produced a `scanId` and loaded its authoritative scan context. Follow the returned block\u002Fwarn\u002Fsuggest results. For an app-generated scan, ask before applying actionable remediation and wait without creating a scan goal or calling `fail_codex_security_scan`. Do not fail automatically for declined or unavailable remediation, helper errors, or a non-ready rerun; preserve the running scan and retry or hand off while recovery may still be possible. Call `fail_codex_security_scan` only after documented recovery is exhausted and the blocker is confirmed unrecoverable, or when the user explicitly cancels. Do not treat a config value that differs from a suggested patch as a warning unless the capability requirement itself is unmet.\n\n## Phase Sequence\n\nKeep these phases distinct and run them in linear order:\n\n1. `$threat-model`\n2. `$finding-discovery`\n3. `$validation`\n4. `$attack-path-analysis`\n5. Generate final output\n\nTreat this skill as the top-level orchestrator for the four skills plus the final report assembly step. Do not collapse the phases together.\n\nFor each phase:\n1. Read that phase's skill.\n2. Load only the inputs required for that phase.\n3. Complete that phase's workflow and checklist.\n4. Only then read the next phase's skill.\n\nDo not read ahead into later-phase skills until the current phase has completed.\nDo not amortize effort across phases: complete each phase to the full depth expected by that phase before moving on.\nFor repository-wide and scoped-path scans, treat explicit invocation of this exhaustive scan workflow as the user's authorization to use the subagents required by the workflow. If subagents are unavailable in the current environment, explain the limitation instead of claiming exhaustive scan coverage.\n\n## Goal Setup\n\nAfter the app wait or direct continuation has provided a `scanId`, the authoritative scan context has been loaded, and the `security_scan` capability preflight has returned `ready`, or after the same preflight is `ready` in Codex CLI or terminal\u002Fchat hosts without the setup app, create a Codex goal for the scan if the runtime exposes goal tools and no active goal already covers this scan. The objective should state that the scan must not stop until the resolved files in scope have been covered and the required coverage artifacts prove that closure.\n\nUse objective wording shaped like:\n\n`Run the Codex Security repository\u002Fscoped-path scan for \u003Cresolved target>; do not stop until every in-scope file\u002Fworklist row has a completion receipt or explicit deferred closure, every candidate has required ledger receipts, and the final report is written.`\n\nIf a compatible active goal already exists, continue under it instead of creating a duplicate. If goal tools are unavailable, state the same coverage objective in the first visible scan update and continue.\n\nDo not mark the goal complete until:\n\n- every file or worklist row in the resolved scope has a completion receipt, or an explicit `deferred`, `not_applicable`, or `suppressed` closure with exact reason\n- every candidate that reached discovery has the required discovery, validation, and attack-path ledger receipts, or an explicit deferred reason for the missing proof\n- the final markdown report has been written to the resolved scan path\n\n## Artifact Resolution\n\nThe path references in this skill are the default locations for this phase.\nIf the user explicitly provides a different path for a required input or output, use the user-provided path instead of the corresponding default path referenced in this skill.\nIf a required input is still missing, stop and ask the user for it before continuing.\nUse the shared scan artifact path conventions in `..\u002F..\u002Freferences\u002Fscan-artifacts.md`.\n\n## Execution Plan\n\nStart this plan only after `Setup Workspace Routing` has either loaded the app-generated scan context with a `scanId`, or determined that the host is using the non-app terminal\u002Fchat workflow, and the `security_scan` capability preflight has returned `ready`.\n\nFollow this plan in order. Do not skip ahead to a later phase until the current phase has produced its intended output.\n\n1. Resolve the scan target, `repo_name`, `security_scans_dir`, `scan_id`, `scan_dir`, and `artifacts_dir` using `..\u002F..\u002Freferences\u002Fscan-artifacts.md`.\n2. Create or adopt the scan goal described in `Goal Setup` for that active scan context.\n3. Read `..\u002F..\u002Freferences\u002Fsecurity-guidance.md`, compile the resolved scan target's policy to `\u003Ccontext_dir>\u002Fsecurity_guidance.md`, and read it before threat modeling or inspecting source code.\n4. Run `$threat-model` first.\n  - Copy the repository-scoped threat model to the per-scan threat model path without alteration for auditability.\n  - Treat the per-scan threat model path as the source of truth threat model for later phases.\n5. Run `$finding-discovery` as the second step, against the resolved repository or scoped path and using the per-scan threat model as context.\n  - Stop at discovery only when the ranked runtime-surface worklist exists and the coverage ledger has closed every applicable high-impact and seeded root-control row as `suppressed`, `not_applicable`, or `deferred` with exact reasons. Open, reportable, or unresolved seeded rows continue to validation even when they are not yet numbered as findings.\n6. Run `$validation` as the third step, for each candidate that came out of discovery and each open, reportable, or deferred seeded\u002Froot-control ledger row that still needs closure.\n  - Pass the resolved scan scope, discovery notes, and candidate inventory to validation. Validation should preserve or suppress the provided instances; it should not independently broaden or narrow the requested repository or scoped-path scan.\n  - Each candidate finding's candidate-ledger path from `..\u002F..\u002Freferences\u002Fscan-artifacts.md` is part of the validation input for every scan scope. Every candidate finding that came out of discovery must have a discovery receipt before validation starts and a validation receipt before the scan can proceed to final reporting.\n  - For repository-wide and scoped-path scans, the discovery worklists, work ledger, raw candidates, per-finding candidate ledgers, deduped candidates, and discovery coverage ledger from `..\u002F..\u002Freferences\u002Fscan-artifacts.md` are part of the validation input; the ledger is a coverage artifact, not just a findings tracker. Raw candidates should already include the discovering file-review subagent's or parent agent's candidate-local validation evidence and attack-path facts before dedupe, and each per-finding candidate ledger should prove that its raw candidate finding received both checks or has an explicit deferred reason. Validation should preserve checked surfaces with not_applicable, suppressed, deferred, and reportable dispositions, reconcile cross-file proof gaps, and continue the ledger's high-impact sibling checks when needed rather than narrowing to one representative finding.\n  - When multiple candidates or coverage-ledger rows need validation and subagents are available under the resolved scan authorization, divide validation across validation subagents by candidate, deduped candidate, or ledger row. Each validation subagent must receive the candidate or row, discovery evidence, artifact paths, and candidate-ledger path it owns, then write or return the validation report update and validation receipt for that assignment.\n  - As coverage-ledger rows are validated, keep the saved per-finding validation reports current enough that reportable, suppressed, not_applicable, and deferred closure rows survive interruption or later phase summarization, including exact root-control file:line and seed-anchor file:line when distinct.\n7. Run `$attack-path-analysis` as the fourth step, for findings and validation closure rows that still need reportability, attack-path, and severity analysis after validation.\n  - Each candidate finding's candidate-ledger path from `..\u002F..\u002Freferences\u002Fscan-artifacts.md` is part of the attack-path input for every scan scope. Every candidate finding that reaches attack-path analysis must have an attack-path receipt before final reporting, even when the final decision is `ignore`, suppressed, or deferred.\n  - When multiple validated candidates or validation closure rows need attack-path analysis and subagents are available under the resolved scan authorization, divide attack-path work across attack-path subagents by candidate or row. Each attack-path subagent must receive the validation evidence, affected root-control and sink lines, artifact paths, and candidate-ledger path it owns, then write or return attack-path facts, severity\u002Fpolicy analysis, and the attack-path receipt for that assignment.\n8. Assemble the complete canonical JSON contract last using `..\u002F..\u002Freferences\u002Ffinal-report.md`; do not author `report.md`.\n  - Populate the optional structured details in `..\u002F..\u002Freferences\u002Ffinding-detail-fields.md` from the same validated evidence used in the generated report.\n  - For every reportable finding, run `$vulnerability-writeup` with exactly one dedicated write-up sub-agent. Give it only that finding, its validation and attack-path evidence, relevant source paths and revision, PoC inputs, and the target output directory.\n  - Write the derived report to `findings\u002F\u003Cslug>\u002F\u003Cslug>.md` with supporting PoC files under `findings\u002F\u003Cslug>\u002Fpoc\u002F`. Verify the report is a regular file, then set that finding's `writeup.reportPath` to the matching safe relative path. Do not add the derived report to the sealed artifact list.\n  - After every write-up is ready, run `$propose-security-hardening` once over the complete finding collection, detailed write-ups, threat model, coverage, and relevant source. Write its portfolio to `hardening\u002Fhardening.md`, its structured analysis to `hardening\u002Fhardening.json`, and any proposals and diagrams below `hardening\u002F`. Verify `hardening\u002Fhardening.md` is a regular file, then set `scan.hardening.portfolioPath` to the fixed relative path `hardening\u002Fhardening.md`. Do not add these derived files to the sealed artifact list. Skip this step and omit `scan.hardening` when there are no reportable findings.\n  - Complete the scan once, after all write-ups, hardening guidance, and canonical JSON are ready, so finalization projects the validated JSON and derived-document links into `report.md`. In the terminal\u002Fchat workflow without `complete_codex_security_scan`, run `python \u003Cplugin_dir>\u002Fscripts\u002Ffinalize_scan_contract.py --scan-dir \u003Cscan_dir> --source-root \u003Crepo_root>` directly.\n\n## Scan Scope\n\n- Phase 1 (threat model generation) is repository-scope by default, unless the user explicitly asks for narrower scope or provides an authoritative threat model or sufficiently repository-specific security scan guidance such as `AGENTS.md`.\n- Phase 2 onward (finding discovery, validation, attack path analysis) remain within the resolved repository or scoped path. For repository-wide scans, the entire checked-out repository is in scope. For scoped-path scans, the requested path, package, folder, or submodule-like boundary is in scope together with directly supporting files needed to understand concrete findings.\n- Before the `$finding-discovery` phase, read `references\u002Frepository-wide-scan.md` and every required reference it lists, then use them for finding discovery, validation, and attack path analysis.\n\n## Scan Target\n\nResolve the requested audit scope before starting:\n\n- repository-wide: scan the entire checked-out repository\n- scoped path: scan the user-specified path, package, folder, or submodule-like boundary inside the checked-out repository\n\nTreat the resolved repository or scoped path as the in-scope codebase for the later phases of this workflow.\n\n## Scoped Exhaustive Mode\n\nFor repository-wide and scoped-path scans, follow `references\u002Frepository-wide-scan.md` and every required reference it lists.\n\nTreat explicit invocation of this repository-wide or scoped-path exhaustive scan workflow as the user's authorization to use the subagents required by the workflow. If subagents are unavailable, do not claim exhaustive coverage; explain the limitation and offer the narrower parent-agent-only path only if it can still satisfy the requested scope honestly.\n\nUse the per-scan artifact directory layout from `..\u002F..\u002Freferences\u002Fscan-artifacts.md`.\n\n## Final Output\n\nPopulate all final report semantics in the canonical manifest, findings, and coverage JSON using `..\u002F..\u002Freferences\u002Ffinal-report.md`. Generate one detailed `vulnerability-writeup` for every reportable finding, then run `propose-security-hardening` once over the complete collection and record the safe derived-document paths. Complete the scan once after both stages; finalization owns `report.md` generation. Emit Codex app review directives from the completed canonical findings.\n\n## Hard Rules\n\nRead `..\u002F..\u002Freferences\u002Fshared-hard-rules.md` before applying scan-mode-specific hard rules.\n\n- After any app setup handoff has provided a `scanId`, or in the non-app terminal\u002Fchat workflow, create or adopt the scan goal only after the capability preflight has returned `ready`, and before substantive scan work. Do not complete it until the resolved in-scope files\u002Fworklist rows, candidate ledgers, and final reports meet the `Goal Setup` closure criteria.\n- For repository-wide and scoped-path scans, do not equate broad sink counts with completed coverage. The coverage ledger must close each applicable high-impact shard row as `reportable`, `suppressed`, `not_applicable`, or `deferred`.\n- For every scan scope, candidate-finding coverage is required. Do not finalize a candidate finding until its candidate-ledger path from `..\u002F..\u002Freferences\u002Fscan-artifacts.md` shows discovery, validation, and attack-path receipts for that exact candidate, or an explicit deferred reason for the missing proof.\n- For repository-wide and scoped-path scans, subagent dispatch must have explicit ownership: each of no more than six ranking subagents owns one static `rank_worker_assignments.json` pool slot containing one or more generated `rank_shards\u002F*.input.jsonl` shards of at most 150 rows, processes its ordered list sequentially, and writes only the matching worker-local `.output.jsonl` files; file-review subagents own one assessed file or tiny shard and return full-file receipts plus pre-dedupe finding objects with candidate-local validation evidence and attack-path facts; validation subagents own one candidate or ledger row that needs validation closure; attack-path subagents own one validated candidate or validation closure row; the parent agent owns bounded worker orchestration, ledger reconciliation, aggregation, cross-file dedupe, and final closure.\n- For repository-wide and scoped-path scans, candidate-finding coverage is separate from file coverage. Do not dedupe or finalize a raw candidate finding until its candidate-ledger path from `..\u002F..\u002Freferences\u002Fscan-artifacts.md` shows candidate-local validation and candidate-local attack-path receipts, or an explicit deferred reason for missing proof.\n- Candidate ids are optional links from coverage rows to findings; a not_applicable, suppressed, or deferred row is still required when the surface was in scope.\n- For repository-wide and scoped-path scans, the ranked runtime-surface worklist must exist before discovery is considered complete, and the coverage ledger must be materially broader than the promoted candidate list.\n- For repository-wide and scoped-path scans with CVE, GHSA, advisory, issue, release, or package-version identifiers, `seed_research.md` must exist before discovery is considered complete. It should record authoritative sources searched, candidate files\u002Ffunctions\u002Fclasses\u002Fhunks, and failed lookup attempts. Missing seed research means advisory-led discovery is incomplete unless the scan explicitly states that no network\u002Flocal-history source was available.\n- In large repository-wide scans, checkpoint the ranked runtime-surface worklist and initial coverage ledger to disk before deep sink review or validation. A run that is interrupted after frontier mapping should still leave auditable coverage artifacts.\n- In large monorepos, top product\u002Fruntime areas by file count or deployment significance must appear as ledger shards or be explicitly excluded with repository evidence; global sink counts and `no top candidate surfaced` do not close coverage.\n- User\u002Fadvisory\u002Ftag-seeded packages, class families, or vulnerability families remain open until the exact seeded row is closed as `reportable`, `suppressed`, `not_applicable`, or `deferred`. A neighboring same-family finding does not close the seeded row.\n- For large repository-wide scans, make one reachability pass across every applicable high-impact shard before prolonged validation of any single shard. A row becomes a validation candidate only when it has a concrete entrypoint or privileged boundary, closest relevant control, sink or broken control, and plausible impact.\n- Discovery is incomplete when a shard has a promoted finding but still has unclosed sibling packages, concrete implementations, or reusable root-control rows that could be independently vulnerable. Finish those rows or mark them explicitly deferred before final reporting.\n- Final assembly must start from reportable validation closure rows and surviving candidates. Do not drop a reportable seeded\u002Froot-control row because attack-path analysis or discovery spent more prose on a neighboring same-family finding.\n- Final reporting is incomplete when a promoted high-impact finding's affected lines omit the concrete root-control file\u002Fline discovered or seeded during discovery, such as a codec, converter, parser feature setup, class filter, resource-path control, protocol state transition, or self-service update guard. Add the root-control affected line or explicitly suppress\u002Fdefer it with exact counterevidence before finalizing.\n- In repository-wide and scoped-path scans, preserve independently reachable sibling instances through final reporting. Repeated vulnerable templates, query builders, parser operations, auth\u002Fobject endpoints, or shared-helper callers need separate finding entries, affected lines, and dispositions; put grouping in summary prose only after the individual instances are emitted.\n- For query\u002Fparser injection, do not suppress syntax-control evidence solely because a later business check appears to limit impact. Carry the injection candidate until validation proves the exact query API and post-query guard defeat semantic change for that instance.\n- If large-repository scope forces deferral, make the final report explicit about which deployed or privileged areas and vulnerability families remain deferred.\n",{"data":37,"body":38},{"name":4,"description":6},{"type":39,"children":40},"root",[41,49,55,62,76,103,160,165,396,448,454,494,500,505,549,554,559,582,587,593,626,631,640,645,650,692,698,710,716,747,752,846,859,874,901,916,958,973,1000,1024,1177,1183,1223,1229,1234,1247,1252,1258,1270,1275,1286,1292,1327,1333,1345],{"type":42,"tag":43,"props":44,"children":45},"element","h1",{"id":4},[46],{"type":47,"value":48},"text","Security Scan",{"type":42,"tag":50,"props":51,"children":52},"p",{},[53],{"type":47,"value":54},"Used when a user wants to audit an entire repository or a user-specified path, package, folder, or submodule-like scope for security vulnerabilities. Keep the scan phases separate and produce the final markdown report.",{"type":42,"tag":56,"props":57,"children":59},"h2",{"id":58},"setup-workspace-routing",[60],{"type":47,"value":61},"Setup Workspace Routing",{"type":42,"tag":50,"props":63,"children":64},{},[65,67,74],{"type":47,"value":66},"When this skill is the active top-level workflow, use the setup workspace only when the host context explicitly says it is running inside the Codex desktop app and both required setup continuation tools are available. Tool availability alone does not identify the app host. Otherwise, including Codex CLI interactive and headless runs, use the prompt-only terminal\u002Fchat workflow: do not call Codex Security app setup tools, ask the user to press Start scan, or wait for an app-generated ",{"type":42,"tag":68,"props":69,"children":71},"code",{"className":70},[],[72],{"type":47,"value":73},"scanId",{"type":47,"value":75},".",{"type":42,"tag":50,"props":77,"children":78},{},[79,81,87,89,94,96,102],{"type":47,"value":80},"Treat goal creation as scan execution, not setup. In the app setup path, do not create or adopt scan goals before the user presses Start scan, the authoritative scan context has been loaded from a ",{"type":42,"tag":68,"props":82,"children":84},{"className":83},[],[85],{"type":47,"value":86},"status: \"started\"",{"type":47,"value":88}," wait result or a direct continuation with a ",{"type":42,"tag":68,"props":90,"children":92},{"className":91},[],[93],{"type":47,"value":73},{"type":47,"value":95},", and the capability preflight has returned ",{"type":42,"tag":68,"props":97,"children":99},{"className":98},[],[100],{"type":47,"value":101},"ready",{"type":47,"value":75},{"type":42,"tag":50,"props":104,"children":105},{},[106,108,113,115,121,123,129,131,136,138,143,145,151,153,159],{"type":47,"value":107},"For an app continuation that already includes a ",{"type":42,"tag":68,"props":109,"children":111},{"className":110},[],[112],{"type":47,"value":73},{"type":47,"value":114}," and optional ",{"type":42,"tag":68,"props":116,"children":118},{"className":117},[],[119],{"type":47,"value":120},"handoffClaimToken",{"type":47,"value":122},", do not open another workspace: call ",{"type":42,"tag":68,"props":124,"children":126},{"className":125},[],[127],{"type":47,"value":128},"get_codex_security_scan_context",{"type":47,"value":130}," with the ",{"type":42,"tag":68,"props":132,"children":134},{"className":133},[],[135],{"type":47,"value":73},{"type":47,"value":137},", pass its ",{"type":42,"tag":68,"props":139,"children":141},{"className":140},[],[142],{"type":47,"value":120},{"type":47,"value":144}," when present, route elsewhere only if its validated mode differs, and use its target, scope, optional ",{"type":42,"tag":68,"props":146,"children":148},{"className":147},[],[149],{"type":47,"value":150},"userContext",{"type":47,"value":152},", and ",{"type":42,"tag":68,"props":154,"children":156},{"className":155},[],[157],{"type":47,"value":158},"scanDir",{"type":47,"value":75},{"type":42,"tag":50,"props":161,"children":162},{},[163],{"type":47,"value":164},"Otherwise, in a host that renders MCP Apps and exposes the Codex Security setup continuation tools:",{"type":42,"tag":166,"props":167,"children":168},"ol",{},[169,213,218,231,265,321,333,353],{"type":42,"tag":170,"props":171,"children":172},"li",{},[173,175,181,183,189,191,197,199,205,207,212],{"type":47,"value":174},"Resolve setup arguments directly from the user's initial prompt and known thread context: local ",{"type":42,"tag":68,"props":176,"children":178},{"className":177},[],[179],{"type":47,"value":180},"targetPath",{"type":47,"value":182},", ",{"type":42,"tag":68,"props":184,"children":186},{"className":185},[],[187],{"type":47,"value":188},"mode: \"standard\"",{"type":47,"value":190},", target-relative ",{"type":42,"tag":68,"props":192,"children":194},{"className":193},[],[195],{"type":47,"value":196},"scope",{"type":47,"value":198}," (",{"type":42,"tag":68,"props":200,"children":202},{"className":201},[],[203],{"type":47,"value":204},"\".\"",{"type":47,"value":206}," for the whole target), and only user-supplied security focus as ",{"type":42,"tag":68,"props":208,"children":210},{"className":209},[],[211],{"type":47,"value":150},{"type":47,"value":75},{"type":42,"tag":170,"props":214,"children":215},{},[216],{"type":47,"value":217},"Perform only the minimal path resolution needed to construct those arguments. Do not run capability preflight, inspect the repository, threat model, discover findings, or create workers before setup opens.",{"type":42,"tag":170,"props":219,"children":220},{},[221,223,229],{"type":47,"value":222},"Immediately call ",{"type":42,"tag":68,"props":224,"children":226},{"className":225},[],[227],{"type":47,"value":228},"open_codex_security_workspace",{"type":47,"value":230}," with the resolved arguments. Do not search for or substitute a separate scan command.",{"type":42,"tag":170,"props":232,"children":233},{},[234,235,241,242,248,250,255,257,263],{"type":47,"value":222},{"type":42,"tag":68,"props":236,"children":238},{"className":237},[],[239],{"type":47,"value":240},"await_codex_security_scan_start",{"type":47,"value":130},{"type":42,"tag":68,"props":243,"children":245},{"className":244},[],[246],{"type":47,"value":247},"sessionId",{"type":47,"value":249}," from the workspace returned by ",{"type":42,"tag":68,"props":251,"children":253},{"className":252},[],[254],{"type":47,"value":228},{"type":47,"value":256},". A returned workspace with ",{"type":42,"tag":68,"props":258,"children":260},{"className":259},[],[261],{"type":47,"value":262},"setup.submitted=false",{"type":47,"value":264}," is the expected wait state. Keep the tool call pending while waiting for the user to review setup and press Start scan; do not create or adopt a scan goal, run preflight, or pivot to terminal\u002Fchat fallback while waiting.",{"type":42,"tag":170,"props":266,"children":267},{},[268,270,275,277,282,284,289,291,296,298,303,305,311,313,319],{"type":47,"value":269},"If the wait returns ",{"type":42,"tag":68,"props":271,"children":273},{"className":272},[],[274],{"type":47,"value":86},{"type":47,"value":276},", require its ",{"type":42,"tag":68,"props":278,"children":280},{"className":279},[],[281],{"type":47,"value":73},{"type":47,"value":283},", call ",{"type":42,"tag":68,"props":285,"children":287},{"className":286},[],[288],{"type":47,"value":128},{"type":47,"value":290}," with that ",{"type":42,"tag":68,"props":292,"children":294},{"className":293},[],[295],{"type":47,"value":73},{"type":47,"value":297},", and pass its ",{"type":42,"tag":68,"props":299,"children":301},{"className":300},[],[302],{"type":47,"value":120},{"type":47,"value":304}," when present. Then run the preflight in ",{"type":42,"tag":68,"props":306,"children":308},{"className":307},[],[309],{"type":47,"value":310},"..\u002F..\u002Freferences\u002Fconfig-preflight.md",{"type":47,"value":312}," for the selected target and ",{"type":42,"tag":68,"props":314,"children":316},{"className":315},[],[317],{"type":47,"value":318},"security_scan",{"type":47,"value":320}," profile before goal setup, threat modeling, or other substantive scan work.",{"type":42,"tag":170,"props":322,"children":323},{},[324,325,331],{"type":47,"value":269},{"type":42,"tag":68,"props":326,"children":328},{"className":327},[],[329],{"type":47,"value":330},"status: \"already_delivered\"",{"type":47,"value":332},", end the current turn without loading scan context or starting scan work. Another continuation already owns the scan.",{"type":42,"tag":170,"props":334,"children":335},{},[336,337,343,345,351],{"type":47,"value":269},{"type":42,"tag":68,"props":338,"children":340},{"className":339},[],[341],{"type":47,"value":342},"status: \"timed_out\"",{"type":47,"value":344},", end the current turn and tell the user to finish setup and use ",{"type":42,"tag":346,"props":347,"children":348},"strong",{},[349],{"type":47,"value":350},"Continue in Codex",{"type":47,"value":352}," after pressing Start scan. Do not run preflight, create or adopt a scan goal, open another workspace, or pivot to terminal\u002Fchat fallback.",{"type":42,"tag":170,"props":354,"children":355},{},[356,358,363,365,371,373,379,381,387,389,394],{"type":47,"value":357},"Continue after a ",{"type":42,"tag":68,"props":359,"children":361},{"className":360},[],[362],{"type":47,"value":101},{"type":47,"value":364}," result, explaining material warn or suggest limitations. If preflight is ",{"type":42,"tag":68,"props":366,"children":368},{"className":367},[],[369],{"type":47,"value":370},"blocked",{"type":47,"value":372}," or ",{"type":42,"tag":68,"props":374,"children":376},{"className":375},[],[377],{"type":47,"value":378},"incomplete",{"type":47,"value":380}," with actionable remediation, present the exact reasons and config delta, ask whether to apply the remediation, and stop for the user's answer before creating or adopting a scan goal or calling ",{"type":42,"tag":68,"props":382,"children":384},{"className":383},[],[385],{"type":47,"value":386},"fail_codex_security_scan",{"type":47,"value":388},". Do not fail automatically for declined or unavailable remediation, helper errors, or a non-ready rerun. Preserve the running scan and retry or hand off while recovery may still be possible. If the user declines required remediation, ask whether to cancel or leave the scan running for a later retry. Call ",{"type":42,"tag":68,"props":390,"children":392},{"className":391},[],[393],{"type":47,"value":386},{"type":47,"value":395}," with the exact reason only after documented recovery is exhausted and the blocker is confirmed unrecoverable, or when the user explicitly cancels.",{"type":42,"tag":50,"props":397,"children":398},{},[399,401,406,407,412,414,419,421,426,428,433,435,439,441,446],{"type":47,"value":400},"In Codex CLI, including interactive and headless runs, or hosts without those capabilities, use the existing prompt-only terminal\u002Fchat preflight and scan workflow and shared artifact paths. Do not call ",{"type":42,"tag":68,"props":402,"children":404},{"className":403},[],[405],{"type":47,"value":228},{"type":47,"value":372},{"type":42,"tag":68,"props":408,"children":410},{"className":409},[],[411],{"type":47,"value":240},{"type":47,"value":413}," on this path. Once ",{"type":42,"tag":68,"props":415,"children":417},{"className":416},[],[418],{"type":47,"value":228},{"type":47,"value":420}," succeeds in an MCP Apps-capable host, remain on the app path: immediately call ",{"type":42,"tag":68,"props":422,"children":424},{"className":423},[],[425],{"type":47,"value":240},{"type":47,"value":427},"; a ",{"type":42,"tag":68,"props":429,"children":431},{"className":430},[],[432],{"type":47,"value":342},{"type":47,"value":434}," result means end the turn and point the user to ",{"type":42,"tag":346,"props":436,"children":437},{},[438],{"type":47,"value":350},{"type":47,"value":440},", while ",{"type":42,"tag":68,"props":442,"children":444},{"className":443},[],[445],{"type":47,"value":330},{"type":47,"value":447}," means stop because another continuation owns the scan. Do not start a terminal\u002Fchat fallback for either result.",{"type":42,"tag":56,"props":449,"children":451},{"id":450},"capability-preflight",[452],{"type":47,"value":453},"Capability Preflight",{"type":42,"tag":50,"props":455,"children":456},{},[457,459,464,466,471,473,478,480,485,487,492],{"type":47,"value":458},"Read ",{"type":42,"tag":68,"props":460,"children":462},{"className":461},[],[463],{"type":47,"value":310},{"type":47,"value":465}," and dispatch and await the preflight execution described there with the ",{"type":42,"tag":68,"props":467,"children":469},{"className":468},[],[470],{"type":47,"value":318},{"type":47,"value":472}," capability profile before substantive scan work, including after an app wait or direct continuation has produced a ",{"type":42,"tag":68,"props":474,"children":476},{"className":475},[],[477],{"type":47,"value":73},{"type":47,"value":479}," and loaded its authoritative scan context. Follow the returned block\u002Fwarn\u002Fsuggest results. For an app-generated scan, ask before applying actionable remediation and wait without creating a scan goal or calling ",{"type":42,"tag":68,"props":481,"children":483},{"className":482},[],[484],{"type":47,"value":386},{"type":47,"value":486},". Do not fail automatically for declined or unavailable remediation, helper errors, or a non-ready rerun; preserve the running scan and retry or hand off while recovery may still be possible. Call ",{"type":42,"tag":68,"props":488,"children":490},{"className":489},[],[491],{"type":47,"value":386},{"type":47,"value":493}," only after documented recovery is exhausted and the blocker is confirmed unrecoverable, or when the user explicitly cancels. Do not treat a config value that differs from a suggested patch as a warning unless the capability requirement itself is unmet.",{"type":42,"tag":56,"props":495,"children":497},{"id":496},"phase-sequence",[498],{"type":47,"value":499},"Phase Sequence",{"type":42,"tag":50,"props":501,"children":502},{},[503],{"type":47,"value":504},"Keep these phases distinct and run them in linear order:",{"type":42,"tag":166,"props":506,"children":507},{},[508,517,526,535,544],{"type":42,"tag":170,"props":509,"children":510},{},[511],{"type":42,"tag":68,"props":512,"children":514},{"className":513},[],[515],{"type":47,"value":516},"$threat-model",{"type":42,"tag":170,"props":518,"children":519},{},[520],{"type":42,"tag":68,"props":521,"children":523},{"className":522},[],[524],{"type":47,"value":525},"$finding-discovery",{"type":42,"tag":170,"props":527,"children":528},{},[529],{"type":42,"tag":68,"props":530,"children":532},{"className":531},[],[533],{"type":47,"value":534},"$validation",{"type":42,"tag":170,"props":536,"children":537},{},[538],{"type":42,"tag":68,"props":539,"children":541},{"className":540},[],[542],{"type":47,"value":543},"$attack-path-analysis",{"type":42,"tag":170,"props":545,"children":546},{},[547],{"type":47,"value":548},"Generate final output",{"type":42,"tag":50,"props":550,"children":551},{},[552],{"type":47,"value":553},"Treat this skill as the top-level orchestrator for the four skills plus the final report assembly step. Do not collapse the phases together.",{"type":42,"tag":50,"props":555,"children":556},{},[557],{"type":47,"value":558},"For each phase:",{"type":42,"tag":166,"props":560,"children":561},{},[562,567,572,577],{"type":42,"tag":170,"props":563,"children":564},{},[565],{"type":47,"value":566},"Read that phase's skill.",{"type":42,"tag":170,"props":568,"children":569},{},[570],{"type":47,"value":571},"Load only the inputs required for that phase.",{"type":42,"tag":170,"props":573,"children":574},{},[575],{"type":47,"value":576},"Complete that phase's workflow and checklist.",{"type":42,"tag":170,"props":578,"children":579},{},[580],{"type":47,"value":581},"Only then read the next phase's skill.",{"type":42,"tag":50,"props":583,"children":584},{},[585],{"type":47,"value":586},"Do not read ahead into later-phase skills until the current phase has completed.\nDo not amortize effort across phases: complete each phase to the full depth expected by that phase before moving on.\nFor repository-wide and scoped-path scans, treat explicit invocation of this exhaustive scan workflow as the user's authorization to use the subagents required by the workflow. If subagents are unavailable in the current environment, explain the limitation instead of claiming exhaustive scan coverage.",{"type":42,"tag":56,"props":588,"children":590},{"id":589},"goal-setup",[591],{"type":47,"value":592},"Goal Setup",{"type":42,"tag":50,"props":594,"children":595},{},[596,598,603,605,610,612,617,619,624],{"type":47,"value":597},"After the app wait or direct continuation has provided a ",{"type":42,"tag":68,"props":599,"children":601},{"className":600},[],[602],{"type":47,"value":73},{"type":47,"value":604},", the authoritative scan context has been loaded, and the ",{"type":42,"tag":68,"props":606,"children":608},{"className":607},[],[609],{"type":47,"value":318},{"type":47,"value":611}," capability preflight has returned ",{"type":42,"tag":68,"props":613,"children":615},{"className":614},[],[616],{"type":47,"value":101},{"type":47,"value":618},", or after the same preflight is ",{"type":42,"tag":68,"props":620,"children":622},{"className":621},[],[623],{"type":47,"value":101},{"type":47,"value":625}," in Codex CLI or terminal\u002Fchat hosts without the setup app, create a Codex goal for the scan if the runtime exposes goal tools and no active goal already covers this scan. The objective should state that the scan must not stop until the resolved files in scope have been covered and the required coverage artifacts prove that closure.",{"type":42,"tag":50,"props":627,"children":628},{},[629],{"type":47,"value":630},"Use objective wording shaped like:",{"type":42,"tag":50,"props":632,"children":633},{},[634],{"type":42,"tag":68,"props":635,"children":637},{"className":636},[],[638],{"type":47,"value":639},"Run the Codex Security repository\u002Fscoped-path scan for \u003Cresolved target>; do not stop until every in-scope file\u002Fworklist row has a completion receipt or explicit deferred closure, every candidate has required ledger receipts, and the final report is written.",{"type":42,"tag":50,"props":641,"children":642},{},[643],{"type":47,"value":644},"If a compatible active goal already exists, continue under it instead of creating a duplicate. If goal tools are unavailable, state the same coverage objective in the first visible scan update and continue.",{"type":42,"tag":50,"props":646,"children":647},{},[648],{"type":47,"value":649},"Do not mark the goal complete until:",{"type":42,"tag":651,"props":652,"children":653},"ul",{},[654,682,687],{"type":42,"tag":170,"props":655,"children":656},{},[657,659,665,666,672,674,680],{"type":47,"value":658},"every file or worklist row in the resolved scope has a completion receipt, or an explicit ",{"type":42,"tag":68,"props":660,"children":662},{"className":661},[],[663],{"type":47,"value":664},"deferred",{"type":47,"value":182},{"type":42,"tag":68,"props":667,"children":669},{"className":668},[],[670],{"type":47,"value":671},"not_applicable",{"type":47,"value":673},", or ",{"type":42,"tag":68,"props":675,"children":677},{"className":676},[],[678],{"type":47,"value":679},"suppressed",{"type":47,"value":681}," closure with exact reason",{"type":42,"tag":170,"props":683,"children":684},{},[685],{"type":47,"value":686},"every candidate that reached discovery has the required discovery, validation, and attack-path ledger receipts, or an explicit deferred reason for the missing proof",{"type":42,"tag":170,"props":688,"children":689},{},[690],{"type":47,"value":691},"the final markdown report has been written to the resolved scan path",{"type":42,"tag":56,"props":693,"children":695},{"id":694},"artifact-resolution",[696],{"type":47,"value":697},"Artifact Resolution",{"type":42,"tag":50,"props":699,"children":700},{},[701,703,709],{"type":47,"value":702},"The path references in this skill are the default locations for this phase.\nIf the user explicitly provides a different path for a required input or output, use the user-provided path instead of the corresponding default path referenced in this skill.\nIf a required input is still missing, stop and ask the user for it before continuing.\nUse the shared scan artifact path conventions in ",{"type":42,"tag":68,"props":704,"children":706},{"className":705},[],[707],{"type":47,"value":708},"..\u002F..\u002Freferences\u002Fscan-artifacts.md",{"type":47,"value":75},{"type":42,"tag":56,"props":711,"children":713},{"id":712},"execution-plan",[714],{"type":47,"value":715},"Execution Plan",{"type":42,"tag":50,"props":717,"children":718},{},[719,721,726,728,733,735,740,741,746],{"type":47,"value":720},"Start this plan only after ",{"type":42,"tag":68,"props":722,"children":724},{"className":723},[],[725],{"type":47,"value":61},{"type":47,"value":727}," has either loaded the app-generated scan context with a ",{"type":42,"tag":68,"props":729,"children":731},{"className":730},[],[732],{"type":47,"value":73},{"type":47,"value":734},", or determined that the host is using the non-app terminal\u002Fchat workflow, and the ",{"type":42,"tag":68,"props":736,"children":738},{"className":737},[],[739],{"type":47,"value":318},{"type":47,"value":611},{"type":42,"tag":68,"props":742,"children":744},{"className":743},[],[745],{"type":47,"value":101},{"type":47,"value":75},{"type":42,"tag":50,"props":748,"children":749},{},[750],{"type":47,"value":751},"Follow this plan in order. Do not skip ahead to a later phase until the current phase has produced its intended output.",{"type":42,"tag":166,"props":753,"children":754},{},[755,802,814,834],{"type":42,"tag":170,"props":756,"children":757},{},[758,760,766,767,773,774,780,781,787,788,794,796,801],{"type":47,"value":759},"Resolve the scan target, ",{"type":42,"tag":68,"props":761,"children":763},{"className":762},[],[764],{"type":47,"value":765},"repo_name",{"type":47,"value":182},{"type":42,"tag":68,"props":768,"children":770},{"className":769},[],[771],{"type":47,"value":772},"security_scans_dir",{"type":47,"value":182},{"type":42,"tag":68,"props":775,"children":777},{"className":776},[],[778],{"type":47,"value":779},"scan_id",{"type":47,"value":182},{"type":42,"tag":68,"props":782,"children":784},{"className":783},[],[785],{"type":47,"value":786},"scan_dir",{"type":47,"value":152},{"type":42,"tag":68,"props":789,"children":791},{"className":790},[],[792],{"type":47,"value":793},"artifacts_dir",{"type":47,"value":795}," using ",{"type":42,"tag":68,"props":797,"children":799},{"className":798},[],[800],{"type":47,"value":708},{"type":47,"value":75},{"type":42,"tag":170,"props":803,"children":804},{},[805,807,812],{"type":47,"value":806},"Create or adopt the scan goal described in ",{"type":42,"tag":68,"props":808,"children":810},{"className":809},[],[811],{"type":47,"value":592},{"type":47,"value":813}," for that active scan context.",{"type":42,"tag":170,"props":815,"children":816},{},[817,818,824,826,832],{"type":47,"value":458},{"type":42,"tag":68,"props":819,"children":821},{"className":820},[],[822],{"type":47,"value":823},"..\u002F..\u002Freferences\u002Fsecurity-guidance.md",{"type":47,"value":825},", compile the resolved scan target's policy to ",{"type":42,"tag":68,"props":827,"children":829},{"className":828},[],[830],{"type":47,"value":831},"\u003Ccontext_dir>\u002Fsecurity_guidance.md",{"type":47,"value":833},", and read it before threat modeling or inspecting source code.",{"type":42,"tag":170,"props":835,"children":836},{},[837,839,844],{"type":47,"value":838},"Run ",{"type":42,"tag":68,"props":840,"children":842},{"className":841},[],[843],{"type":47,"value":516},{"type":47,"value":845}," first.",{"type":42,"tag":651,"props":847,"children":848},{},[849,854],{"type":42,"tag":170,"props":850,"children":851},{},[852],{"type":47,"value":853},"Copy the repository-scoped threat model to the per-scan threat model path without alteration for auditability.",{"type":42,"tag":170,"props":855,"children":856},{},[857],{"type":47,"value":858},"Treat the per-scan threat model path as the source of truth threat model for later phases.",{"type":42,"tag":166,"props":860,"children":862},{"start":861},5,[863],{"type":42,"tag":170,"props":864,"children":865},{},[866,867,872],{"type":47,"value":838},{"type":42,"tag":68,"props":868,"children":870},{"className":869},[],[871],{"type":47,"value":525},{"type":47,"value":873}," as the second step, against the resolved repository or scoped path and using the per-scan threat model as context.",{"type":42,"tag":651,"props":875,"children":876},{},[877],{"type":42,"tag":170,"props":878,"children":879},{},[880,882,887,888,893,894,899],{"type":47,"value":881},"Stop at discovery only when the ranked runtime-surface worklist exists and the coverage ledger has closed every applicable high-impact and seeded root-control row as ",{"type":42,"tag":68,"props":883,"children":885},{"className":884},[],[886],{"type":47,"value":679},{"type":47,"value":182},{"type":42,"tag":68,"props":889,"children":891},{"className":890},[],[892],{"type":47,"value":671},{"type":47,"value":673},{"type":42,"tag":68,"props":895,"children":897},{"className":896},[],[898],{"type":47,"value":664},{"type":47,"value":900}," with exact reasons. Open, reportable, or unresolved seeded rows continue to validation even when they are not yet numbered as findings.",{"type":42,"tag":166,"props":902,"children":904},{"start":903},6,[905],{"type":42,"tag":170,"props":906,"children":907},{},[908,909,914],{"type":47,"value":838},{"type":42,"tag":68,"props":910,"children":912},{"className":911},[],[913],{"type":47,"value":534},{"type":47,"value":915}," as the third step, for each candidate that came out of discovery and each open, reportable, or deferred seeded\u002Froot-control ledger row that still needs closure.",{"type":42,"tag":651,"props":917,"children":918},{},[919,924,936,948,953],{"type":42,"tag":170,"props":920,"children":921},{},[922],{"type":47,"value":923},"Pass the resolved scan scope, discovery notes, and candidate inventory to validation. Validation should preserve or suppress the provided instances; it should not independently broaden or narrow the requested repository or scoped-path scan.",{"type":42,"tag":170,"props":925,"children":926},{},[927,929,934],{"type":47,"value":928},"Each candidate finding's candidate-ledger path from ",{"type":42,"tag":68,"props":930,"children":932},{"className":931},[],[933],{"type":47,"value":708},{"type":47,"value":935}," is part of the validation input for every scan scope. Every candidate finding that came out of discovery must have a discovery receipt before validation starts and a validation receipt before the scan can proceed to final reporting.",{"type":42,"tag":170,"props":937,"children":938},{},[939,941,946],{"type":47,"value":940},"For repository-wide and scoped-path scans, the discovery worklists, work ledger, raw candidates, per-finding candidate ledgers, deduped candidates, and discovery coverage ledger from ",{"type":42,"tag":68,"props":942,"children":944},{"className":943},[],[945],{"type":47,"value":708},{"type":47,"value":947}," are part of the validation input; the ledger is a coverage artifact, not just a findings tracker. Raw candidates should already include the discovering file-review subagent's or parent agent's candidate-local validation evidence and attack-path facts before dedupe, and each per-finding candidate ledger should prove that its raw candidate finding received both checks or has an explicit deferred reason. Validation should preserve checked surfaces with not_applicable, suppressed, deferred, and reportable dispositions, reconcile cross-file proof gaps, and continue the ledger's high-impact sibling checks when needed rather than narrowing to one representative finding.",{"type":42,"tag":170,"props":949,"children":950},{},[951],{"type":47,"value":952},"When multiple candidates or coverage-ledger rows need validation and subagents are available under the resolved scan authorization, divide validation across validation subagents by candidate, deduped candidate, or ledger row. Each validation subagent must receive the candidate or row, discovery evidence, artifact paths, and candidate-ledger path it owns, then write or return the validation report update and validation receipt for that assignment.",{"type":42,"tag":170,"props":954,"children":955},{},[956],{"type":47,"value":957},"As coverage-ledger rows are validated, keep the saved per-finding validation reports current enough that reportable, suppressed, not_applicable, and deferred closure rows survive interruption or later phase summarization, including exact root-control file:line and seed-anchor file:line when distinct.",{"type":42,"tag":166,"props":959,"children":961},{"start":960},7,[962],{"type":42,"tag":170,"props":963,"children":964},{},[965,966,971],{"type":47,"value":838},{"type":42,"tag":68,"props":967,"children":969},{"className":968},[],[970],{"type":47,"value":543},{"type":47,"value":972}," as the fourth step, for findings and validation closure rows that still need reportability, attack-path, and severity analysis after validation.",{"type":42,"tag":651,"props":974,"children":975},{},[976,995],{"type":42,"tag":170,"props":977,"children":978},{},[979,980,985,987,993],{"type":47,"value":928},{"type":42,"tag":68,"props":981,"children":983},{"className":982},[],[984],{"type":47,"value":708},{"type":47,"value":986}," is part of the attack-path input for every scan scope. Every candidate finding that reaches attack-path analysis must have an attack-path receipt before final reporting, even when the final decision is ",{"type":42,"tag":68,"props":988,"children":990},{"className":989},[],[991],{"type":47,"value":992},"ignore",{"type":47,"value":994},", suppressed, or deferred.",{"type":42,"tag":170,"props":996,"children":997},{},[998],{"type":47,"value":999},"When multiple validated candidates or validation closure rows need attack-path analysis and subagents are available under the resolved scan authorization, divide attack-path work across attack-path subagents by candidate or row. Each attack-path subagent must receive the validation evidence, affected root-control and sink lines, artifact paths, and candidate-ledger path it owns, then write or return attack-path facts, severity\u002Fpolicy analysis, and the attack-path receipt for that assignment.",{"type":42,"tag":166,"props":1001,"children":1003},{"start":1002},8,[1004],{"type":42,"tag":170,"props":1005,"children":1006},{},[1007,1009,1015,1017,1023],{"type":47,"value":1008},"Assemble the complete canonical JSON contract last using ",{"type":42,"tag":68,"props":1010,"children":1012},{"className":1011},[],[1013],{"type":47,"value":1014},"..\u002F..\u002Freferences\u002Ffinal-report.md",{"type":47,"value":1016},"; do not author ",{"type":42,"tag":68,"props":1018,"children":1020},{"className":1019},[],[1021],{"type":47,"value":1022},"report.md",{"type":47,"value":75},{"type":42,"tag":651,"props":1025,"children":1026},{},[1027,1040,1053,1082,1149],{"type":42,"tag":170,"props":1028,"children":1029},{},[1030,1032,1038],{"type":47,"value":1031},"Populate the optional structured details in ",{"type":42,"tag":68,"props":1033,"children":1035},{"className":1034},[],[1036],{"type":47,"value":1037},"..\u002F..\u002Freferences\u002Ffinding-detail-fields.md",{"type":47,"value":1039}," from the same validated evidence used in the generated report.",{"type":42,"tag":170,"props":1041,"children":1042},{},[1043,1045,1051],{"type":47,"value":1044},"For every reportable finding, run ",{"type":42,"tag":68,"props":1046,"children":1048},{"className":1047},[],[1049],{"type":47,"value":1050},"$vulnerability-writeup",{"type":47,"value":1052}," with exactly one dedicated write-up sub-agent. Give it only that finding, its validation and attack-path evidence, relevant source paths and revision, PoC inputs, and the target output directory.",{"type":42,"tag":170,"props":1054,"children":1055},{},[1056,1058,1064,1066,1072,1074,1080],{"type":47,"value":1057},"Write the derived report to ",{"type":42,"tag":68,"props":1059,"children":1061},{"className":1060},[],[1062],{"type":47,"value":1063},"findings\u002F\u003Cslug>\u002F\u003Cslug>.md",{"type":47,"value":1065}," with supporting PoC files under ",{"type":42,"tag":68,"props":1067,"children":1069},{"className":1068},[],[1070],{"type":47,"value":1071},"findings\u002F\u003Cslug>\u002Fpoc\u002F",{"type":47,"value":1073},". Verify the report is a regular file, then set that finding's ",{"type":42,"tag":68,"props":1075,"children":1077},{"className":1076},[],[1078],{"type":47,"value":1079},"writeup.reportPath",{"type":47,"value":1081}," to the matching safe relative path. Do not add the derived report to the sealed artifact list.",{"type":42,"tag":170,"props":1083,"children":1084},{},[1085,1087,1093,1095,1101,1103,1109,1111,1117,1119,1124,1126,1132,1134,1139,1141,1147],{"type":47,"value":1086},"After every write-up is ready, run ",{"type":42,"tag":68,"props":1088,"children":1090},{"className":1089},[],[1091],{"type":47,"value":1092},"$propose-security-hardening",{"type":47,"value":1094}," once over the complete finding collection, detailed write-ups, threat model, coverage, and relevant source. Write its portfolio to ",{"type":42,"tag":68,"props":1096,"children":1098},{"className":1097},[],[1099],{"type":47,"value":1100},"hardening\u002Fhardening.md",{"type":47,"value":1102},", its structured analysis to ",{"type":42,"tag":68,"props":1104,"children":1106},{"className":1105},[],[1107],{"type":47,"value":1108},"hardening\u002Fhardening.json",{"type":47,"value":1110},", and any proposals and diagrams below ",{"type":42,"tag":68,"props":1112,"children":1114},{"className":1113},[],[1115],{"type":47,"value":1116},"hardening\u002F",{"type":47,"value":1118},". Verify ",{"type":42,"tag":68,"props":1120,"children":1122},{"className":1121},[],[1123],{"type":47,"value":1100},{"type":47,"value":1125}," is a regular file, then set ",{"type":42,"tag":68,"props":1127,"children":1129},{"className":1128},[],[1130],{"type":47,"value":1131},"scan.hardening.portfolioPath",{"type":47,"value":1133}," to the fixed relative path ",{"type":42,"tag":68,"props":1135,"children":1137},{"className":1136},[],[1138],{"type":47,"value":1100},{"type":47,"value":1140},". Do not add these derived files to the sealed artifact list. Skip this step and omit ",{"type":42,"tag":68,"props":1142,"children":1144},{"className":1143},[],[1145],{"type":47,"value":1146},"scan.hardening",{"type":47,"value":1148}," when there are no reportable findings.",{"type":42,"tag":170,"props":1150,"children":1151},{},[1152,1154,1159,1161,1167,1169,1175],{"type":47,"value":1153},"Complete the scan once, after all write-ups, hardening guidance, and canonical JSON are ready, so finalization projects the validated JSON and derived-document links into ",{"type":42,"tag":68,"props":1155,"children":1157},{"className":1156},[],[1158],{"type":47,"value":1022},{"type":47,"value":1160},". In the terminal\u002Fchat workflow without ",{"type":42,"tag":68,"props":1162,"children":1164},{"className":1163},[],[1165],{"type":47,"value":1166},"complete_codex_security_scan",{"type":47,"value":1168},", run ",{"type":42,"tag":68,"props":1170,"children":1172},{"className":1171},[],[1173],{"type":47,"value":1174},"python \u003Cplugin_dir>\u002Fscripts\u002Ffinalize_scan_contract.py --scan-dir \u003Cscan_dir> --source-root \u003Crepo_root>",{"type":47,"value":1176}," directly.",{"type":42,"tag":56,"props":1178,"children":1180},{"id":1179},"scan-scope",[1181],{"type":47,"value":1182},"Scan Scope",{"type":42,"tag":651,"props":1184,"children":1185},{},[1186,1198,1203],{"type":42,"tag":170,"props":1187,"children":1188},{},[1189,1191,1197],{"type":47,"value":1190},"Phase 1 (threat model generation) is repository-scope by default, unless the user explicitly asks for narrower scope or provides an authoritative threat model or sufficiently repository-specific security scan guidance such as ",{"type":42,"tag":68,"props":1192,"children":1194},{"className":1193},[],[1195],{"type":47,"value":1196},"AGENTS.md",{"type":47,"value":75},{"type":42,"tag":170,"props":1199,"children":1200},{},[1201],{"type":47,"value":1202},"Phase 2 onward (finding discovery, validation, attack path analysis) remain within the resolved repository or scoped path. For repository-wide scans, the entire checked-out repository is in scope. For scoped-path scans, the requested path, package, folder, or submodule-like boundary is in scope together with directly supporting files needed to understand concrete findings.",{"type":42,"tag":170,"props":1204,"children":1205},{},[1206,1208,1213,1215,1221],{"type":47,"value":1207},"Before the ",{"type":42,"tag":68,"props":1209,"children":1211},{"className":1210},[],[1212],{"type":47,"value":525},{"type":47,"value":1214}," phase, read ",{"type":42,"tag":68,"props":1216,"children":1218},{"className":1217},[],[1219],{"type":47,"value":1220},"references\u002Frepository-wide-scan.md",{"type":47,"value":1222}," and every required reference it lists, then use them for finding discovery, validation, and attack path analysis.",{"type":42,"tag":56,"props":1224,"children":1226},{"id":1225},"scan-target",[1227],{"type":47,"value":1228},"Scan Target",{"type":42,"tag":50,"props":1230,"children":1231},{},[1232],{"type":47,"value":1233},"Resolve the requested audit scope before starting:",{"type":42,"tag":651,"props":1235,"children":1236},{},[1237,1242],{"type":42,"tag":170,"props":1238,"children":1239},{},[1240],{"type":47,"value":1241},"repository-wide: scan the entire checked-out repository",{"type":42,"tag":170,"props":1243,"children":1244},{},[1245],{"type":47,"value":1246},"scoped path: scan the user-specified path, package, folder, or submodule-like boundary inside the checked-out repository",{"type":42,"tag":50,"props":1248,"children":1249},{},[1250],{"type":47,"value":1251},"Treat the resolved repository or scoped path as the in-scope codebase for the later phases of this workflow.",{"type":42,"tag":56,"props":1253,"children":1255},{"id":1254},"scoped-exhaustive-mode",[1256],{"type":47,"value":1257},"Scoped Exhaustive Mode",{"type":42,"tag":50,"props":1259,"children":1260},{},[1261,1263,1268],{"type":47,"value":1262},"For repository-wide and scoped-path scans, follow ",{"type":42,"tag":68,"props":1264,"children":1266},{"className":1265},[],[1267],{"type":47,"value":1220},{"type":47,"value":1269}," and every required reference it lists.",{"type":42,"tag":50,"props":1271,"children":1272},{},[1273],{"type":47,"value":1274},"Treat explicit invocation of this repository-wide or scoped-path exhaustive scan workflow as the user's authorization to use the subagents required by the workflow. If subagents are unavailable, do not claim exhaustive coverage; explain the limitation and offer the narrower parent-agent-only path only if it can still satisfy the requested scope honestly.",{"type":42,"tag":50,"props":1276,"children":1277},{},[1278,1280,1285],{"type":47,"value":1279},"Use the per-scan artifact directory layout from ",{"type":42,"tag":68,"props":1281,"children":1283},{"className":1282},[],[1284],{"type":47,"value":708},{"type":47,"value":75},{"type":42,"tag":56,"props":1287,"children":1289},{"id":1288},"final-output",[1290],{"type":47,"value":1291},"Final Output",{"type":42,"tag":50,"props":1293,"children":1294},{},[1295,1297,1302,1304,1310,1312,1318,1320,1325],{"type":47,"value":1296},"Populate all final report semantics in the canonical manifest, findings, and coverage JSON using ",{"type":42,"tag":68,"props":1298,"children":1300},{"className":1299},[],[1301],{"type":47,"value":1014},{"type":47,"value":1303},". Generate one detailed ",{"type":42,"tag":68,"props":1305,"children":1307},{"className":1306},[],[1308],{"type":47,"value":1309},"vulnerability-writeup",{"type":47,"value":1311}," for every reportable finding, then run ",{"type":42,"tag":68,"props":1313,"children":1315},{"className":1314},[],[1316],{"type":47,"value":1317},"propose-security-hardening",{"type":47,"value":1319}," once over the complete collection and record the safe derived-document paths. Complete the scan once after both stages; finalization owns ",{"type":42,"tag":68,"props":1321,"children":1323},{"className":1322},[],[1324],{"type":47,"value":1022},{"type":47,"value":1326}," generation. Emit Codex app review directives from the completed canonical findings.",{"type":42,"tag":56,"props":1328,"children":1330},{"id":1329},"hard-rules",[1331],{"type":47,"value":1332},"Hard Rules",{"type":42,"tag":50,"props":1334,"children":1335},{},[1336,1337,1343],{"type":47,"value":458},{"type":42,"tag":68,"props":1338,"children":1340},{"className":1339},[],[1341],{"type":47,"value":1342},"..\u002F..\u002Freferences\u002Fshared-hard-rules.md",{"type":47,"value":1344}," before applying scan-mode-specific hard rules.",{"type":42,"tag":651,"props":1346,"children":1347},{},[1348,1374,1404,1416,1445,1457,1462,1467,1480,1485,1498,1528,1533,1538,1543,1548,1553,1558],{"type":42,"tag":170,"props":1349,"children":1350},{},[1351,1353,1358,1360,1365,1367,1372],{"type":47,"value":1352},"After any app setup handoff has provided a ",{"type":42,"tag":68,"props":1354,"children":1356},{"className":1355},[],[1357],{"type":47,"value":73},{"type":47,"value":1359},", or in the non-app terminal\u002Fchat workflow, create or adopt the scan goal only after the capability preflight has returned ",{"type":42,"tag":68,"props":1361,"children":1363},{"className":1362},[],[1364],{"type":47,"value":101},{"type":47,"value":1366},", and before substantive scan work. Do not complete it until the resolved in-scope files\u002Fworklist rows, candidate ledgers, and final reports meet the ",{"type":42,"tag":68,"props":1368,"children":1370},{"className":1369},[],[1371],{"type":47,"value":592},{"type":47,"value":1373}," closure criteria.",{"type":42,"tag":170,"props":1375,"children":1376},{},[1377,1379,1385,1386,1391,1392,1397,1398,1403],{"type":47,"value":1378},"For repository-wide and scoped-path scans, do not equate broad sink counts with completed coverage. The coverage ledger must close each applicable high-impact shard row as ",{"type":42,"tag":68,"props":1380,"children":1382},{"className":1381},[],[1383],{"type":47,"value":1384},"reportable",{"type":47,"value":182},{"type":42,"tag":68,"props":1387,"children":1389},{"className":1388},[],[1390],{"type":47,"value":679},{"type":47,"value":182},{"type":42,"tag":68,"props":1393,"children":1395},{"className":1394},[],[1396],{"type":47,"value":671},{"type":47,"value":673},{"type":42,"tag":68,"props":1399,"children":1401},{"className":1400},[],[1402],{"type":47,"value":664},{"type":47,"value":75},{"type":42,"tag":170,"props":1405,"children":1406},{},[1407,1409,1414],{"type":47,"value":1408},"For every scan scope, candidate-finding coverage is required. Do not finalize a candidate finding until its candidate-ledger path from ",{"type":42,"tag":68,"props":1410,"children":1412},{"className":1411},[],[1413],{"type":47,"value":708},{"type":47,"value":1415}," shows discovery, validation, and attack-path receipts for that exact candidate, or an explicit deferred reason for the missing proof.",{"type":42,"tag":170,"props":1417,"children":1418},{},[1419,1421,1427,1429,1435,1437,1443],{"type":47,"value":1420},"For repository-wide and scoped-path scans, subagent dispatch must have explicit ownership: each of no more than six ranking subagents owns one static ",{"type":42,"tag":68,"props":1422,"children":1424},{"className":1423},[],[1425],{"type":47,"value":1426},"rank_worker_assignments.json",{"type":47,"value":1428}," pool slot containing one or more generated ",{"type":42,"tag":68,"props":1430,"children":1432},{"className":1431},[],[1433],{"type":47,"value":1434},"rank_shards\u002F*.input.jsonl",{"type":47,"value":1436}," shards of at most 150 rows, processes its ordered list sequentially, and writes only the matching worker-local ",{"type":42,"tag":68,"props":1438,"children":1440},{"className":1439},[],[1441],{"type":47,"value":1442},".output.jsonl",{"type":47,"value":1444}," files; file-review subagents own one assessed file or tiny shard and return full-file receipts plus pre-dedupe finding objects with candidate-local validation evidence and attack-path facts; validation subagents own one candidate or ledger row that needs validation closure; attack-path subagents own one validated candidate or validation closure row; the parent agent owns bounded worker orchestration, ledger reconciliation, aggregation, cross-file dedupe, and final closure.",{"type":42,"tag":170,"props":1446,"children":1447},{},[1448,1450,1455],{"type":47,"value":1449},"For repository-wide and scoped-path scans, candidate-finding coverage is separate from file coverage. Do not dedupe or finalize a raw candidate finding until its candidate-ledger path from ",{"type":42,"tag":68,"props":1451,"children":1453},{"className":1452},[],[1454],{"type":47,"value":708},{"type":47,"value":1456}," shows candidate-local validation and candidate-local attack-path receipts, or an explicit deferred reason for missing proof.",{"type":42,"tag":170,"props":1458,"children":1459},{},[1460],{"type":47,"value":1461},"Candidate ids are optional links from coverage rows to findings; a not_applicable, suppressed, or deferred row is still required when the surface was in scope.",{"type":42,"tag":170,"props":1463,"children":1464},{},[1465],{"type":47,"value":1466},"For repository-wide and scoped-path scans, the ranked runtime-surface worklist must exist before discovery is considered complete, and the coverage ledger must be materially broader than the promoted candidate list.",{"type":42,"tag":170,"props":1468,"children":1469},{},[1470,1472,1478],{"type":47,"value":1471},"For repository-wide and scoped-path scans with CVE, GHSA, advisory, issue, release, or package-version identifiers, ",{"type":42,"tag":68,"props":1473,"children":1475},{"className":1474},[],[1476],{"type":47,"value":1477},"seed_research.md",{"type":47,"value":1479}," must exist before discovery is considered complete. It should record authoritative sources searched, candidate files\u002Ffunctions\u002Fclasses\u002Fhunks, and failed lookup attempts. Missing seed research means advisory-led discovery is incomplete unless the scan explicitly states that no network\u002Flocal-history source was available.",{"type":42,"tag":170,"props":1481,"children":1482},{},[1483],{"type":47,"value":1484},"In large repository-wide scans, checkpoint the ranked runtime-surface worklist and initial coverage ledger to disk before deep sink review or validation. A run that is interrupted after frontier mapping should still leave auditable coverage artifacts.",{"type":42,"tag":170,"props":1486,"children":1487},{},[1488,1490,1496],{"type":47,"value":1489},"In large monorepos, top product\u002Fruntime areas by file count or deployment significance must appear as ledger shards or be explicitly excluded with repository evidence; global sink counts and ",{"type":42,"tag":68,"props":1491,"children":1493},{"className":1492},[],[1494],{"type":47,"value":1495},"no top candidate surfaced",{"type":47,"value":1497}," do not close coverage.",{"type":42,"tag":170,"props":1499,"children":1500},{},[1501,1503,1508,1509,1514,1515,1520,1521,1526],{"type":47,"value":1502},"User\u002Fadvisory\u002Ftag-seeded packages, class families, or vulnerability families remain open until the exact seeded row is closed as ",{"type":42,"tag":68,"props":1504,"children":1506},{"className":1505},[],[1507],{"type":47,"value":1384},{"type":47,"value":182},{"type":42,"tag":68,"props":1510,"children":1512},{"className":1511},[],[1513],{"type":47,"value":679},{"type":47,"value":182},{"type":42,"tag":68,"props":1516,"children":1518},{"className":1517},[],[1519],{"type":47,"value":671},{"type":47,"value":673},{"type":42,"tag":68,"props":1522,"children":1524},{"className":1523},[],[1525],{"type":47,"value":664},{"type":47,"value":1527},". A neighboring same-family finding does not close the seeded row.",{"type":42,"tag":170,"props":1529,"children":1530},{},[1531],{"type":47,"value":1532},"For large repository-wide scans, make one reachability pass across every applicable high-impact shard before prolonged validation of any single shard. A row becomes a validation candidate only when it has a concrete entrypoint or privileged boundary, closest relevant control, sink or broken control, and plausible impact.",{"type":42,"tag":170,"props":1534,"children":1535},{},[1536],{"type":47,"value":1537},"Discovery is incomplete when a shard has a promoted finding but still has unclosed sibling packages, concrete implementations, or reusable root-control rows that could be independently vulnerable. Finish those rows or mark them explicitly deferred before final reporting.",{"type":42,"tag":170,"props":1539,"children":1540},{},[1541],{"type":47,"value":1542},"Final assembly must start from reportable validation closure rows and surviving candidates. Do not drop a reportable seeded\u002Froot-control row because attack-path analysis or discovery spent more prose on a neighboring same-family finding.",{"type":42,"tag":170,"props":1544,"children":1545},{},[1546],{"type":47,"value":1547},"Final reporting is incomplete when a promoted high-impact finding's affected lines omit the concrete root-control file\u002Fline discovered or seeded during discovery, such as a codec, converter, parser feature setup, class filter, resource-path control, protocol state transition, or self-service update guard. Add the root-control affected line or explicitly suppress\u002Fdefer it with exact counterevidence before finalizing.",{"type":42,"tag":170,"props":1549,"children":1550},{},[1551],{"type":47,"value":1552},"In repository-wide and scoped-path scans, preserve independently reachable sibling instances through final reporting. Repeated vulnerable templates, query builders, parser operations, auth\u002Fobject endpoints, or shared-helper callers need separate finding entries, affected lines, and dispositions; put grouping in summary prose only after the individual instances are emitted.",{"type":42,"tag":170,"props":1554,"children":1555},{},[1556],{"type":47,"value":1557},"For query\u002Fparser injection, do not suppress syntax-control evidence solely because a later business check appears to limit impact. Carry the injection candidate until validation proves the exact query API and post-query guard defeat semantic change for that instance.",{"type":42,"tag":170,"props":1559,"children":1560},{},[1561],{"type":47,"value":1562},"If large-repository scope forces deferral, make the final report explicit about which deployed or privileged areas and vulnerability families remain deferred.",{"items":1564,"total":1767},[1565,1586,1609,1626,1640,1659,1678,1694,1710,1724,1736,1751],{"slug":1566,"name":1566,"fn":1567,"description":1568,"org":1569,"tags":1570,"stars":1583,"repoUrl":1584,"updatedAt":1585},"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},[1571,1574,1577,1580],{"name":1572,"slug":1573,"type":15},"Documents","documents",{"name":1575,"slug":1576,"type":15},"Healthcare","healthcare",{"name":1578,"slug":1579,"type":15},"Insurance","insurance",{"name":1581,"slug":1582,"type":15},"Regulatory Compliance","regulatory-compliance",28169,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fopenai-agents-python","2026-04-16T05:11:39.180399",{"slug":1587,"name":1587,"fn":1588,"description":1589,"org":1590,"tags":1591,"stars":1606,"repoUrl":1607,"updatedAt":1608},"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},[1592,1595,1597,1600,1603],{"name":1593,"slug":1594,"type":15},".NET","dotnet",{"name":1596,"slug":1587,"type":15},"ASP.NET Core",{"name":1598,"slug":1599,"type":15},"Blazor","blazor",{"name":1601,"slug":1602,"type":15},"C#","csharp",{"name":1604,"slug":1605,"type":15},"Web Development","web-development",23787,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fskills","2026-04-12T05:07:02.819491",{"slug":1610,"name":1610,"fn":1611,"description":1612,"org":1613,"tags":1614,"stars":1606,"repoUrl":1607,"updatedAt":1625},"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},[1615,1618,1621,1624],{"name":1616,"slug":1617,"type":15},"Apps SDK","apps-sdk",{"name":1619,"slug":1620,"type":15},"ChatGPT","chatgpt",{"name":1622,"slug":1623,"type":15},"MCP","mcp",{"name":9,"slug":8,"type":15},"2026-04-12T05:07:05.468097",{"slug":1627,"name":1627,"fn":1628,"description":1629,"org":1630,"tags":1631,"stars":1606,"repoUrl":1607,"updatedAt":1639},"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},[1632,1635,1638],{"name":1633,"slug":1634,"type":15},"API Development","api-development",{"name":1636,"slug":1637,"type":15},"CLI","cli",{"name":23,"slug":24,"type":15},"2026-04-12T05:07:04.132762",{"slug":1641,"name":1641,"fn":1642,"description":1643,"org":1644,"tags":1645,"stars":1606,"repoUrl":1607,"updatedAt":1658},"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},[1646,1649,1652,1655],{"name":1647,"slug":1648,"type":15},"Cloudflare","cloudflare",{"name":1650,"slug":1651,"type":15},"Cloudflare Pages","cloudflare-pages",{"name":1653,"slug":1654,"type":15},"Cloudflare Workers","cloudflare-workers",{"name":1656,"slug":1657,"type":15},"Deployment","deployment","2026-04-12T05:07:14.275118",{"slug":1660,"name":1660,"fn":1661,"description":1662,"org":1663,"tags":1664,"stars":1606,"repoUrl":1607,"updatedAt":1677},"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},[1665,1668,1671,1674],{"name":1666,"slug":1667,"type":15},"Productivity","productivity",{"name":1669,"slug":1670,"type":15},"Project Management","project-management",{"name":1672,"slug":1673,"type":15},"Strategy","strategy",{"name":1675,"slug":1676,"type":15},"Task Management","task-management","2026-05-23T06:17:16.870838",{"slug":1679,"name":1679,"fn":1680,"description":1681,"org":1682,"tags":1683,"stars":1606,"repoUrl":1607,"updatedAt":1693},"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},[1684,1687,1689,1692],{"name":1685,"slug":1686,"type":15},"Design","design",{"name":1688,"slug":1679,"type":15},"Figma",{"name":1690,"slug":1691,"type":15},"Frontend","frontend",{"name":1622,"slug":1623,"type":15},"2026-04-12T05:06:47.939943",{"slug":1695,"name":1695,"fn":1696,"description":1697,"org":1698,"tags":1699,"stars":1606,"repoUrl":1607,"updatedAt":1709},"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},[1700,1701,1704,1705,1706],{"name":1685,"slug":1686,"type":15},{"name":1702,"slug":1703,"type":15},"Design System","design-system",{"name":1688,"slug":1679,"type":15},{"name":1690,"slug":1691,"type":15},{"name":1707,"slug":1708,"type":15},"UI Components","ui-components","2026-05-10T05:59:52.971881",{"slug":1711,"name":1711,"fn":1712,"description":1713,"org":1714,"tags":1715,"stars":1606,"repoUrl":1607,"updatedAt":1723},"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},[1716,1717,1718,1721,1722],{"name":1685,"slug":1686,"type":15},{"name":1702,"slug":1703,"type":15},{"name":1719,"slug":1720,"type":15},"Documentation","documentation",{"name":1688,"slug":1679,"type":15},{"name":1690,"slug":1691,"type":15},"2026-05-16T06:07:47.821474",{"slug":1725,"name":1725,"fn":1726,"description":1727,"org":1728,"tags":1729,"stars":1606,"repoUrl":1607,"updatedAt":1735},"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},[1730,1731,1732,1733,1734],{"name":1685,"slug":1686,"type":15},{"name":1688,"slug":1679,"type":15},{"name":1690,"slug":1691,"type":15},{"name":1707,"slug":1708,"type":15},{"name":1604,"slug":1605,"type":15},"2026-05-16T06:07:40.583615",{"slug":1737,"name":1737,"fn":1738,"description":1739,"org":1740,"tags":1741,"stars":1606,"repoUrl":1607,"updatedAt":1750},"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},[1742,1745,1746,1749],{"name":1743,"slug":1744,"type":15},"Animation","animation",{"name":23,"slug":24,"type":15},{"name":1747,"slug":1748,"type":15},"Creative","creative",{"name":1685,"slug":1686,"type":15},"2026-05-02T05:31:48.48485",{"slug":1752,"name":1752,"fn":1753,"description":1754,"org":1755,"tags":1756,"stars":1606,"repoUrl":1607,"updatedAt":1766},"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},[1757,1758,1759,1762,1765],{"name":1747,"slug":1748,"type":15},{"name":1685,"slug":1686,"type":15},{"name":1760,"slug":1761,"type":15},"Image Generation","image-generation",{"name":1763,"slug":1764,"type":15},"Images","images",{"name":9,"slug":8,"type":15},"2026-05-15T06:23:24.312127",675,{"items":1769,"total":1883},[1770,1787,1803,1815,1833,1851,1871],{"slug":1771,"name":1771,"fn":1772,"description":1773,"org":1774,"tags":1775,"stars":25,"repoUrl":26,"updatedAt":1786},"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},[1776,1779,1782,1785],{"name":1777,"slug":1778,"type":15},"Accessibility","accessibility",{"name":1780,"slug":1781,"type":15},"Charts","charts",{"name":1783,"slug":1784,"type":15},"Data Visualization","data-visualization",{"name":1685,"slug":1686,"type":15},"2026-06-30T19:00:57.102",{"slug":1788,"name":1788,"fn":1789,"description":1790,"org":1791,"tags":1792,"stars":25,"repoUrl":26,"updatedAt":1802},"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},[1793,1796,1799],{"name":1794,"slug":1795,"type":15},"Agents","agents",{"name":1797,"slug":1798,"type":15},"Browser Automation","browser-automation",{"name":1800,"slug":1801,"type":15},"Testing","testing","2026-04-06T18:41:03.44016",{"slug":1804,"name":1804,"fn":1805,"description":1806,"org":1807,"tags":1808,"stars":25,"repoUrl":26,"updatedAt":1814},"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},[1809,1810,1813],{"name":1797,"slug":1798,"type":15},{"name":1811,"slug":1812,"type":15},"Local Development","local-development",{"name":1800,"slug":1801,"type":15},"2026-04-06T18:41:17.526867",{"slug":1816,"name":1816,"fn":1817,"description":1818,"org":1819,"tags":1820,"stars":25,"repoUrl":26,"updatedAt":1832},"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},[1821,1822,1823,1826,1829],{"name":1794,"slug":1795,"type":15},{"name":1653,"slug":1654,"type":15},{"name":1824,"slug":1825,"type":15},"SDK","sdk",{"name":1827,"slug":1828,"type":15},"Serverless","serverless",{"name":1830,"slug":1831,"type":15},"WebSockets","websockets","2026-04-06T18:39:51.717063",{"slug":1834,"name":1834,"fn":1835,"description":1836,"org":1837,"tags":1838,"stars":25,"repoUrl":26,"updatedAt":1850},"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},[1839,1840,1843,1846,1847],{"name":1690,"slug":1691,"type":15},{"name":1841,"slug":1842,"type":15},"React","react",{"name":1844,"slug":1845,"type":15},"shadcn\u002Fui","shadcn-ui",{"name":1707,"slug":1708,"type":15},{"name":1848,"slug":1849,"type":15},"Vercel","vercel","2026-04-06T18:40:59.619419",{"slug":1852,"name":1852,"fn":1853,"description":1854,"org":1855,"tags":1856,"stars":25,"repoUrl":26,"updatedAt":1870},"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},[1857,1860,1863,1866,1869],{"name":1858,"slug":1859,"type":15},"AI Infrastructure","ai-infrastructure",{"name":1861,"slug":1862,"type":15},"Cost Optimization","cost-optimization",{"name":1864,"slug":1865,"type":15},"LLM","llm",{"name":1867,"slug":1868,"type":15},"Performance","performance",{"name":1848,"slug":1849,"type":15},"2026-04-06T18:40:44.377464",{"slug":1872,"name":1872,"fn":1873,"description":1874,"org":1875,"tags":1876,"stars":25,"repoUrl":26,"updatedAt":1882},"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},[1877,1878,1881],{"name":1861,"slug":1862,"type":15},{"name":1879,"slug":1880,"type":15},"Database","database",{"name":1864,"slug":1865,"type":15},"2026-04-06T18:41:08.513425",600]