How do I install the Development skill?

Run npx skillmds@latest add ashfordeou/development in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Development safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Development?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Development free to use?

Yes. Installing skills from SkillMD is free. This skill is licensed under Apache-2.

Who published Development?

ashfordeOU (@ashfordeou) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Development by ashfordeou — Agent Skill

Name: Development
Author: ashfordeOU

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.

ashfordeOU 4e053e5 3 files · 10.2 KB Updated Sep 17, 2026

File contents

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

Confirm the software level (DAL) from the planning phase.
Capture high-level requirements with unique identifiers; each must be verifiable and testable.
Derive low-level requirements from the high-level set; flag derived items explicitly.
Implement source code against the low-level requirements under the project coding standard.
Build the trace matrix across levels; identify orphans and derived items.
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.

---name: developmentdescription: 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.license: Apache-2.0---# DO-178C Development (avionics/do178c/development)Use when the task is DO-178C development-phase work: turning requirementsinto 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.## Workflow1. 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 contracttest: 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.

Frequently asked questions