# Jsf Av Cpp Standards > 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. - Skill: `daedalus/jsf-av-cpp-standards` (Agent Skill, multi-file: 4 files) - Install (CLI): `npx skillmds@latest add daedalus/jsf-av-cpp-standards` - Raw SKILL.md: https://api.skillmd.com/api/skills/daedalus/jsf-av-cpp-standards/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Security - Author: daedalus (https://skillmd.com/u/daedalus) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/daedalus/jsf-av-cpp-standards --- # JSF Air Vehicle C++ Coding Standards This skill packages the full text of the **Joint Strike Fighter Air Vehicle C++ Coding Standards** (Doc. No. 2RDU00001 Rev C, December 2005, Lockheed Martin — distribution unlimited, publicly released). It contains 228 numbered "AV Rules" governing safety-critical C++ development, built on top of the MISRA C guidelines and a Vehicle Systems Safety-Critical C standard, plus a full appendix of code examples. Use this skill to check code against the standard, look up or explain a specific rule, or help someone write new C++ that already conforms to it. Don't rely on memory for exact rule text or numbers — always look them up in the bundled reference files, since misquoting a "shall" rule number or rationale defeats the point of citing a standard. ## Reference files - `references/rule-index.md` — a table of all 228 AV Rules with rule number, MISRA cross-reference (where one exists), and a one-line summary. **Start here** to find the rule(s) relevant to a question or a piece of code. - `references/standards-body.md` — the full text of the standard: introduction, general design principles (coupling/cohesion, size/complexity), and all 228 rules with their complete statement, rationale, and any exceptions, organized under the original section numbering (4.4 Environment, 4.9 Style, 4.10 Classes, 4.13 Functions, 4.22 Pointers & References, etc.). - `references/appendix-a-examples.md` — Appendix A: worked code examples ("do this / not this") for many of the rules, referenced by rule number. Appendix B (compliance/tooling checklist) is not included — it referred to an external LDRA tool-mapping spreadsheet, not standard content. ## How to use this skill ### Looking up or explaining a specific rule Search `rule-index.md` for the rule number or topic, then read the corresponding entry in `standards-body.md` for the exact wording, rationale, and exceptions. Quote the rule number and its "should/will/shall" strength (see below) rather than paraphrasing loosely — the distinction is load-bearing in this standard. If Appendix A has an example for that rule, pull it in too. ### Reviewing or auditing C++ code against the standard 1. Skim `rule-index.md` and identify which rule categories plausibly apply to the code at hand (e.g., naming, class design, pointers/references, memory allocation, flow control, templates, exceptions). 2. Read the full rule text for each candidate rule in `standards-body.md` before judging compliance — summaries in the index are for triage only, not for citing. 3. Go through the code and flag violations, citing the exact rule number, e.g. "AV Rule 143 (shall): ... — violated here because ...". Distinguish clearly between: - **shall** — mandatory, verified; a real violation to flag as such - **will** — mandatory but not formally verified (often naming/style conventions) - **should** — advisory; note as a recommendation, not a hard violation 4. Where useful, show the corrected code alongside the flagged snippet. 5. Don't invent violations for rules not in this document — if something looks like bad practice but isn't covered by an AV Rule, say so as general advice, separate from standard compliance. ### Writing new code to conform to the standard Apply the relevant "shall"/"will" rules as you write (naming conventions in 4.9, class/ctor/dtor rules in 4.10, function rules in 4.13, pointer/reference rules in 4.22, etc.), and mention which rules informed non-obvious choices (e.g., why a base class destructor is virtual, why a conversion is explicit). If a deviation is genuinely necessary, say so explicitly and note that the real standard requires documented, approved deviations for "shall"/"will" rules (AV Rules 4–7) — this skill can flag the need for a deviation but can't grant the approval itself. ### Drafting a derived/house coding standard If the user wants their own project standard based on this one, use `standards-body.md` as the source of truth for what to keep, relax, or drop, and preserve the should/will/shall terminology if they're aiming for a similarly enforceable document.