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-34). 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
- 7d8f579 Current 2026-08-20 11:33
