菜单
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/commit/branch/working-tree diffs, or for deep, multi-pass, or variance-reducing scans.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/openai/plugins --skill security-scan命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use this skill when implementing a Figma design as code (design → code) — the read-FROM-Figma direction. Triggers: 'implement this Figma design', 'build this screen from Figma', 'turn this Figma into code', 'code this up from Figma', 'design to code', or a figma.com design URL provided alongside a codebase. Encodes the workflow for reading a node out of Figma with get_design_context and adapting its reference output to the target project — reusing existing components, tokens, and conventions, and honoring Code Connect mappings, component docs, design annotations, and design tokens by priority. Complements figma-code-connect (component mapping) and figma-generate-design / figma-use (the reverse, code → design direction).
Build or update a professional-grade design system in Figma from a codebase. Use when the user wants to create variables/tokens, build component libraries, create individual components with proper variant sets and variable bindings, set up theming (light/dark modes), document foundations, or reconcile gaps between code and Figma. Also use when the user asks to create or generate any component in Figma — even a single one — since components require proper variable foundations, variant states, and design token bindings to be production-quality. This skill teaches WHAT to build and in WHAT ORDER — it complements the `figma-use` skill which teaches HOW to call the Plugin API. Both skills should be loaded together.
**MANDATORY prerequisite** — you MUST invoke this skill BEFORE every `use_figma` tool call. NEVER call `use_figma` directly without loading this skill first. Skipping it causes common, hard-to-debug failures. Trigger whenever the user wants to perform a write action or a unique read action that requires JavaScript execution in the Figma file context — e.g. create/edit/delete nodes, set up variables or tokens, build components and variants, modify auto-layout or fills, bind variables to properties, or inspect file structure programmatically.
基于 SOC 职业分类
正在显示 SKILL.md
| name | security-scan |
| description | 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/commit/branch/working-tree diffs, or for deep, multi-pass, or variance-reducing scans. |
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.
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/chat workflow: do not call Codex Security app setup tools, ask the user to press Start scan, or wait for an app-generated scanId.
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 status: "started" wait result or a direct continuation with a scanId, and the capability preflight has returned ready.
For 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.
Otherwise, in a host that renders MCP Apps and exposes the Codex Security setup continuation tools:
targetPath, mode: "standard", target-relative scope ("." for the whole target), and only user-supplied security focus as userContext.open_codex_security_workspace with the resolved arguments. Do not search for or substitute a separate scan command.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/chat fallback while waiting.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 ../../references/config-preflight.md for the selected target and security_scan profile before goal setup, threat modeling, or other substantive scan work.status: "already_delivered", end the current turn without loading scan context or starting scan work. Another continuation already owns the scan.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/chat fallback.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.In Codex CLI, including interactive and headless runs, or hosts without those capabilities, use the existing prompt-only terminal/chat 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/chat fallback for either result.
Read ../../references/config-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/warn/suggest 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.
Keep these phases distinct and run them in linear order:
$threat-model$finding-discovery$validation$attack-path-analysisTreat this skill as the top-level orchestrator for the four skills plus the final report assembly step. Do not collapse the phases together.
For each phase:
Do not read ahead into later-phase skills until the current phase has completed. Do not amortize effort across phases: complete each phase to the full depth expected by that phase before moving on. For 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.
After 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/chat 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.
Use objective wording shaped like:
Run the Codex Security repository/scoped-path scan for <resolved target>; do not stop until every in-scope file/worklist row has a completion receipt or explicit deferred closure, every candidate has required ledger receipts, and the final report is written.
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.
Do not mark the goal complete until:
deferred, not_applicable, or suppressed closure with exact reasonThe path references in this skill are the default locations for this phase.
If 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.
If a required input is still missing, stop and ask the user for it before continuing.
Use the shared scan artifact path conventions in ../../references/scan-artifacts.md.
Start 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/chat workflow, and the security_scan capability preflight has returned ready.
Follow this plan in order. Do not skip ahead to a later phase until the current phase has produced its intended output.
repo_name, security_scans_dir, scan_id, scan_dir, and artifacts_dir using ../../references/scan-artifacts.md.Goal Setup for that active scan context.../../references/security-guidance.md, compile the resolved scan target's policy to <context_dir>/security_guidance.md, and read it before threat modeling or inspecting source code.$threat-model first.$finding-discovery as the second step, against the resolved repository or scoped path and using the per-scan threat model as context.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.$validation as the third step, for each candidate that came out of discovery and each open, reportable, or deferred seeded/root-control ledger row that still needs closure.../../references/scan-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.../../references/scan-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.$attack-path-analysis as the fourth step, for findings and validation closure rows that still need reportability, attack-path, and severity analysis after validation.../../references/scan-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.../../references/final-report.md; do not author report.md.../../references/finding-detail-fields.md from the same validated evidence used in the generated report.$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.findings/<slug>/<slug>.md with supporting PoC files under findings/<slug>/poc/. 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.$propose-security-hardening once over the complete finding collection, detailed write-ups, threat model, coverage, and relevant source. Write its portfolio to hardening/hardening.md, its structured analysis to hardening/hardening.json, and any proposals and diagrams below hardening/. Verify hardening/hardening.md is a regular file, then set scan.hardening.portfolioPath to the fixed relative path hardening/hardening.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.report.md. In the terminal/chat workflow without complete_codex_security_scan, run python <plugin_dir>/scripts/finalize_scan_contract.py --scan-dir <scan_dir> --source-root <repo_root> directly.AGENTS.md.$finding-discovery phase, read references/repository-wide-scan.md and every required reference it lists, then use them for finding discovery, validation, and attack path analysis.Resolve the requested audit scope before starting:
Treat the resolved repository or scoped path as the in-scope codebase for the later phases of this workflow.
For repository-wide and scoped-path scans, follow references/repository-wide-scan.md and every required reference it lists.
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.
Use the per-scan artifact directory layout from ../../references/scan-artifacts.md.
Populate all final report semantics in the canonical manifest, findings, and coverage JSON using ../../references/final-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.
Read ../../references/shared-hard-rules.md before applying scan-mode-specific hard rules.
scanId, or in the non-app terminal/chat 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/worklist rows, candidate ledgers, and final reports meet the Goal Setup closure criteria.reportable, suppressed, not_applicable, or deferred.../../references/scan-artifacts.md shows discovery, validation, and attack-path receipts for that exact candidate, or an explicit deferred reason for the missing proof.rank_worker_assignments.json pool slot containing one or more generated rank_shards/*.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.../../references/scan-artifacts.md shows candidate-local validation and candidate-local attack-path receipts, or an explicit deferred reason for missing proof.seed_research.md must exist before discovery is considered complete. It should record authoritative sources searched, candidate files/functions/classes/hunks, and failed lookup attempts. Missing seed research means advisory-led discovery is incomplete unless the scan explicitly states that no network/local-history source was available.no top candidate surfaced do not close coverage.reportable, suppressed, not_applicable, or deferred. A neighboring same-family finding does not close the seeded row.