# Development

> Use when you must develop DO-178C airborne software lifecycle data for avionics items: capture high-level and low-level requirements, maintain bidirectional requirement-to-code trace links, identify derived requirements, and apply design/coding standards scaled to software level. Produce development-phase artifacts (requirements, design, code, trace matrix) for verification, with traceability closure and independent review at levels A and B. Ensure protection and safety assurance trace from top-level system protection needs down to low-level implementation and code, and maintain full coverage of verification results against each requirement and design element. Track verification coverage depth linking each test, analysis, or review outcome to originating requirements. Trigger: DO-178C development, requirements traceability, protection trace, protection assurance, safety assurance trace, verification coverage, derived requirements, low-level requirements, coding standards, software design, lifecycle data.

- Skill: `ashfordeou/development` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add ashfordeou/development`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashfordeou/development/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- License: Apache-2.0
- Author: ashfordeOU (https://skillmd.com/u/ashfordeou)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ashfordeou/development

---


# DO-178C Development (avionics/do178c/development)

Use when the task is DO-178C development-phase work: turning requirements
into verification-ready source code with complete traceability.

## Domain quick reference

- Development process (DO-178C): high-level requirements -> low-level
  requirements -> source code -> object code, with derived requirements
  identified at each step.
- Bidirectional traceability is required at every software level (A-E):
  high-level requirements to low-level requirements, low-level
  requirements to source code, source code to object code.
- Derived requirements: requirements added during development (design
  decisions, safety analysis output) with no direct higher-level source;
  they must be identified and justified.
- Design and coding standards are project-defined; the process must
  produce the data the standards demand.
- Levels A and B require independent review of development data,
  including the trace matrix.

## Workflow

1. Confirm the software level (DAL) from the planning phase.
2. Capture high-level requirements with unique identifiers; each must be
   verifiable and testable.
3. Derive low-level requirements from the high-level set; flag derived
   items explicitly.
4. Implement source code against the low-level requirements under the
   project coding standard.
5. Build the trace matrix across levels; identify orphans and derived
   items.
6. Gate on traceability closure; levels A/B add independent review.

## Pitfalls

- Derived requirements left unidentified (silent orphans).
- One-way traceability (requirements to code without code to
  requirements).
- Non-verifiable requirements that fail later at verification.
- No coding standard defined before code is written.

## Behavior contract (gate 3)

The traceability-completeness logic is exercised by the gate 3 contract
test: scripts/test_development.py against scripts/development_logic.py
(stdlib unittest, offline). Run: python3 scripts/test_development.py

## Compliance

- Standards referenced, not reproduced: DO-178C / ARP4754A / ARP4761A text
  is proprietary (RTCA/SAE); summary-only per standards-map.yaml and brief 06.
- compliance: STANDARDS-REF, gated: false.