[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill-openai-vulnerability-writeup":3,"mdc-aslp33-key":36,"related-repo-openai-vulnerability-writeup":787,"related-org-openai-vulnerability-writeup":911},{"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},"vulnerability-writeup","write vulnerability reports","Write up vulnerabilities from disclosure documents, rough notes, supplied findings, PoCs, source code, or Codex Security scan output into polished, self-contained, source-backed reports. Use for one vulnerability or a disclosure campaign; a Codex Security scan is optional.",{"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},"Audit","audit",{"name":20,"slug":21,"type":15},"Technical Writing","technical-writing",{"name":23,"slug":24,"type":15},"Code Analysis","code-analysis",3992,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fplugins","2026-07-10T06:35:35.744308",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\u002Fvulnerability-writeup","---\nname: vulnerability-writeup\ndescription: Write up vulnerabilities from disclosure documents, rough notes, supplied findings, PoCs, source code, or Codex Security scan output into polished, self-contained, source-backed reports. Use for one vulnerability or a disclosure campaign; a Codex Security scan is optional.\n---\n\n# Vulnerability Writeup\n\n## Overview\n\nProduce a distributable report set from rough vulnerability notes, PoCs, and source code. Treat this as a technical disclosure campaign: every distinct vulnerability gets its own directory, its own report, its own PoC artifacts,\nand its own sub-agent draft. The desired output is not a cleaned-up note. It is a calm, expert narrative that proves the bug from source, explores how far the primitive can realistically be pushed, and ships with a PoC that another researcher can build and run.\n\nDo not require a Codex Security scan, scan ID, manifest, findings JSON, coverage receipt, or seal. Ordinary disclosure documents and supplied vulnerability material are first-class inputs. When scan artifacts are present, use their validated fields as additional evidence; otherwise inventory the supplied documents directly and proceed with the same research and quality bar.\n\n## Core Rules\n\n- Use one sub-agent per vulnerability write-up. Do not assign multiple vulnerabilities to one worker.\n- When this skill is used during Codex Security final reporting, the scan request is already authorization to launch the required one-finding write-up sub-agents. Do not ask for separate sub-agent authorization.\n- The main agent owns inventory and deduplication. Workers receive only the single vulnerability they are writing.\n- Review every sub-agent report yourself before accepting it.\n- If a report falls short, run another sub-agent for that same vulnerability with the raw artifacts and a concise critique.\n- Source access is mandatory for an excellent report. If the source tree or vulnerable revision is missing, stop and get it from the user unless the user explicitly accepts a lower-confidence report.\n- Treat pre-captured source snippets as leads, not as the complete source of truth. Workers must inspect the target source tree or an exact revision snapshot before choosing final snippets.\n- Never guess missing technical detail. Read source, inspect commits, run safe experiments, and clearly separate validated facts from hypotheses.\n- Use lab or VM access only when it is explicitly authorized for this work.\n  Never test against public or live production instances unless the user has explicitly instructed you to do so for that target.\n- Make reports self-contained and distributable. Do not mention Drive,\n  internal provenance, local absolute paths, or prior working folders.\n- Write in the natural first-person voice of a professional vulnerability researcher. Use \"we\" throughout the technical walkthrough to guide the reader through source, state transitions, exploit ideas, and PoC behavior (\"we first reach\", \"if we carry this value forward\", \"from here we control\"). Include honest \"I\" statements for the work actually performed and its limits (\"I reviewed revision\", \"I reproduced\", \"I could not run this without a VM\"). Static review is work and may be stated as such. Never invent testing or personal observations. Do not sprinkle pronouns into otherwise impersonal prose merely to satisfy this rule; the report should feel genuinely narrated.\n- Prefer readable, terminal-friendly line wrapping when it does not make the prose awkward. Do not let line length rules damage clarity, links, tables,\n  code references, or the natural rhythm of the report.\n- Prefer source-backed narrative over labels. Each report should tell the full story: trigger, vulnerable path, bad state, impact, PoC, and fix.\n- Vulnerabilities sometimes have several different options for exploitation.\n  Exploring and discussing alternative exploitation routes is often useful to include in a report even if it's not the best route or the one used for the PoC, so always include those discussions where they add interesting insights or explore ideas that otherwise wouldn't be covered. Where alternatives are covered, make the pros and cons clear, as one would expect in a technical discourse.\n- Treat PoCs as first-class deliverables. The final report directory should contain clean PoC source, build\u002Frun instructions, representative output,\n  and any reliability, cleanup, or target-environment notes the reader needs.\n  If you feel it's not possible to develop a PoC, ask the user for guidance.\n\nIf the platform refuses to start more sub-agents, state that constraint to the user and queue the tasks. You should always delegate one report to one sub-agent. If a sub-agent starts but creates no files after one reasonable wait and one explicit finish instruction, close it and retry once with a tighter prompt for the same single vulnerability. If the retry also stalls,\nmark the writeup phase blocked unless the user explicitly authorizes a main-agent fallback. Do not silently use a main-agent fallback for production scan completion.\n\n## Inputs\n\nGather and preserve these inputs before drafting:\n\n- raw vulnerability documents, exported text, or existing rough reports;\n- supplied scanner findings or Codex Security finding bundles, when present;\n- existing PoCs, scripts, crash logs, traces, and screenshots;\n- the target source tree and exact vulnerable revision or release tag;\n- a focused inventory of relevant source paths, functions, and revisions when available;\n- fix commits, upstream diffs, or advisory text when available;\n- lab access details such as SSH hosts, VMs, kernels, or test accounts;\n- the user's authorization boundary for testing, especially whether any live target is in scope.\n\nWhen the corpus comes from an external store (e.g. cloud storage or network paths), export the key text locally first. The final reports must not refer to external storage unless the user explicitly asks for provenance notes.\n\nThe produced write-ups must be distributable on their own and not assume access to other files or systems.\n\n## Campaign Workflow\n\n1. Create a destination directory, usually `reports` or the user-provided name. Use short, representative slug names.\n2. Build an inventory of candidate documents and PoCs. Record title,\n   subsystem, primitive, affected paths, and likely duplicates.\n3. Deduplicate by root cause and vulnerable code path, not by document title.\n   Merge notes and PoCs that describe the same bug.\n4. Read `references\u002Freport-format.md` in full and use it as the report format.\n   Instruct every worker to do the same before drafting.\n5. Confirm that each distinct vulnerability has enough source context to let a worker trace the bug from entry point to bad state. Inspect the finding's recorded locations, reopen the source around each relevant boundary, and give the worker the focused paths, functions, revision, and short source excerpts it needs. If source access is missing, collect the missing files,\n   revision, fix diff, or build instructions before drafting, or proceed at explicitly lower confidence when the user accepts that limitation.\n6. If authorized lab access exists, record how to reach it and what safety limits apply. If it does not, instruct the worker to build or reason about PoCs locally and to state what could not be executed.\n7. For each distinct vulnerability, create one directory containing an appropriately-named report file as markdown (e.g. `freebsd-shm-uaf.md`)\n   and a `poc\u002F` directory when PoCs exist. Don't just use a nondescript file name like `report.md`.\n8. Launch exactly one sub-agent for that vulnerability. Give it the raw notes, focused source paths and excerpts, target source tree, vulnerable revision, PoCs, output directory, format rules, lab details, and authorization boundary. Do not give it other vulnerabilities.\n9. Review the worker output immediately. Check technical correctness,\n   completeness, line wrapping, self-contained wording, source snippets,\n   exploitability depth, PoC usability, and narrative voice. Reject a report that is written as an impersonal sequence of facts, reserves \"we\" for one token sentence, or never states in first person what was and was not validated.\n10. Reject snippets that cut off before the vulnerable condition, missing guard, dangerous sink, relevant lifetime transition, or proposed fixed invariant. Inspect source directly before asking the worker to rewrite. If the story is thin, incomplete,\n   speculative, narratively compressed, impersonal, or missing a runnable PoC path, launch a new sub-agent for that same vulnerability with the raw inputs and the specific gaps to close.\n11. Make only small main-agent edits after acceptance: heading fixes, line wrapping, command-path portability, and typo cleanup. Do not paper over a weak draft with surface edits.\n12. Run final validation over the whole report set before returning.\n\n## Sub-Agent Prompt\n\nUse a prompt shaped like this for each vulnerability:\n\n```text\nWrite one high-quality vulnerability disclosure report for \u003Cslug>.\n\nYou are responsible for exactly one vulnerability. Do not write about,\nsummarize, compare, or polish any other finding. Quality drops when one\nworker handles multiple bugs, so keep all attention on this single report.\n\nInputs:\n- Raw notes: \u003Cpaths>\n- Existing rough report, if any: \u003Cpath>\n- PoC artifacts: \u003Cpaths>\n- Focused source paths and excerpts: \u003Cpaths and relevant functions>\n- Target source tree: \u003Cpath>\n- Vulnerable revision\u002Frelease: \u003Crevision>\n- Fix commits\u002Fdiffs, if any: \u003Cpaths\u002Frevisions>\n- Lab access: \u003Cssh\u002Fvm details>\n- Testing authorization boundary: \u003Cwhat is allowed and forbidden>\n- Required format: `references\u002Freport-format.md`.\n- Output directory: \u003Creports-dir>\u002F\u003Cslug>\n\nRules:\n- Before drafting, open and read `references\u002Freport-format.md` in full. Its\n  headings are the beginning of the assignment, not a completeness checklist.\n- Analyze source and fixes directly; never guess. Trace the bug from the\n  attacker-controlled entry point through the relevant state transitions to\n  the bad state.\n- Treat supplied snippets as starting points. If a snippet ends before the\n  decisive branch, guard, sink, lifetime transition, or patch invariant,\n  reopen the source tree and quote a complete short snippet instead.\n- Use the source tree throughout the report. Include short, relevant snippets\n  with file paths, functions, and enough surrounding explanation for a human\n  reader to follow the path without opening the repository.\n- Treat the rough notes as leads, not gospel. Validate each claim against the\n  vulnerable source, the fix diff, or an experiment. Correct the notes when\n  the source proves them incomplete or slightly wrong.\n- Explore exploitability, not just reachability. Discuss viable primitives,\n  constraints, allocator or protocol behavior, race windows, object lifetime,\n  attacker-controlled bytes, reliability, and useful dead ends. Build small\n  throwaway probes when they clarify an exploit path.\n- Verify or improve the PoC when safe and authorized. Prefer disposable VMs\n  or local test targets for crashes, corruption, LPE, data loss, or denial of\n  service. Never run against public or live production instances unless the\n  authorization boundary explicitly allows that target.\n- Ship a polished final PoC in `poc\u002F`. Include source, build files, a README\n  when helpful, exact run commands using relative paths, required environment\n  details, expected output, and notes on reliability or cleanup.\n- Produce a self-contained report markdown file with no provenance references\n  and no local absolute paths.\n- Use a natural first-person researcher voice in the report itself. Guide the\n  reader with \"we\" across the substantive walkthrough: introduce why each\n  source excerpt matters, carry values and object state between functions,\n  reason through exploit options, and explain PoC behavior. Do not leave the\n  reader with a dense sequence of snippets and declarative conclusions.\n- Include at least one truthful first-person-singular account of the validation\n  basis and limits. For example: \"I reviewed the vulnerable revision and fix\n  directly, but I did not execute the panic trigger because no disposable VM\n  was available.\" Mention builds, experiments, failures, or observations only\n  when they actually happened.\n- Give important transitions enough prose to teach why the evidence matters.\n  Explore promising exploitation routes, relevant alternatives, constraints,\n  and informative dead ends instead of collapsing exploitability into a verdict\n  paragraph. Add depth where the bug warrants it; do not pad the report.\n- Prefer readable prose wrapping, but do not contort technical language,\n  links, tables, or code references to satisfy a fixed column width.\n- Explain trigger, vulnerable path, bad state, impact, exploitability, PoC,\n  and fix as one coherent narrative. The reader should feel calmly guided\n  from background to source proof to practical demonstration.\n- Use relative commands such as `cd poc` then `make`, not local absolute\n  paths.\n```\n\nWhen re-running a weak report, add only the review deltas:\n\n```text\nThe prior draft was too light on \u003Cspecific gaps>. Rewrite from the raw\nartifacts and source so the report reads as a complete technical story. Use\n\"we\" to guide the actual source and exploitation walkthrough, and state with\n\"I\" what you personally validated and what you could not test. Do not merely\nadd first-person phrases to the existing prose.\n```\n\n## Technical Analysis Standard\n\nFor each report, prove the vulnerability from the target source:\n\n- identify the exact entry point and attacker-controlled inputs;\n- follow data, lifetime, locking, bounds, and state transitions;\n- quote short source snippets only when they clarify the path;\n- inspect vulnerable release code with commands like `git show \u003Crev>:\u003Cfile>`;\n- compare fix commits when available to confirm the intended invariant;\n- describe the resulting kernel or application state precisely;\n- calibrate impact to the validated primitive;\n- name assumptions and unverified exploitability limits.\n\n### Source Work\n\nThe worker should use the repository as a primary artifact:\n\n- inspect the vulnerable revision, not just the current tree;\n- use `git show \u003Crevision>:\u003Cpath>` when the source tree is a Git checkout and the scanned revision is available;\n- identify relevant compile-time options, configuration, permissions, and threat-model checks;\n- search for sibling call sites and variants that help explain the invariant;\n- include snippets from vulnerable code and, when useful, the fixing diff;\n- keep snippets short and narrate the important lines before or after them.\n\n### Exploitability Work\n\nThe Exploitability Analysis section should be thoughtful and specific. It may include unsuccessful branches when they teach the reader something important.\nUseful lines of inquiry include:\n\n- how to maximize attacker control over corrupted data or control flow;\n- how allocator, scheduler, parser, cache, sandbox, or protocol behavior affects reliability;\n- how to groom state before the trigger and stabilize state afterward;\n- what information leaks, write gadgets, confused-deputy paths, or privilege boundaries might combine with the primitive;\n- what constraints make a stronger exploit unlikely.\n\n### PoC Work\n\nUse the lab to build PoCs and run safe probes. For panic, wedge, corruption,\ndata-loss, or LPE cases, prefer disposable VMs and state the risk in the report. If a PoC cannot safely be run, at least verify that it builds or that its build recipe is coherent, and explain the missing execution condition.\n\nA strong final PoC should be easy for the reader to run:\n\n- place it under the report directory's `poc\u002F` folder;\n- include a `Makefile`, script, container recipe, or exact build command;\n- include example commands from a clean checkout or unpacked report bundle;\n- include representative output from a successful run;\n- separate exploratory probes from the polished final PoC when both are kept;\n- include cleanup or reset instructions when the PoC changes system state.\n\n## Report Quality Bar\n\nEvery accepted report must follow the guidance in `references\u002Freport-format.md`.\n\nThe report should read like a complete story for a security engineer who has not seen the original notes. It should patiently walk the reader from the entry point to the vulnerable transition, the bad state, exploitation routes,\nPoC behavior, and the fix. Avoid filler, generic variant-analysis endings,\nand claims unsupported by source or experiment, but include thoughtful discussion and maintain a warm, professional attitude: the voice of one security researcher carefully explaining the work to another.\n\nAn excellent report usually has a few recognizable traits:\n\n- The proof is layered. It establishes the actor, entry point, vulnerable check, bad transformation or state transition, sink, and fixed source shape in an order that feels easy to follow.\n- Exploitability is treated as research. The report names attacker-controlled values, useful primitives, realistic routes, constraints, fallbacks,\n  reliability dependencies, and dead ends that teach something.\n- The PoC section separates diagnostic probes from the strongest exploit or demonstration path, gives a safe-first run order, and includes representative output.\n- Remediation explains the invariant to restore, then gives minimal fixes,\n  deeper structural hardening where useful, and regression tests that exercise the real vulnerable path.\n- The language is precise, calm, and conversationally professional. It should not read like a terse scanner finding, a marketing advisory, or a pile of disconnected notes.\n- The voice sounds like a researcher writing to peers. First-person plural carries the reader through the substantive source, exploitability, and PoC reasoning rather than appearing once as decoration. First-person singular gives an honest account of actual source review, validation work, failed attempts, and limits.\n- The prose explains why each important transition matters. A complete set of headings, snippets, and conclusions is not enough when the connective reasoning remains implicit.\n\nBefore accepting a report, ask whether it reaches the excellent bar:\n\n- Can a reader understand the affected component and threat model without the original notes?\n- Does the report prove the vulnerable path from source and cite the exact functions, files, and revisions that matter?\n- Are code snippets chosen because they illuminate the story, not because the report needed decoration?\n- Does every snippet include the decisive line or branch it is meant to prove,\n  rather than cutting off just before the vulnerability?\n- Does the exploitability analysis explore multiple realistic paths,\n  including constraints and dead ends that sharpen the conclusion?\n- Is there a high-quality final PoC with build\u002Frun commands and example output, or a clear reason why execution was not authorized or safe?\n- Does the remediation explain the invariant that must be restored and show a plausible minimal patch or defensive pattern?\n- Does the report use a natural \"we\" voice through the walkthrough and include a truthful \"I\" account of what the author validated or could not test?\n- Does the prose patiently connect the evidence, or does it still read like a technically correct but lightweight scanner expansion?\n\n## Validation\n\nReview the completed report set directly after drafting and after any rewrite.\nCheck every report against `references\u002Freport-format.md`, then run relevant project checks:\n\n- `rg` for forbidden provenance terms and TODO markers;\n- `rg -n '\\b(we|We|I|our|Our|us)\\b' \u003Creport>` as a quick signal for missing researcher voice, followed by a manual read for natural usage;\n- `make -n` in every `poc\u002F` directory (may need to run on the appropriate target system; doesn't necessarily need to build on whichever system the report is being written on);\n- source commands used in the reports, when feasible;\n- a parity check against the original report directory when rewriting.\n\nDo not hand off until validation passes or the remaining failures are explicitly explained to the user.\n\nA report with no natural first-person walkthrough, or no truthful singular account of the validation basis and limits, fails validation and must be rewritten. A mechanical pronoun match does not make an impersonal report pass.\n",{"data":37,"body":38},{"name":4,"description":6},{"type":39,"children":40},"root",[41,49,56,62,67,73,153,158,164,169,212,217,222,228,333,339,344,356,361,370,376,381,432,439,444,485,491,496,524,530,535,540,588,594,605,610,615,653,658,706,712,724,777,782],{"type":42,"tag":43,"props":44,"children":45},"element","h1",{"id":4},[46],{"type":47,"value":48},"text","Vulnerability Writeup",{"type":42,"tag":50,"props":51,"children":53},"h2",{"id":52},"overview",[54],{"type":47,"value":55},"Overview",{"type":42,"tag":57,"props":58,"children":59},"p",{},[60],{"type":47,"value":61},"Produce a distributable report set from rough vulnerability notes, PoCs, and source code. Treat this as a technical disclosure campaign: every distinct vulnerability gets its own directory, its own report, its own PoC artifacts,\nand its own sub-agent draft. The desired output is not a cleaned-up note. It is a calm, expert narrative that proves the bug from source, explores how far the primitive can realistically be pushed, and ships with a PoC that another researcher can build and run.",{"type":42,"tag":57,"props":63,"children":64},{},[65],{"type":47,"value":66},"Do not require a Codex Security scan, scan ID, manifest, findings JSON, coverage receipt, or seal. Ordinary disclosure documents and supplied vulnerability material are first-class inputs. When scan artifacts are present, use their validated fields as additional evidence; otherwise inventory the supplied documents directly and proceed with the same research and quality bar.",{"type":42,"tag":50,"props":68,"children":70},{"id":69},"core-rules",[71],{"type":47,"value":72},"Core Rules",{"type":42,"tag":74,"props":75,"children":76},"ul",{},[77,83,88,93,98,103,108,113,118,123,128,133,138,143,148],{"type":42,"tag":78,"props":79,"children":80},"li",{},[81],{"type":47,"value":82},"Use one sub-agent per vulnerability write-up. Do not assign multiple vulnerabilities to one worker.",{"type":42,"tag":78,"props":84,"children":85},{},[86],{"type":47,"value":87},"When this skill is used during Codex Security final reporting, the scan request is already authorization to launch the required one-finding write-up sub-agents. Do not ask for separate sub-agent authorization.",{"type":42,"tag":78,"props":89,"children":90},{},[91],{"type":47,"value":92},"The main agent owns inventory and deduplication. Workers receive only the single vulnerability they are writing.",{"type":42,"tag":78,"props":94,"children":95},{},[96],{"type":47,"value":97},"Review every sub-agent report yourself before accepting it.",{"type":42,"tag":78,"props":99,"children":100},{},[101],{"type":47,"value":102},"If a report falls short, run another sub-agent for that same vulnerability with the raw artifacts and a concise critique.",{"type":42,"tag":78,"props":104,"children":105},{},[106],{"type":47,"value":107},"Source access is mandatory for an excellent report. If the source tree or vulnerable revision is missing, stop and get it from the user unless the user explicitly accepts a lower-confidence report.",{"type":42,"tag":78,"props":109,"children":110},{},[111],{"type":47,"value":112},"Treat pre-captured source snippets as leads, not as the complete source of truth. Workers must inspect the target source tree or an exact revision snapshot before choosing final snippets.",{"type":42,"tag":78,"props":114,"children":115},{},[116],{"type":47,"value":117},"Never guess missing technical detail. Read source, inspect commits, run safe experiments, and clearly separate validated facts from hypotheses.",{"type":42,"tag":78,"props":119,"children":120},{},[121],{"type":47,"value":122},"Use lab or VM access only when it is explicitly authorized for this work.\nNever test against public or live production instances unless the user has explicitly instructed you to do so for that target.",{"type":42,"tag":78,"props":124,"children":125},{},[126],{"type":47,"value":127},"Make reports self-contained and distributable. Do not mention Drive,\ninternal provenance, local absolute paths, or prior working folders.",{"type":42,"tag":78,"props":129,"children":130},{},[131],{"type":47,"value":132},"Write in the natural first-person voice of a professional vulnerability researcher. Use \"we\" throughout the technical walkthrough to guide the reader through source, state transitions, exploit ideas, and PoC behavior (\"we first reach\", \"if we carry this value forward\", \"from here we control\"). Include honest \"I\" statements for the work actually performed and its limits (\"I reviewed revision\", \"I reproduced\", \"I could not run this without a VM\"). Static review is work and may be stated as such. Never invent testing or personal observations. Do not sprinkle pronouns into otherwise impersonal prose merely to satisfy this rule; the report should feel genuinely narrated.",{"type":42,"tag":78,"props":134,"children":135},{},[136],{"type":47,"value":137},"Prefer readable, terminal-friendly line wrapping when it does not make the prose awkward. Do not let line length rules damage clarity, links, tables,\ncode references, or the natural rhythm of the report.",{"type":42,"tag":78,"props":139,"children":140},{},[141],{"type":47,"value":142},"Prefer source-backed narrative over labels. Each report should tell the full story: trigger, vulnerable path, bad state, impact, PoC, and fix.",{"type":42,"tag":78,"props":144,"children":145},{},[146],{"type":47,"value":147},"Vulnerabilities sometimes have several different options for exploitation.\nExploring and discussing alternative exploitation routes is often useful to include in a report even if it's not the best route or the one used for the PoC, so always include those discussions where they add interesting insights or explore ideas that otherwise wouldn't be covered. Where alternatives are covered, make the pros and cons clear, as one would expect in a technical discourse.",{"type":42,"tag":78,"props":149,"children":150},{},[151],{"type":47,"value":152},"Treat PoCs as first-class deliverables. The final report directory should contain clean PoC source, build\u002Frun instructions, representative output,\nand any reliability, cleanup, or target-environment notes the reader needs.\nIf you feel it's not possible to develop a PoC, ask the user for guidance.",{"type":42,"tag":57,"props":154,"children":155},{},[156],{"type":47,"value":157},"If the platform refuses to start more sub-agents, state that constraint to the user and queue the tasks. You should always delegate one report to one sub-agent. If a sub-agent starts but creates no files after one reasonable wait and one explicit finish instruction, close it and retry once with a tighter prompt for the same single vulnerability. If the retry also stalls,\nmark the writeup phase blocked unless the user explicitly authorizes a main-agent fallback. Do not silently use a main-agent fallback for production scan completion.",{"type":42,"tag":50,"props":159,"children":161},{"id":160},"inputs",[162],{"type":47,"value":163},"Inputs",{"type":42,"tag":57,"props":165,"children":166},{},[167],{"type":47,"value":168},"Gather and preserve these inputs before drafting:",{"type":42,"tag":74,"props":170,"children":171},{},[172,177,182,187,192,197,202,207],{"type":42,"tag":78,"props":173,"children":174},{},[175],{"type":47,"value":176},"raw vulnerability documents, exported text, or existing rough reports;",{"type":42,"tag":78,"props":178,"children":179},{},[180],{"type":47,"value":181},"supplied scanner findings or Codex Security finding bundles, when present;",{"type":42,"tag":78,"props":183,"children":184},{},[185],{"type":47,"value":186},"existing PoCs, scripts, crash logs, traces, and screenshots;",{"type":42,"tag":78,"props":188,"children":189},{},[190],{"type":47,"value":191},"the target source tree and exact vulnerable revision or release tag;",{"type":42,"tag":78,"props":193,"children":194},{},[195],{"type":47,"value":196},"a focused inventory of relevant source paths, functions, and revisions when available;",{"type":42,"tag":78,"props":198,"children":199},{},[200],{"type":47,"value":201},"fix commits, upstream diffs, or advisory text when available;",{"type":42,"tag":78,"props":203,"children":204},{},[205],{"type":47,"value":206},"lab access details such as SSH hosts, VMs, kernels, or test accounts;",{"type":42,"tag":78,"props":208,"children":209},{},[210],{"type":47,"value":211},"the user's authorization boundary for testing, especially whether any live target is in scope.",{"type":42,"tag":57,"props":213,"children":214},{},[215],{"type":47,"value":216},"When the corpus comes from an external store (e.g. cloud storage or network paths), export the key text locally first. The final reports must not refer to external storage unless the user explicitly asks for provenance notes.",{"type":42,"tag":57,"props":218,"children":219},{},[220],{"type":47,"value":221},"The produced write-ups must be distributable on their own and not assume access to other files or systems.",{"type":42,"tag":50,"props":223,"children":225},{"id":224},"campaign-workflow",[226],{"type":47,"value":227},"Campaign Workflow",{"type":42,"tag":229,"props":230,"children":231},"ol",{},[232,246,251,256,269,274,279,308,313,318,323,328],{"type":42,"tag":78,"props":233,"children":234},{},[235,237,244],{"type":47,"value":236},"Create a destination directory, usually ",{"type":42,"tag":238,"props":239,"children":241},"code",{"className":240},[],[242],{"type":47,"value":243},"reports",{"type":47,"value":245}," or the user-provided name. Use short, representative slug names.",{"type":42,"tag":78,"props":247,"children":248},{},[249],{"type":47,"value":250},"Build an inventory of candidate documents and PoCs. Record title,\nsubsystem, primitive, affected paths, and likely duplicates.",{"type":42,"tag":78,"props":252,"children":253},{},[254],{"type":47,"value":255},"Deduplicate by root cause and vulnerable code path, not by document title.\nMerge notes and PoCs that describe the same bug.",{"type":42,"tag":78,"props":257,"children":258},{},[259,261,267],{"type":47,"value":260},"Read ",{"type":42,"tag":238,"props":262,"children":264},{"className":263},[],[265],{"type":47,"value":266},"references\u002Freport-format.md",{"type":47,"value":268}," in full and use it as the report format.\nInstruct every worker to do the same before drafting.",{"type":42,"tag":78,"props":270,"children":271},{},[272],{"type":47,"value":273},"Confirm that each distinct vulnerability has enough source context to let a worker trace the bug from entry point to bad state. Inspect the finding's recorded locations, reopen the source around each relevant boundary, and give the worker the focused paths, functions, revision, and short source excerpts it needs. If source access is missing, collect the missing files,\nrevision, fix diff, or build instructions before drafting, or proceed at explicitly lower confidence when the user accepts that limitation.",{"type":42,"tag":78,"props":275,"children":276},{},[277],{"type":47,"value":278},"If authorized lab access exists, record how to reach it and what safety limits apply. If it does not, instruct the worker to build or reason about PoCs locally and to state what could not be executed.",{"type":42,"tag":78,"props":280,"children":281},{},[282,284,290,292,298,300,306],{"type":47,"value":283},"For each distinct vulnerability, create one directory containing an appropriately-named report file as markdown (e.g. ",{"type":42,"tag":238,"props":285,"children":287},{"className":286},[],[288],{"type":47,"value":289},"freebsd-shm-uaf.md",{"type":47,"value":291},")\nand a ",{"type":42,"tag":238,"props":293,"children":295},{"className":294},[],[296],{"type":47,"value":297},"poc\u002F",{"type":47,"value":299}," directory when PoCs exist. Don't just use a nondescript file name like ",{"type":42,"tag":238,"props":301,"children":303},{"className":302},[],[304],{"type":47,"value":305},"report.md",{"type":47,"value":307},".",{"type":42,"tag":78,"props":309,"children":310},{},[311],{"type":47,"value":312},"Launch exactly one sub-agent for that vulnerability. Give it the raw notes, focused source paths and excerpts, target source tree, vulnerable revision, PoCs, output directory, format rules, lab details, and authorization boundary. Do not give it other vulnerabilities.",{"type":42,"tag":78,"props":314,"children":315},{},[316],{"type":47,"value":317},"Review the worker output immediately. Check technical correctness,\ncompleteness, line wrapping, self-contained wording, source snippets,\nexploitability depth, PoC usability, and narrative voice. Reject a report that is written as an impersonal sequence of facts, reserves \"we\" for one token sentence, or never states in first person what was and was not validated.",{"type":42,"tag":78,"props":319,"children":320},{},[321],{"type":47,"value":322},"Reject snippets that cut off before the vulnerable condition, missing guard, dangerous sink, relevant lifetime transition, or proposed fixed invariant. Inspect source directly before asking the worker to rewrite. If the story is thin, incomplete,\nspeculative, narratively compressed, impersonal, or missing a runnable PoC path, launch a new sub-agent for that same vulnerability with the raw inputs and the specific gaps to close.",{"type":42,"tag":78,"props":324,"children":325},{},[326],{"type":47,"value":327},"Make only small main-agent edits after acceptance: heading fixes, line wrapping, command-path portability, and typo cleanup. Do not paper over a weak draft with surface edits.",{"type":42,"tag":78,"props":329,"children":330},{},[331],{"type":47,"value":332},"Run final validation over the whole report set before returning.",{"type":42,"tag":50,"props":334,"children":336},{"id":335},"sub-agent-prompt",[337],{"type":47,"value":338},"Sub-Agent Prompt",{"type":42,"tag":57,"props":340,"children":341},{},[342],{"type":47,"value":343},"Use a prompt shaped like this for each vulnerability:",{"type":42,"tag":345,"props":346,"children":351},"pre",{"className":347,"code":349,"language":47,"meta":350},[348],"language-text","Write one high-quality vulnerability disclosure report for \u003Cslug>.\n\nYou are responsible for exactly one vulnerability. Do not write about,\nsummarize, compare, or polish any other finding. Quality drops when one\nworker handles multiple bugs, so keep all attention on this single report.\n\nInputs:\n- Raw notes: \u003Cpaths>\n- Existing rough report, if any: \u003Cpath>\n- PoC artifacts: \u003Cpaths>\n- Focused source paths and excerpts: \u003Cpaths and relevant functions>\n- Target source tree: \u003Cpath>\n- Vulnerable revision\u002Frelease: \u003Crevision>\n- Fix commits\u002Fdiffs, if any: \u003Cpaths\u002Frevisions>\n- Lab access: \u003Cssh\u002Fvm details>\n- Testing authorization boundary: \u003Cwhat is allowed and forbidden>\n- Required format: `references\u002Freport-format.md`.\n- Output directory: \u003Creports-dir>\u002F\u003Cslug>\n\nRules:\n- Before drafting, open and read `references\u002Freport-format.md` in full. Its\n  headings are the beginning of the assignment, not a completeness checklist.\n- Analyze source and fixes directly; never guess. Trace the bug from the\n  attacker-controlled entry point through the relevant state transitions to\n  the bad state.\n- Treat supplied snippets as starting points. If a snippet ends before the\n  decisive branch, guard, sink, lifetime transition, or patch invariant,\n  reopen the source tree and quote a complete short snippet instead.\n- Use the source tree throughout the report. Include short, relevant snippets\n  with file paths, functions, and enough surrounding explanation for a human\n  reader to follow the path without opening the repository.\n- Treat the rough notes as leads, not gospel. Validate each claim against the\n  vulnerable source, the fix diff, or an experiment. Correct the notes when\n  the source proves them incomplete or slightly wrong.\n- Explore exploitability, not just reachability. Discuss viable primitives,\n  constraints, allocator or protocol behavior, race windows, object lifetime,\n  attacker-controlled bytes, reliability, and useful dead ends. Build small\n  throwaway probes when they clarify an exploit path.\n- Verify or improve the PoC when safe and authorized. Prefer disposable VMs\n  or local test targets for crashes, corruption, LPE, data loss, or denial of\n  service. Never run against public or live production instances unless the\n  authorization boundary explicitly allows that target.\n- Ship a polished final PoC in `poc\u002F`. Include source, build files, a README\n  when helpful, exact run commands using relative paths, required environment\n  details, expected output, and notes on reliability or cleanup.\n- Produce a self-contained report markdown file with no provenance references\n  and no local absolute paths.\n- Use a natural first-person researcher voice in the report itself. Guide the\n  reader with \"we\" across the substantive walkthrough: introduce why each\n  source excerpt matters, carry values and object state between functions,\n  reason through exploit options, and explain PoC behavior. Do not leave the\n  reader with a dense sequence of snippets and declarative conclusions.\n- Include at least one truthful first-person-singular account of the validation\n  basis and limits. For example: \"I reviewed the vulnerable revision and fix\n  directly, but I did not execute the panic trigger because no disposable VM\n  was available.\" Mention builds, experiments, failures, or observations only\n  when they actually happened.\n- Give important transitions enough prose to teach why the evidence matters.\n  Explore promising exploitation routes, relevant alternatives, constraints,\n  and informative dead ends instead of collapsing exploitability into a verdict\n  paragraph. Add depth where the bug warrants it; do not pad the report.\n- Prefer readable prose wrapping, but do not contort technical language,\n  links, tables, or code references to satisfy a fixed column width.\n- Explain trigger, vulnerable path, bad state, impact, exploitability, PoC,\n  and fix as one coherent narrative. The reader should feel calmly guided\n  from background to source proof to practical demonstration.\n- Use relative commands such as `cd poc` then `make`, not local absolute\n  paths.\n","",[352],{"type":42,"tag":238,"props":353,"children":354},{"__ignoreMap":350},[355],{"type":47,"value":349},{"type":42,"tag":57,"props":357,"children":358},{},[359],{"type":47,"value":360},"When re-running a weak report, add only the review deltas:",{"type":42,"tag":345,"props":362,"children":365},{"className":363,"code":364,"language":47,"meta":350},[348],"The prior draft was too light on \u003Cspecific gaps>. Rewrite from the raw\nartifacts and source so the report reads as a complete technical story. Use\n\"we\" to guide the actual source and exploitation walkthrough, and state with\n\"I\" what you personally validated and what you could not test. Do not merely\nadd first-person phrases to the existing prose.\n",[366],{"type":42,"tag":238,"props":367,"children":368},{"__ignoreMap":350},[369],{"type":47,"value":364},{"type":42,"tag":50,"props":371,"children":373},{"id":372},"technical-analysis-standard",[374],{"type":47,"value":375},"Technical Analysis Standard",{"type":42,"tag":57,"props":377,"children":378},{},[379],{"type":47,"value":380},"For each report, prove the vulnerability from the target source:",{"type":42,"tag":74,"props":382,"children":383},{},[384,389,394,399,412,417,422,427],{"type":42,"tag":78,"props":385,"children":386},{},[387],{"type":47,"value":388},"identify the exact entry point and attacker-controlled inputs;",{"type":42,"tag":78,"props":390,"children":391},{},[392],{"type":47,"value":393},"follow data, lifetime, locking, bounds, and state transitions;",{"type":42,"tag":78,"props":395,"children":396},{},[397],{"type":47,"value":398},"quote short source snippets only when they clarify the path;",{"type":42,"tag":78,"props":400,"children":401},{},[402,404,410],{"type":47,"value":403},"inspect vulnerable release code with commands like ",{"type":42,"tag":238,"props":405,"children":407},{"className":406},[],[408],{"type":47,"value":409},"git show \u003Crev>:\u003Cfile>",{"type":47,"value":411},";",{"type":42,"tag":78,"props":413,"children":414},{},[415],{"type":47,"value":416},"compare fix commits when available to confirm the intended invariant;",{"type":42,"tag":78,"props":418,"children":419},{},[420],{"type":47,"value":421},"describe the resulting kernel or application state precisely;",{"type":42,"tag":78,"props":423,"children":424},{},[425],{"type":47,"value":426},"calibrate impact to the validated primitive;",{"type":42,"tag":78,"props":428,"children":429},{},[430],{"type":47,"value":431},"name assumptions and unverified exploitability limits.",{"type":42,"tag":433,"props":434,"children":436},"h3",{"id":435},"source-work",[437],{"type":47,"value":438},"Source Work",{"type":42,"tag":57,"props":440,"children":441},{},[442],{"type":47,"value":443},"The worker should use the repository as a primary artifact:",{"type":42,"tag":74,"props":445,"children":446},{},[447,452,465,470,475,480],{"type":42,"tag":78,"props":448,"children":449},{},[450],{"type":47,"value":451},"inspect the vulnerable revision, not just the current tree;",{"type":42,"tag":78,"props":453,"children":454},{},[455,457,463],{"type":47,"value":456},"use ",{"type":42,"tag":238,"props":458,"children":460},{"className":459},[],[461],{"type":47,"value":462},"git show \u003Crevision>:\u003Cpath>",{"type":47,"value":464}," when the source tree is a Git checkout and the scanned revision is available;",{"type":42,"tag":78,"props":466,"children":467},{},[468],{"type":47,"value":469},"identify relevant compile-time options, configuration, permissions, and threat-model checks;",{"type":42,"tag":78,"props":471,"children":472},{},[473],{"type":47,"value":474},"search for sibling call sites and variants that help explain the invariant;",{"type":42,"tag":78,"props":476,"children":477},{},[478],{"type":47,"value":479},"include snippets from vulnerable code and, when useful, the fixing diff;",{"type":42,"tag":78,"props":481,"children":482},{},[483],{"type":47,"value":484},"keep snippets short and narrate the important lines before or after them.",{"type":42,"tag":433,"props":486,"children":488},{"id":487},"exploitability-work",[489],{"type":47,"value":490},"Exploitability Work",{"type":42,"tag":57,"props":492,"children":493},{},[494],{"type":47,"value":495},"The Exploitability Analysis section should be thoughtful and specific. It may include unsuccessful branches when they teach the reader something important.\nUseful lines of inquiry include:",{"type":42,"tag":74,"props":497,"children":498},{},[499,504,509,514,519],{"type":42,"tag":78,"props":500,"children":501},{},[502],{"type":47,"value":503},"how to maximize attacker control over corrupted data or control flow;",{"type":42,"tag":78,"props":505,"children":506},{},[507],{"type":47,"value":508},"how allocator, scheduler, parser, cache, sandbox, or protocol behavior affects reliability;",{"type":42,"tag":78,"props":510,"children":511},{},[512],{"type":47,"value":513},"how to groom state before the trigger and stabilize state afterward;",{"type":42,"tag":78,"props":515,"children":516},{},[517],{"type":47,"value":518},"what information leaks, write gadgets, confused-deputy paths, or privilege boundaries might combine with the primitive;",{"type":42,"tag":78,"props":520,"children":521},{},[522],{"type":47,"value":523},"what constraints make a stronger exploit unlikely.",{"type":42,"tag":433,"props":525,"children":527},{"id":526},"poc-work",[528],{"type":47,"value":529},"PoC Work",{"type":42,"tag":57,"props":531,"children":532},{},[533],{"type":47,"value":534},"Use the lab to build PoCs and run safe probes. For panic, wedge, corruption,\ndata-loss, or LPE cases, prefer disposable VMs and state the risk in the report. If a PoC cannot safely be run, at least verify that it builds or that its build recipe is coherent, and explain the missing execution condition.",{"type":42,"tag":57,"props":536,"children":537},{},[538],{"type":47,"value":539},"A strong final PoC should be easy for the reader to run:",{"type":42,"tag":74,"props":541,"children":542},{},[543,555,568,573,578,583],{"type":42,"tag":78,"props":544,"children":545},{},[546,548,553],{"type":47,"value":547},"place it under the report directory's ",{"type":42,"tag":238,"props":549,"children":551},{"className":550},[],[552],{"type":47,"value":297},{"type":47,"value":554}," folder;",{"type":42,"tag":78,"props":556,"children":557},{},[558,560,566],{"type":47,"value":559},"include a ",{"type":42,"tag":238,"props":561,"children":563},{"className":562},[],[564],{"type":47,"value":565},"Makefile",{"type":47,"value":567},", script, container recipe, or exact build command;",{"type":42,"tag":78,"props":569,"children":570},{},[571],{"type":47,"value":572},"include example commands from a clean checkout or unpacked report bundle;",{"type":42,"tag":78,"props":574,"children":575},{},[576],{"type":47,"value":577},"include representative output from a successful run;",{"type":42,"tag":78,"props":579,"children":580},{},[581],{"type":47,"value":582},"separate exploratory probes from the polished final PoC when both are kept;",{"type":42,"tag":78,"props":584,"children":585},{},[586],{"type":47,"value":587},"include cleanup or reset instructions when the PoC changes system state.",{"type":42,"tag":50,"props":589,"children":591},{"id":590},"report-quality-bar",[592],{"type":47,"value":593},"Report Quality Bar",{"type":42,"tag":57,"props":595,"children":596},{},[597,599,604],{"type":47,"value":598},"Every accepted report must follow the guidance in ",{"type":42,"tag":238,"props":600,"children":602},{"className":601},[],[603],{"type":47,"value":266},{"type":47,"value":307},{"type":42,"tag":57,"props":606,"children":607},{},[608],{"type":47,"value":609},"The report should read like a complete story for a security engineer who has not seen the original notes. It should patiently walk the reader from the entry point to the vulnerable transition, the bad state, exploitation routes,\nPoC behavior, and the fix. Avoid filler, generic variant-analysis endings,\nand claims unsupported by source or experiment, but include thoughtful discussion and maintain a warm, professional attitude: the voice of one security researcher carefully explaining the work to another.",{"type":42,"tag":57,"props":611,"children":612},{},[613],{"type":47,"value":614},"An excellent report usually has a few recognizable traits:",{"type":42,"tag":74,"props":616,"children":617},{},[618,623,628,633,638,643,648],{"type":42,"tag":78,"props":619,"children":620},{},[621],{"type":47,"value":622},"The proof is layered. It establishes the actor, entry point, vulnerable check, bad transformation or state transition, sink, and fixed source shape in an order that feels easy to follow.",{"type":42,"tag":78,"props":624,"children":625},{},[626],{"type":47,"value":627},"Exploitability is treated as research. The report names attacker-controlled values, useful primitives, realistic routes, constraints, fallbacks,\nreliability dependencies, and dead ends that teach something.",{"type":42,"tag":78,"props":629,"children":630},{},[631],{"type":47,"value":632},"The PoC section separates diagnostic probes from the strongest exploit or demonstration path, gives a safe-first run order, and includes representative output.",{"type":42,"tag":78,"props":634,"children":635},{},[636],{"type":47,"value":637},"Remediation explains the invariant to restore, then gives minimal fixes,\ndeeper structural hardening where useful, and regression tests that exercise the real vulnerable path.",{"type":42,"tag":78,"props":639,"children":640},{},[641],{"type":47,"value":642},"The language is precise, calm, and conversationally professional. It should not read like a terse scanner finding, a marketing advisory, or a pile of disconnected notes.",{"type":42,"tag":78,"props":644,"children":645},{},[646],{"type":47,"value":647},"The voice sounds like a researcher writing to peers. First-person plural carries the reader through the substantive source, exploitability, and PoC reasoning rather than appearing once as decoration. First-person singular gives an honest account of actual source review, validation work, failed attempts, and limits.",{"type":42,"tag":78,"props":649,"children":650},{},[651],{"type":47,"value":652},"The prose explains why each important transition matters. A complete set of headings, snippets, and conclusions is not enough when the connective reasoning remains implicit.",{"type":42,"tag":57,"props":654,"children":655},{},[656],{"type":47,"value":657},"Before accepting a report, ask whether it reaches the excellent bar:",{"type":42,"tag":74,"props":659,"children":660},{},[661,666,671,676,681,686,691,696,701],{"type":42,"tag":78,"props":662,"children":663},{},[664],{"type":47,"value":665},"Can a reader understand the affected component and threat model without the original notes?",{"type":42,"tag":78,"props":667,"children":668},{},[669],{"type":47,"value":670},"Does the report prove the vulnerable path from source and cite the exact functions, files, and revisions that matter?",{"type":42,"tag":78,"props":672,"children":673},{},[674],{"type":47,"value":675},"Are code snippets chosen because they illuminate the story, not because the report needed decoration?",{"type":42,"tag":78,"props":677,"children":678},{},[679],{"type":47,"value":680},"Does every snippet include the decisive line or branch it is meant to prove,\nrather than cutting off just before the vulnerability?",{"type":42,"tag":78,"props":682,"children":683},{},[684],{"type":47,"value":685},"Does the exploitability analysis explore multiple realistic paths,\nincluding constraints and dead ends that sharpen the conclusion?",{"type":42,"tag":78,"props":687,"children":688},{},[689],{"type":47,"value":690},"Is there a high-quality final PoC with build\u002Frun commands and example output, or a clear reason why execution was not authorized or safe?",{"type":42,"tag":78,"props":692,"children":693},{},[694],{"type":47,"value":695},"Does the remediation explain the invariant that must be restored and show a plausible minimal patch or defensive pattern?",{"type":42,"tag":78,"props":697,"children":698},{},[699],{"type":47,"value":700},"Does the report use a natural \"we\" voice through the walkthrough and include a truthful \"I\" account of what the author validated or could not test?",{"type":42,"tag":78,"props":702,"children":703},{},[704],{"type":47,"value":705},"Does the prose patiently connect the evidence, or does it still read like a technically correct but lightweight scanner expansion?",{"type":42,"tag":50,"props":707,"children":709},{"id":708},"validation",[710],{"type":47,"value":711},"Validation",{"type":42,"tag":57,"props":713,"children":714},{},[715,717,722],{"type":47,"value":716},"Review the completed report set directly after drafting and after any rewrite.\nCheck every report against ",{"type":42,"tag":238,"props":718,"children":720},{"className":719},[],[721],{"type":47,"value":266},{"type":47,"value":723},", then run relevant project checks:",{"type":42,"tag":74,"props":725,"children":726},{},[727,738,749,767,772],{"type":42,"tag":78,"props":728,"children":729},{},[730,736],{"type":42,"tag":238,"props":731,"children":733},{"className":732},[],[734],{"type":47,"value":735},"rg",{"type":47,"value":737}," for forbidden provenance terms and TODO markers;",{"type":42,"tag":78,"props":739,"children":740},{},[741,747],{"type":42,"tag":238,"props":742,"children":744},{"className":743},[],[745],{"type":47,"value":746},"rg -n '\\b(we|We|I|our|Our|us)\\b' \u003Creport>",{"type":47,"value":748}," as a quick signal for missing researcher voice, followed by a manual read for natural usage;",{"type":42,"tag":78,"props":750,"children":751},{},[752,758,760,765],{"type":42,"tag":238,"props":753,"children":755},{"className":754},[],[756],{"type":47,"value":757},"make -n",{"type":47,"value":759}," in every ",{"type":42,"tag":238,"props":761,"children":763},{"className":762},[],[764],{"type":47,"value":297},{"type":47,"value":766}," directory (may need to run on the appropriate target system; doesn't necessarily need to build on whichever system the report is being written on);",{"type":42,"tag":78,"props":768,"children":769},{},[770],{"type":47,"value":771},"source commands used in the reports, when feasible;",{"type":42,"tag":78,"props":773,"children":774},{},[775],{"type":47,"value":776},"a parity check against the original report directory when rewriting.",{"type":42,"tag":57,"props":778,"children":779},{},[780],{"type":47,"value":781},"Do not hand off until validation passes or the remaining failures are explicitly explained to the user.",{"type":42,"tag":57,"props":783,"children":784},{},[785],{"type":47,"value":786},"A report with no natural first-person walkthrough, or no truthful singular account of the validation basis and limits, fails validation and must be rewritten. A mechanical pronoun match does not make an impersonal report pass.",{"items":788,"total":910},[789,808,824,836,856,878,898],{"slug":790,"name":790,"fn":791,"description":792,"org":793,"tags":794,"stars":25,"repoUrl":26,"updatedAt":807},"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},[795,798,801,804],{"name":796,"slug":797,"type":15},"Accessibility","accessibility",{"name":799,"slug":800,"type":15},"Charts","charts",{"name":802,"slug":803,"type":15},"Data Visualization","data-visualization",{"name":805,"slug":806,"type":15},"Design","design","2026-06-30T19:00:57.102",{"slug":809,"name":809,"fn":810,"description":811,"org":812,"tags":813,"stars":25,"repoUrl":26,"updatedAt":823},"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},[814,817,820],{"name":815,"slug":816,"type":15},"Agents","agents",{"name":818,"slug":819,"type":15},"Browser Automation","browser-automation",{"name":821,"slug":822,"type":15},"Testing","testing","2026-04-06T18:41:03.44016",{"slug":825,"name":825,"fn":826,"description":827,"org":828,"tags":829,"stars":25,"repoUrl":26,"updatedAt":835},"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},[830,831,834],{"name":818,"slug":819,"type":15},{"name":832,"slug":833,"type":15},"Local Development","local-development",{"name":821,"slug":822,"type":15},"2026-04-06T18:41:17.526867",{"slug":837,"name":837,"fn":838,"description":839,"org":840,"tags":841,"stars":25,"repoUrl":26,"updatedAt":855},"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},[842,843,846,849,852],{"name":815,"slug":816,"type":15},{"name":844,"slug":845,"type":15},"Cloudflare Workers","cloudflare-workers",{"name":847,"slug":848,"type":15},"SDK","sdk",{"name":850,"slug":851,"type":15},"Serverless","serverless",{"name":853,"slug":854,"type":15},"WebSockets","websockets","2026-04-06T18:39:51.717063",{"slug":857,"name":857,"fn":858,"description":859,"org":860,"tags":861,"stars":25,"repoUrl":26,"updatedAt":877},"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},[862,865,868,871,874],{"name":863,"slug":864,"type":15},"Frontend","frontend",{"name":866,"slug":867,"type":15},"React","react",{"name":869,"slug":870,"type":15},"shadcn\u002Fui","shadcn-ui",{"name":872,"slug":873,"type":15},"UI Components","ui-components",{"name":875,"slug":876,"type":15},"Vercel","vercel","2026-04-06T18:40:59.619419",{"slug":879,"name":879,"fn":880,"description":881,"org":882,"tags":883,"stars":25,"repoUrl":26,"updatedAt":897},"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},[884,887,890,893,896],{"name":885,"slug":886,"type":15},"AI Infrastructure","ai-infrastructure",{"name":888,"slug":889,"type":15},"Cost Optimization","cost-optimization",{"name":891,"slug":892,"type":15},"LLM","llm",{"name":894,"slug":895,"type":15},"Performance","performance",{"name":875,"slug":876,"type":15},"2026-04-06T18:40:44.377464",{"slug":899,"name":899,"fn":900,"description":901,"org":902,"tags":903,"stars":25,"repoUrl":26,"updatedAt":909},"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},[904,905,908],{"name":888,"slug":889,"type":15},{"name":906,"slug":907,"type":15},"Database","database",{"name":891,"slug":892,"type":15},"2026-04-06T18:41:08.513425",600,{"items":912,"total":1109},[913,934,957,974,990,1007,1026,1038,1052,1066,1078,1093],{"slug":914,"name":914,"fn":915,"description":916,"org":917,"tags":918,"stars":931,"repoUrl":932,"updatedAt":933},"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},[919,922,925,928],{"name":920,"slug":921,"type":15},"Documents","documents",{"name":923,"slug":924,"type":15},"Healthcare","healthcare",{"name":926,"slug":927,"type":15},"Insurance","insurance",{"name":929,"slug":930,"type":15},"Regulatory Compliance","regulatory-compliance",28169,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fopenai-agents-python","2026-04-16T05:11:39.180399",{"slug":935,"name":935,"fn":936,"description":937,"org":938,"tags":939,"stars":954,"repoUrl":955,"updatedAt":956},"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},[940,943,945,948,951],{"name":941,"slug":942,"type":15},".NET","dotnet",{"name":944,"slug":935,"type":15},"ASP.NET Core",{"name":946,"slug":947,"type":15},"Blazor","blazor",{"name":949,"slug":950,"type":15},"C#","csharp",{"name":952,"slug":953,"type":15},"Web Development","web-development",23787,"https:\u002F\u002Fgithub.com\u002Fopenai\u002Fskills","2026-04-12T05:07:02.819491",{"slug":958,"name":958,"fn":959,"description":960,"org":961,"tags":962,"stars":954,"repoUrl":955,"updatedAt":973},"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},[963,966,969,972],{"name":964,"slug":965,"type":15},"Apps SDK","apps-sdk",{"name":967,"slug":968,"type":15},"ChatGPT","chatgpt",{"name":970,"slug":971,"type":15},"MCP","mcp",{"name":9,"slug":8,"type":15},"2026-04-12T05:07:05.468097",{"slug":975,"name":975,"fn":976,"description":977,"org":978,"tags":979,"stars":954,"repoUrl":955,"updatedAt":989},"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},[980,983,986],{"name":981,"slug":982,"type":15},"API Development","api-development",{"name":984,"slug":985,"type":15},"CLI","cli",{"name":987,"slug":988,"type":15},"Codex","codex","2026-04-12T05:07:04.132762",{"slug":991,"name":991,"fn":992,"description":993,"org":994,"tags":995,"stars":954,"repoUrl":955,"updatedAt":1006},"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},[996,999,1002,1003],{"name":997,"slug":998,"type":15},"Cloudflare","cloudflare",{"name":1000,"slug":1001,"type":15},"Cloudflare Pages","cloudflare-pages",{"name":844,"slug":845,"type":15},{"name":1004,"slug":1005,"type":15},"Deployment","deployment","2026-04-12T05:07:14.275118",{"slug":1008,"name":1008,"fn":1009,"description":1010,"org":1011,"tags":1012,"stars":954,"repoUrl":955,"updatedAt":1025},"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},[1013,1016,1019,1022],{"name":1014,"slug":1015,"type":15},"Productivity","productivity",{"name":1017,"slug":1018,"type":15},"Project Management","project-management",{"name":1020,"slug":1021,"type":15},"Strategy","strategy",{"name":1023,"slug":1024,"type":15},"Task Management","task-management","2026-05-23T06:17:16.870838",{"slug":1027,"name":1027,"fn":1028,"description":1029,"org":1030,"tags":1031,"stars":954,"repoUrl":955,"updatedAt":1037},"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},[1032,1033,1035,1036],{"name":805,"slug":806,"type":15},{"name":1034,"slug":1027,"type":15},"Figma",{"name":863,"slug":864,"type":15},{"name":970,"slug":971,"type":15},"2026-04-12T05:06:47.939943",{"slug":1039,"name":1039,"fn":1040,"description":1041,"org":1042,"tags":1043,"stars":954,"repoUrl":955,"updatedAt":1051},"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},[1044,1045,1048,1049,1050],{"name":805,"slug":806,"type":15},{"name":1046,"slug":1047,"type":15},"Design System","design-system",{"name":1034,"slug":1027,"type":15},{"name":863,"slug":864,"type":15},{"name":872,"slug":873,"type":15},"2026-05-10T05:59:52.971881",{"slug":1053,"name":1053,"fn":1054,"description":1055,"org":1056,"tags":1057,"stars":954,"repoUrl":955,"updatedAt":1065},"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},[1058,1059,1060,1063,1064],{"name":805,"slug":806,"type":15},{"name":1046,"slug":1047,"type":15},{"name":1061,"slug":1062,"type":15},"Documentation","documentation",{"name":1034,"slug":1027,"type":15},{"name":863,"slug":864,"type":15},"2026-05-16T06:07:47.821474",{"slug":1067,"name":1067,"fn":1068,"description":1069,"org":1070,"tags":1071,"stars":954,"repoUrl":955,"updatedAt":1077},"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},[1072,1073,1074,1075,1076],{"name":805,"slug":806,"type":15},{"name":1034,"slug":1027,"type":15},{"name":863,"slug":864,"type":15},{"name":872,"slug":873,"type":15},{"name":952,"slug":953,"type":15},"2026-05-16T06:07:40.583615",{"slug":1079,"name":1079,"fn":1080,"description":1081,"org":1082,"tags":1083,"stars":954,"repoUrl":955,"updatedAt":1092},"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},[1084,1087,1088,1091],{"name":1085,"slug":1086,"type":15},"Animation","animation",{"name":987,"slug":988,"type":15},{"name":1089,"slug":1090,"type":15},"Creative","creative",{"name":805,"slug":806,"type":15},"2026-05-02T05:31:48.48485",{"slug":1094,"name":1094,"fn":1095,"description":1096,"org":1097,"tags":1098,"stars":954,"repoUrl":955,"updatedAt":1108},"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},[1099,1100,1101,1104,1107],{"name":1089,"slug":1090,"type":15},{"name":805,"slug":806,"type":15},{"name":1102,"slug":1103,"type":15},"Image Generation","image-generation",{"name":1105,"slug":1106,"type":15},"Images","images",{"name":9,"slug":8,"type":15},"2026-05-15T06:23:24.312127",675]