From MOOS-IvP Skills
Build or modify user-owned MOOS applications outside the core MOOS-IvP source tree. Use when an AI coding agent needs to create a new C++ MOOS app, wire it into an extension/project build, implement MOOS mail/config/iterate logic, update app help/interface text, or add mission config for a custom MOOS process.
How this skill is triggered — by the user, by Claude, or both
Slash command
/moos-ivp-skills:moos-app-builderThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Use this skill for user application development against the local MOOS-IvP checkout. Treat MOOS-IvP itself as the dependency and example source unless the user explicitly asks to patch core MOOS-IvP.
Use this skill for user application development against the local MOOS-IvP checkout. Treat MOOS-IvP itself 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/GenMOOSApp_AppCasting is executable.
If no valid checkout is found and the task requires app 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.
GenMOOSApp_AppCasting for new apps.src/CMakeLists.txt, update it with ADD_SUBDIRECTORY(<app-dir>).MOOS_IVP_ROOT.OnNewMail() ingests mail, validates messages, and updates state through handleMail* helpers; Iterate() owns most business logic, recurring work, and state-derived publications.OnStartUp(), using handleConfig* helpers for nontrivial values and AppCasting warnings for bad or unhandled config.registerVariables() and call AppCastingMOOSApp::RegisterVariables() in AppCasting apps._Info.cpp as part of the app implementation: synopsis, example config, subscriptions, publications, and options must describe the real app.NAME, ORGN, FILE, and DATE to match the user project.m_; helpers commonly use handleMail*, handleConfig*, post*, update*.--help, --example, and --interface as binary smoke checks
before finishing when feasible. These prove the app starts and its
self-documentation is wired; they do not prove mission runtime config.p: process/control/monitoring appu: utility or simulation-support appuFld: shoreside field appi: interface/driver appp for process/control/monitoring apps and u for utilities or simulation helpers.$MOOS_IVP_ROOT/scripts/GenMOOSApp_AppCasting <Name> <prefix> "<Author>" from the project source directory.references/app-build.md before creating or repairing project-level CMake.references/app-patterns.md for mail/config/iterate/AppCasting conventions.Iterate(). Publish directly from OnNewMail() only for trivial acknowledgments or explicitly requested immediate reactions.GetDouble() or GetString().showSynopsis()showExampleConfigAndExit()showInterfaceAndExit()moos-ivp-mission-builder for broader launcher, ANTLER, vehicle, or
shoreside mission work.
ProcessConfig = <AppName> with realistic AppTick and CommsTick.ProcessConfig in _Info.cpp is
enough. If a runnable sample mission was requested, include the
ProcessConfig and the pAntler or launcher context that actually starts
the app.pAntler or the mission launcher pattern only if the existing mission uses that style.pAntler validation mission with a launcher-local
PATH=<project>/bin:$PATH extension, or document the persistent shell
setup that puts the project bin/ on PATH.--help, --example, and --interface as
smoke checks when those options are supported.pAntler launch with
ProcessConfig = <AppName> rather than treating a direct binary run as
equivalent.references/app-build.md when the project build layout is missing, broken, or unfamiliar.references/app-patterns.md before implementing nontrivial app logic.references/app-examples.md when choosing a representative app to inspect in the resolved MOOS_IVP_ROOT.apputil for AppCasting and mbutil for common utilities.OnNewMail() handles or deliberately ignores subscribed mail without warning on APPCAST_REQ.registerVariables() lists every subscribed variable.showInterfaceAndExit() matches actual subscriptions/publications.--help, --example, and --interface reflect the real app and do not
crash when supported.pAntler with
ProcessConfig = <AppName>, not by direct app-by-path execution alone.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.