developmentlisted

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/aero-agent-skills · ★ 0 · AI & Automation · score 78

Install: claude install-skill ashfordeOU/aero-agent-skills

# 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 -