| name | jsf-av-cpp-standards |
| description | 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. |
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
- 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).
- 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.
- 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
- Where useful, show the corrected code alongside the flagged snippet.
- 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.
