SKILLEMALL.ai
GitHub ↗ RU Sign in

CB faa-8110-49

Reconstructed reference notes on US FAA approval guidance for airborne software and airborne electronic hardware, built from four public-domain sources (FAA Order 8110.49A, AC 20-115D, AC 20-152A, AC 00-69; documents dated 2017-07-21 to 2022-10-07, pinned 2026-10-12). Use for how FAA certification staff plan and conduct software reviews (certification liaison, desk versus on-site review, review planning agreements), how the level of FAA involvement (LOI) is picked and scored with the Appendix A worksheets, how software conformity inspection works (software part and installation conformity, ASE and ASI tasks, Form 8120-10), what AC 20-115D recognizes and how DO-178B processes and tool qualification transition to DO-178C/DO-330 (supplements, FLS, UMS, legacy software changes), and what AC 20-152A adds for airborne electronic hardware (simple versus complex custom devices, robustness and HDL code coverage, tool assessment, previously developed hardware, COTS IP, COTS devices, circuit board assemblies), and what AC 00-69 adds as best practices for change impact analysis, data and control coupling, and design-level error handling (best practices, not guidance and not a means of compliance). SCOPE LIMITS: FAA guidance only, and guidance is not regulation (ACs are acceptable means, not the only means); no RTCA DO-178C or DO-254, EUROCAE ED-12C or ED-80, supplement, or SAE ARP text, which are copyrighted and named only (see the avionics-signpost pack); no AC 00-72 (named, not packed); no DO-178C software-level objective tables; no EASA AMC 20-115D or AMC 20-152A content (use easa-rules); reflects the pinned source dates, not later FAA actions; synthesized reference notes, not legal advice and not a substitute for the source documents. LICENCE: Public Domain (US Government work, 17 U.S.C. 105).

jgsystemsconsulting/jgs-se-knowledge-packs Agent Skills author: jgsystemsconsulting 18 files body ≈ 4 268 tokens Open the sourcegithub.com↗ analyzed 29 h ago

Reconstructed reference notes on US FAA approval guidance for airborne software and airborne electronic hardware, built from four public-domain sources (FAA…

As a process B 66/100 · Nearly there — weak spots: result and completion, failures and branches, running it twice

ReferenceSoftware developmentSecurityAI and agentstype and topics are labelled automatically from the skill text
Runs in: Claude / Claude Code ChatGPT / Codex Gemini CLI Cursor GitHub Copilot / VS Code Qwen Code Kimi Code CLI Z.ai (GLM) DeepSeek (Deep Code) Mistral Vibe LangChain (deepagents) OpenClaw Goose OpenCode
JSON
Technical rating
C
79/100
safety, quality, tests
Safety 60%
99
Quality 40%
50
Run on models
none yet
Process rating
B
66/100
Nearly there
Failures and branches w 10
0
Progress reporting w 2
0
Running it twice w 4
30
the three weakest of ten parameters · all ten

How to improve

  1. Shorten the description to 1024 characters.
For the model run — optional
  • Your own cases (evals/evals.json, 4–6 real requests with expected answers): the full check would then run those instead of a model-drafted suite.
  • A spec.yaml with trigger phrases and assertions — a behaviour contract for CI; `skilltest init` writes a template.

Guard findings · 1

✓ No critical or high findings

Medium and low: 1
  • low Secrets in code secret-high-entropy-token chapters/ch06-legacy-software-fls-ums.md:17
    High-entropy token-like string (may be an id, hash or a credential)
    - **Legacy software flow (section 9 + Figure 1).** Usage-history gate, then software-level acceptability (Table 1), then modify-or-not branch, then change impact analysis and tool triggers, then keep-

Files scanned: 18. Evidence is masked. Grey chips explain why severity was lowered.

Against the Agent Skills spec

  • error description-long description is 1816 chars, limit 1024
  • note description-budget description takes 1816 of the ~15000-char shared budget for all skills
  • note edit-residue the text marks something as outdated (lines 17, 36, 55, 86): check that old rules are not kept next to new ones — the full check reads the text for contradictions

Process rating: all ten parameters 66/100

  • 0Failures and branches. Linear process with no failure handling
  • 0Progress reporting. Says nothing while it works
  • 30Running it twice. 6 mutating operations with no state check
  • 40Result and completion. Does not say what the result is
  • 50When it triggers. No condition that starts the skill
  • 70Inputs and preconditions. Inputs and preconditions are listed
  • 70Execution cost. Instruction body is 4268 tokens
  • 100Tools and files. No external tools needed
  • 100Steps. 46 steps
  • 100Consistency. Name and required fields are in place

Everything here is measured from the skill text rather than judged by a model, so the numbers are checkable. A parameter weighs more when it is a more common reason for the process to stall.

Quality signals

  • +5Description has no quoted example phrases that should trigger the skill
  • +4Description does not say when NOT to use the skill (false activations)
  • +3Description length 1816: 120–800 characters recommended
  • +3Output format is not stated: the model decides each time
  • +4No input/output examples
  • +2Single-language instructions
  • +4Structure: 15 headings
  • +3Step-by-step instructions: 46 items
  • +1License stated

Quality base 70; lint remarks subtract, signals add up to 100. Result: 50.