fprime-component-development
GitHub指导F Prime组件全生命周期开发，涵盖需求、设计、实现及测试阶段。强制分阶段确认与TDD流程，确保飞行软件质量与安全。适用于新建或重构组件场景。
Trigger Scenarios
Install
npx skills add nasa/fprime --skill fprime-component-development -g -y
SKILL.md
Frontmatter
{
"name": "fprime-component-development",
"description": "Top-level flight development process for F Prime components. Orchestrates the full lifecycle from requirements through integration testing. Trigger on any task involving creating a new F Prime component or adding significant functionality to an existing one. Keywords: F Prime, component, development, lifecycle, flight software, requirements, design, implementation, unit test, integration test."
}
Skill: F Prime Component Development Process
The flight development process for F Prime components follows a strict sequential lifecycle. Each phase produces artifacts that feed the next. Never skip a phase or guess at requirements/design decisions — always ask the user.
For the canonical process description, see the F´ Development Process.
Process Overview
1. Requirements → 2. Design (FPP) → 3. Implementation (C++) → 4. Unit Test → 5. Integration Test
Each phase has a dedicated skill with detailed guidance:
| Phase | Skill | Key Output |
|---|---|---|
| 1. Requirements | fprime-component-requirements |
Written requirements list |
| 2. Design | fprime-component-design-fpp |
.fpp model file |
| 3. Implementation | fprime-component-implementation |
.cpp / .hpp files |
| 4. Unit Test | fprime-component-unit-test |
test/ut/ test suite |
| 5. Integration Test | fprime-component-integration-test |
test/int/ pytest suite |
Cardinal Rules
-
Ask, don't guess. If you are unsure about a requirement, interface, behavior, naming convention, or deployment context — stop and ask the user. Wrong assumptions in flight software are costly.
-
Each phase gates the next — with explicit user approval. Present the requirements to the user and obtain approval before starting design. Present the design (FPP model, port layout, behavior, and any configuration) to the user and obtain explicit confirmation before writing any implementation or unit-test code. This applies even to trivial or pass-through components; simplicity does not waive the gate. Once the model is confirmed, you may write tests against it following the test-driven development pattern (see
docs/how-to/test-driven-development.md). -
Reference the C++ design skill. All implementation must comply with
fprime-cpp-design(CPP-1 through CPP-37). Consult it before writing any C++ code. -
Follow Test-Driven Development when possible. The recommended F Prime workflow is: design in FPP → write tests → implement to pass tests. See the TDD guide.
-
Document as you go. Each component should have an SDD (
docs/sdd.md) that records requirements coverage, port descriptions, and design rationale.
When to Use This Skill
- Creating a new component from scratch
- Adding significant new functionality to an existing component (new ports, commands, telemetry, state machines)
- Migrating or refactoring a component where the interface changes
For small bug fixes or implementation-only changes that don't alter the component's interface, you may skip directly to the implementation and unit test phases — but confirm with the user first.
Quick Reference: Key Commands
| Action | Command |
|---|---|
| Create new component | fprime-util new --component |
| Create new port | fprime-util new --port |
| Generate impl stubs | fprime-util impl |
| Generate UT stubs | fprime-util impl --ut |
| Build component | fprime-util build |
| Run unit tests | fprime-util check |
| Run with coverage | fprime-util check --coverage |
| Generate UT build | fprime-util generate --ut |
| Scaffold rule-based tests | fprime-util new --rule-based-test |
Version History
-
736c365
Current 2026-09-23 01:43
新增CPP-35（操作结果使用枚举）、CPP-36（事件溯源至调用点）和CPP-37（命令处理器必须发射事件）等C++设计规范约束。
- 7d8f579 2026-08-20 11:33
