Imported from nasa/fprime (.github/skills/fprime-component-implementation/SKILL.md). Install upstream with npx skills add nasa/fprime --skill fprime-component-implementation. Copyright stays with the author.

Skill: F Prime Component Implementation (C++)

Implementation fills in the handler stubs generated from the FPP model. The autocoder produces base classes with pure-virtual handlers; you implement the derived class.

For the full reference on autocoded functions (port handlers, command handlers, telemetry, events, parameters, initialization), see Autocoded Functions and Component Classes.

Use F Prime design patterns where possible — standard solutions exist for common needs:

• Rate Group Pattern — docs/user-manual/design-patterns/rate-group.md
• Health Checking — docs/user-manual/design-patterns/health-checking.md
• Manager-Worker — docs/user-manual/design-patterns/manager-worker.md
• Application-Manager-Driver — docs/user-manual/design-patterns/app-man-drv.md
• Common Port Patterns — docs/user-manual/design-patterns/common-port-patterns.md

Follow F Prime Style Guidelines for naming and code style.

Prerequisites

The FPP model must be confirmed (see fprime-component-design-fpp) and C++ design rules (fprime-cpp-design, CPP-1 through CPP-37) are mandatory. The confirmed requirements and FPP model should provide all the information needed for implementation.

Step-by-Step Process

Step 1 — Generate Implementation Stubs

fprime-util impl

This produces <Component>-template.cpp and <Component>-template.hpp files. If this is the first time:

mv <Component>-template.cpp <Component>.cpp
mv <Component>-template.hpp <Component>.hpp

If iterating on an existing design, copy new handler stubs from the template into your existing files.

Step 2 — Implement Handlers

Implement all pure-virtual handlers generated from the FPP model. See Autocoded Functions for handler naming conventions, argument types, and the full API provided by the base class.

Key rules to follow during implementation:

• No dynamic memory after construction (CPP-1) — size all arrays at compile time
• Fixed-size types: U32, FwSizeType, etc. (CPP-3, CPP-28)
• No STL containers — use Fw/DataStructures or fixed arrays (CPP-22, CPP-25)
• No FW_ASSERT on untrusted inputs (CPP-4) — validate and return an error response instead
• All variables initialized (CPP-19)
• Fw::String over char* (CPP-24)
• Every command handler must call cmdResponse_out — omitting it hangs the command in the dispatcher
• Events for each command (CPP-37) — add an event that describes what the command did, including the command arguments. This is frequently forgotten and is very useful for recreating what happened.
• One event emission per call site (CPP-36) — never emit the same event with the same argument set from two places; use a distinct event or a site-identifying argument.
• Mark copy/move as deleted for components (CPP-17)

Step 3 — Build and Fix Errors

fprime-util build

Iterate until compilation succeeds. Common issues:

• Missing #include for types used in handlers
• Incorrect argument types (check the generated base class)
• Missing cmdResponse_out call in command handlers

Step 4 — Review Against C++ Design Rules

Before considering implementation complete, verify compliance with fprime-cpp-design (CPP-1 through CPP-37).

Anti-Patterns

• Using FW_ASSERT on command arguments or hardware inputs
• Forgetting cmdResponse_out (command will hang in dispatcher)
• Command handlers that emit no event describing what the command did (CPP-37)
• The same event emitted from several sites with indistinguishable arguments (CPP-36)
• Using new/delete in handler code
• Using std::string, std::vector, or other STL containers
• Leaving member variables uninitialized
• Implementing behavior not covered by a requirement