Reference and apply the Joint Strike Fighter (JSF) Air Vehicle C++ Coding Standards (Doc. No. 2RDU00001 Rev C, "AV Rules") — the Lockheed Martin/MISRA-derived safety-critical C++ standard used in avionics and other high-assurance software. Use this skill whenever the user asks to review, audit, or lint C++ code against the JSF/AV rules or against safety-critical C++ coding standards generally; asks about a specific "AV Rule" by number; wants to write safety-critical, MISRA-style, or DO-178B-adjacent C++ code; asks about coding standards for embedded, avionics, automotive, or other high-integrity C++ systems; or references "JSF", "Air Vehicle coding standards", "2RDU00001", or similar. Also use it to explain the rationale behind a specific rule, find which rule(s) a code snippet violates, or draft a project's own coding standard based on this one.
Apply systems-thinking to reinterpret fictional narratives (films, series, games). Deconstructs official explanations by identifying logical/thermodynamic inconsistencies, then proposes a coherent alternative that reframes all plot elements through a single system-level mechanism. Use when: analyzing sci-fi lore, debunking popular fan theories, reinterpreting fictional worldbuilding, or exploring "what if the official story is wrong." Strong triggers: "film theory", "lore reinterpretation", "debunk this theory", "systems thinking for fiction", "what are [X] actually for in [fictional system]", "reanalyze this story", "plot hole as feature". Anti-triggers: factual documentary analysis, real-world engineering, news reporting.
Use this skill before merging, praising, or considering "done" ANY new algorithm, heuristic, scoring function, or statistical technique added to a research-driven codebase — anything with a formula in it. Trigger this whenever a change is justified by theoretical reasoning alone ("this fills a gap," "this is more rigorous," "this generalizes X") rather than a measured before/after comparison. Also trigger when reviewing a pull request or diff that adds a new scoring/weighting term, when a component has never been run end-to-end against a real target, or when asked "does this actually help" about any subsystem. This skill exists because many projects repeatedly ship mathematically-broken code that passed code review and passing tests, because correctness-in-isolation was mistaken for correctness-in-practice.
Extracts the reasoning behind a solved problem — not just the diff or the fix, but why that approach was chosen, what alternatives were rejected and why, and what generalizes. Use this any time a debugging session, code review, research task, proof attempt, or exploratory investigation reaches a resolution and the user wants it captured as a learnings note, not just closed out. Trigger on explicit requests ("write up what we learned", "extract the approach", "capture this as a pattern", "document the reasoning", "turn this into a note") AND proactively suggest it whenever a nontrivial fix or finding is about to be left undocumented — a solution without a learnings note is unfinished work.
Router that maps user security intent to specific files, scripts, and workflows inside the codex-security plugin. Guides any agent to find and invoke the right plugin files for security tasks — scans, threat models, validation, attack paths, triage, and tracking.
Full Python project bootstrapping workflow. Use this skill whenever the user wants to build a new Python tool, library, CLI, or module from scratch — especially when they mention "create X", "build X in Python", "write a Python project for X", or ask for a proper project with tests, linting, versioning, or git setup. Triggers on any request to scaffold, initialize, or structure a new Python project. Even if the user only says "build me X in Python", apply this skill — it encodes the full professional workflow: SPEC → implementation → pytest → README → lint → git. Always use this skill rather than improvising a one-off script when the deliverable is a reusable project.
Implement and run Inverse Rubric Optimization (IRO) experiments: a black-box judge testbed where an agent must reverse-engineer hidden evaluation criteria under a label budget. Use this skill whenever the user wants to: benchmark agent science methodologies, measure how well an optimizer recovers a hidden rubric, build a poetry/text IRO harness, study reward hacking in LLM optimization loops, measure performance vs label-budget tradeoffs, implement the normalized gap metric (blind vs rubric-visible baseline), or replicate/extend the Fulcrum IRO testbed. Also trigger for: "agent optimizer loop", "black-box judge hill-climbing", "label budget experiment", "prompt optimization against hidden criteria", "reward hacking in LLM eval loops", "IRO testbed", or any task involving an LLM iteratively optimizing a generation policy against an opaque scoring function.
Use this skill whenever the user wants to set up a tight, repeatable test-and-score loop to improve ONE thing — code performance, marketing copy, ad creative, email or DM scripts, landing pages, configs, or prompts — by changing it, measuring it against a single objective number, and keeping only the changes that beat the baseline. Trigger on phrases like "auto research engineer," "nanochat loop," "program train prepare," "A/B test loop," "evolutionary optimization," "hill climbing," or "keep what wins, trash what loses," and on any request to run iterative experiments against one metric (load time, click-through rate, open rate, conversion rate, reply rate, function speed, token cost, etc.) — even if the user doesn't name the skill directly. Also use when the user asks to run something "overnight," "indefinitely," or "in the background" to improve a number, so the actual execution constraints of the current environment get set honestly before work begins.