From MOOS-IvP Skills
Build or modify user-owned IvP helm behaviors outside the core MOOS-IvP source tree. Use when an AI coding agent needs to create a C++ BHV_* behavior, implement IvPBehavior lifecycle methods, build a behavior shared library, make pHelmIvP find behavior libraries through IVP_BEHAVIOR_DIRS, or add .bhv mission configuration for a custom helm behavior.
How this skill is triggered — by the user, by Claude, or both
Slash command
/moos-ivp-skills:ivp-behavior-builderThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill for custom IvP helm behavior development against the local MOOS-IvP checkout. Treat MOOS-IvP as the dependency and example source unless the user explicitly asks to patch core MOOS-IvP.
Use this skill for custom IvP helm behavior development against the local MOOS-IvP checkout. Treat MOOS-IvP as the dependency and example source unless the user explicitly asks to patch core MOOS-IvP.
When this skill needs a local MOOS-IvP checkout, resolve it in this order:
MOOS_IVP_ROOT from the shell environment.ivp/src.~/moos-ivp, ~/src/moos-ivp, ~/repos/moos-ivp, and ~/projects/moos-ivp.moos-ivp, excluding noisy folders.Validate a candidate by confirming ivp/src exists and scripts/GenBehavior is executable.
If no valid checkout is found and the task requires behavior source generation, build wiring, examples, headers, or libraries, stop and ask the user for the checkout path before editing code, generating build files, or using placeholder paths.
ivp/src/lib_behaviors* unless the user explicitly asks to modify core MOOS-IvP.$MOOS_IVP_ROOT/scripts/GenBehavior when there is no close existing behavior to copy.GenBehavior only in a clean behavior source location; it appends to BHV_<Name>.h/.cpp if those files already exist.BHV_<Name>.h/.cpp and BHV_<Name>.createBehavior for dynamic loading.libBHV_<Name>.dylib on macOS or libBHV_<Name>.so on Linux.pHelmIvP can find the library. Default to the user's shell convention: add the project lib directory to IVP_BEHAVIOR_DIRS, usually in .bashrc or the user's equivalent shell startup file when they ask for persistent setup. Use mission-local ivp_behavior_dir = <project>/lib only when the user explicitly wants a self-contained mission, non-interactive execution cannot assume shell setup, or an existing mission already uses that convention..bhv blocks for mission configuration; do not bake mission-specific parameters into the constructor.IvPBehavior::setParam(param, val) first when the behavior should accept standard behavior parameters.m_priority_wt to returned IvP functions.postWMessage() or postEMessage() for behavior warnings/errors instead of silent failure.NAME, ORGN, FILE, and DATE to match the user project.IvPContactBehavior only for behaviors centered on another vehicle/contact.GenBehavior <Name> "<Author>" there.references/behavior-build.md.ADD_LIBRARY(BHV_<Name> SHARED ...) block.references/behavior-patterns.md.subDomain, addInfoVars.setParam: replace the generator placeholder so standard params are accepted through IvPBehavior::setParam(param, val) before custom parsing.onSetParamComplete: validate required and interdependent params.onRunState: read info-buffer state, build/post output, return an IvPFunction* or 0.references/ivp-function-patterns.md.moos-ivp-mission-builder
when the task expands into ordinary mission launchers, ANTLER rosters,
vehicle/shoreside layout, or pMarineViewer operator controls.
Behavior = BHV_<Name> block in the relevant .bhv.LatOrigin and LongOrigin; missing origins can put pHelmIvP in MALCONFIG before behavior loading is exercised.IVP_BEHAVIOR_DIRS when persistent shell setup is in scope.ivp_behavior_dir = <project>/lib to pHelmIvP config only for explicit self-contained, non-interactive, or existing-mission-convention cases.lib/.createBehavior before runtime loading.pHelmIvP can load the behavior through
a normal pAntler mission launch when feasible. Treat direct pHelmIvP
execution as a narrow fallback only; if used, launch with app name
pHelmIvP on PATH or pass --alias=pHelmIvP so the process reads
ProcessConfig = pHelmIvP.IVP_BEHAVIOR_DIRS to only the generated
project lib directory unless inherited behavior dirs are part of the
test.references/behavior-build.md before writing behavior CMake or mission loading lines.references/behavior-patterns.md before implementing lifecycle methods.references/ivp-function-patterns.md before building an objective function.references/behavior-examples.md when choosing local examples to inspect.libBHV_* name.addInfoVars() covers every info-buffer variable read by the behavior.onRunState() handles missing or stale info-buffer values explicitly.m_priority_wt applied..bhv block uses behavior type BHV_<Name> and a unique name.pHelmIvP.createBehavior as a dynamic symbol.About to load behavior library: BHV_<Name> ... SUCCESS, BehaviorSet: all_builds_ok: true, or equivalent appcast/console confirmation.npx claudepluginhub cbenjamin23/moos-ivp-skills --plugin moos-ivp-skillsFetches up-to-date documentation from Context7 for libraries and frameworks like React, Next.js, Prisma. Use for setup questions, API references, and code examples.
Provides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.