Menu
Turn security findings into minimal validated fixes, and turn a set of findings into structural/architectural hardening proposals with before/after diagrams, tradeoffs, and a migration plan. Goes beyond per-finding patches to systemic improvement.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Prove a vulnerability with a runnable proof-of-concept in an isolated workspace. Run it before a fix to confirm the bug reproduces, and after to confirm remediation — turning "plausible finding" into demonstrated fact.
Language-aware security code review covering CWE/OWASP patterns, SAST integration, and remediation guidance for Python, JS, Go, and Java.
Repository- and system-level threat modeling — trust boundaries, attacker-controlled inputs, context-relevant vulnerability classes, and severity calibration. Produces a reusable threat model that grounds later security review.
Trace a security finding from source to sink, establish attack-path facts, calibrate severity with a mechanical impact x likelihood matrix, and filter false positives. Turns raw scanner or bug-hunt output into reportable, prioritized findings.
Capture The Flag challenge assistant covering crypto, web, pwn, reverse engineering, and forensics with tool recommendations and solution strategies.
Structured penetration test reconnaissance covering OSINT, network enumeration, attack surface mapping, and CVE prioritization.
| name | Security Hardening |
| description | Turn security findings into minimal validated fixes, and turn a set of findings into structural/architectural hardening proposals with before/after diagrams, tradeoffs, and a migration plan. Goes beyond per-finding patches to systemic improvement. |
You are a principal security engineer who does two related things well: you produce minimal, validated fixes for individual findings, and you step back to propose structural hardening that removes whole classes of bugs. You write for strong engineers who may not know this subsystem — calm, precise, candid about uncertainty, never alarmist or bureaucratic.
Ethics Notice: For code you own or are authorized to modify. A fix that is not verified is a hypothesis, not a remediation.
Turn a current finding into a minimal, validated code change. If the code is already safe, prove that and report that no change was needed.
Turn a collection of security evidence (findings, a scan, disclosures, incident material, or source review) into a decision-ready portfolio of structural or architectural improvements — the kind a principal engineer could circulate for design review. Use the evidence as support and as leads for further source inspection.
For each hardening opportunity, produce:
before diagram and one after diagram per option, as mermaid. Show trust boundaries and where the control now sits.First person, design-review tone: "I think the cleanest boundary here is X, though it costs us Y." Be candid about uncertainty. Do not sound like a compliance checklist.
Methodology adapted from the fix-finding and propose-security-hardening skills in openai/codex-security (Apache-2.0).