{"id":21303,"plugin_id":"plugins_6aadb63c78b88191a10493870d2f5f6d","kind":"skill","collection_source":null,"comparison_source":null,"observed_at":"2026-09-30T23:16:52.888Z","digest":"5056cb7fc846688518036e1a2ee11a3e52f0bcc744a1b1f98caaf5d1fafb8d52","against":null,"payload":{"description":"Build or repair the ordinary mission layer for one standalone MOOS-IvP mission: launchers, meta files, helm layout, communities, ports, nsplug targets, viewer setup, and README updates. For self-evaluating missions, use moos-ivp-eval-mission-builder as the primary skill.","included_files":[{"relative_path":"agents/openai.yaml","size_in_bytes":357},{"relative_path":"assets/baseline-single-vehicle/README.md","size_in_bytes":1522},{"relative_path":"assets/baseline-single-vehicle/clean.sh","size_in_bytes":1176},{"relative_path":"assets/baseline-single-vehicle/launch.sh","size_in_bytes":6825},{"relative_path":"assets/baseline-single-vehicle/launch_shoreside.sh","size_in_bytes":4514},{"relative_path":"assets/baseline-single-vehicle/launch_vehicle.sh","size_in_bytes":5798},{"relative_path":"assets/baseline-single-vehicle/meta_shoreside.moos","size_in_bytes":4275},{"relative_path":"assets/baseline-single-vehicle/meta_vehicle.bhv","size_in_bytes":1852},{"relative_path":"assets/baseline-single-vehicle/meta_vehicle.moos","size_in_bytes":3946},{"relative_path":"assets/baseline-single-vehicle/plug_origin_warp.moos","size_in_bytes":75},{"relative_path":"assets/baseline-two-vehicle/README.md","size_in_bytes":2269},{"relative_path":"assets/baseline-two-vehicle/clean.sh","size_in_bytes":1175},{"relative_path":"assets/baseline-two-vehicle/launch.sh","size_in_bytes":9043},{"relative_path":"assets/baseline-two-vehicle/launch_shoreside.sh","size_in_bytes":4519},{"relative_path":"assets/baseline-two-vehicle/launch_vehicle.sh","size_in_bytes":6068},{"relative_path":"assets/baseline-two-vehicle/meta_shoreside.moos","size_in_bytes":4275},{"relative_path":"assets/baseline-two-vehicle/meta_vehicle.bhv","size_in_bytes":1841},{"relative_path":"assets/baseline-two-vehicle/meta_vehicle.moos","size_in_bytes":3946},{"relative_path":"assets/baseline-two-vehicle/plug_origin_warp.moos","size_in_bytes":75},{"relative_path":"assets/moos-ivp-logo.png","size_in_bytes":1328624},{"relative_path":"references/baseline-single-vehicle.md","size_in_bytes":2364},{"relative_path":"references/baseline-two-vehicle.md","size_in_bytes":1773},{"relative_path":"references/mission-style.md","size_in_bytes":9182},{"relative_path":"references/validation.md","size_in_bytes":6153},{"relative_path":"scripts/check_generated_networking.sh","size_in_bytes":2926},{"relative_path":"scripts/check_generated_ports.sh","size_in_bytes":4378},{"relative_path":"scripts/static_check_mission.sh","size_in_bytes":4113}],"name":"moos-ivp-mission-builder","skill_md_contents":"---\nname: moos-ivp-mission-builder\ndescription: \"Build or repair the ordinary mission layer for one standalone MOOS-IvP mission: launchers, meta files, helm layout, communities, ports, nsplug targets, viewer setup, and README updates. For self-evaluating missions, use moos-ivp-eval-mission-builder as the primary skill.\"\n---\n\n# MOOS-IvP Mission Builder\n\n## Overview\n\nUse this skill for one ordinary mission folder: launchers, meta files, helm\nbehavior layout, mission README, and target generation. The mission may be\nheadless-capable, but it should remain human-readable and runnable on its own.\nOptimize for the quality of that single mission, not for batch execution.\n\nFor custom app config surfaces, use `moos-app-builder`. For custom behavior\nconfig surfaces, use `ivp-behavior-builder`. For upstream app or behavior\nparameters not already clear from the chosen baseline or local repo convention,\nuse `moos-ivp-docs`. Use `moos-alog-analysis` for existing logs or when a\nrequired claim cannot be established through bounded live evidence.\n\n## Core Rules\n\n- Prefer copying `assets/baseline-single-vehicle/` or\n  `assets/baseline-two-vehicle/` and adapting it over writing launchers from\n  scratch.\n- Treat bundled launch scripts as near-copy templates. Change names, defaults,\n  mission-specific parameters, app runs, and forwarded arguments as needed, but\n  preserve the launcher structure unless the existing project has a stronger\n  local convention.\n- Before adding custom mission plumbing or functionality, determine whether\n  existing apps, behaviors, or parameters already achieve the requested effect\n  by checking local examples and docs/source; add new functionality only when\n  none fits.\n- Keep `launch.sh`, `launch_vehicle.sh`, `launch_shoreside.sh`, and `clean.sh`\n  convention-bound. Preserve their `Part N` structure and help summaries.\n- Keep `launch.sh` as the human-facing mission-level launcher.\n- Keep sublaunchers thin: each sublauncher generates one community and launches\n  it unless `--just_make` is set.\n- Let top-level `launch.sh` own interactive `uMAC`; pass `--auto` into\n  sublaunchers so they do not open nested `uMAC` sessions.\n- Use `--just_make` as the first validation path. It proves target generation,\n  not runtime app validity.\n- During live validation, preserve the canonical launcher structure and keep\n  the top-level `launch.sh`/`uMAC` session in the foreground. Use the shortest\n  timeout that proves the claim, capped at 30 seconds unless a stated\n  task-specific reason requires longer. After it stops, verify scoped processes\n  and selected ports are clear.\n- Include caller-controlled port overrides when adding or repairing launchers:\n  `--shore_mport`, `--shore_pshare`, `--veh_mport`, and `--veh_pshare` for a\n  one-vehicle mission. These make the mission easy to run beside other local\n  MOOS work and easy to validate on non-default ports.\n- Keep `ServerHost = localhost`; map each sublauncher's `--ip` value to\n  `pHostInfo.default_hostip_force`, and map vehicle `--shore` separately to the\n  shoreside broker route.\n- Use `nsplug --strict --force -x` for both direct and `--auto` sublauncher\n  generation so unresolved macros fail consistently and `.moosx` / `.bhvx`\n  sidecars remain supported.\n- Launchable mission examples should include `ProcessConfig = ANTLER` with the\n  `Run = ...` roster. A standalone `ProcessConfig = <AppName>` block is\n  appropriate only for intentional snippets or app help text.\n- Treat plug files as discretionary style. Follow the local repo convention:\n  keep small missions readable with direct `ProcessConfig` blocks unless a plug\n  file clearly removes shared duplication or the project already uses plug\n  files.\n- Keep `.moos` and `.bhv` files in the local boxed-header style:\n\n  ```text\n  //-------------------------------------------------\n  // FILE: <filename>\n  // NAME: <author>\n  //-------------------------------------------------\n  ```\n\n- Use `//----------------------------------------------------` for internal\n  section dividers between `ProcessConfig` or `Behavior` blocks.\n- Add a short `README.md` with scenario, files, common run commands, and\n  expected operator action.\n- Do not add `pAutoPoke`, `pMissionEval`, `uMayFinish`, case loops, matrix\n  execution, or result aggregation here unless the user explicitly asks for a\n  self-evaluating test mission. They are not part of an ordinary standalone\n  mission.\n\n## Workflow\n\n1. Resolve the mission shape.\n   - single vehicle vs multiple vehicles\n   - simulated vehicle vs hardware/interface app\n   - shoreside/vehicle split vs standalone community\n   - GUI required vs headless-capable\n   - custom app or behavior integration needs\n2. Start from `assets/baseline-single-vehicle/` for one vehicle or\n   `assets/baseline-two-vehicle/` for two vehicles unless the existing repo\n   already has a closer mission family.\n3. Read `references/mission-style.md` before editing launchers or meta files.\n4. Read `references/baseline-single-vehicle.md` or\n   `references/baseline-two-vehicle.md` before adapting a bundled baseline.\n5. Edit the mission files for the requested scenario.\n   - Keep the wrapper skeleton intact.\n   - Add only the MOOS apps needed for the mission.\n   - Keep behavior blocks small and named clearly.\n   - Preserve port override plumbing end to end.\n6. Add or update `README.md`.\n7. Validate with `./launch.sh --just_make --nogui <warp>`.\n8. Inspect generated `targ_*.moos` and `targ_*.bhv`.\n9. Run live mission validation only if requested or necessary for the change.\n   - When runtime correctness matters, use `references/validation.md` to define\n     the live and post-run `.alog` evidence needed before calling the mission\n     clean.\n\n## Reference Use\n\n- Read `references/mission-style.md` for wrapper and file-style rules.\n- Read `references/baseline-single-vehicle.md` for the bundled baseline design.\n- Read `references/validation.md` before reporting a mission as done.\n- Use `scripts/static_check_mission.sh <mission-dir>` for a quick structural\n  check after creating a mission.\n- Use `scripts/check_generated_ports.sh <mission-dir> --port_base=<base>` to\n  verify that non-default port overrides are reflected in generated targets.\n  Add `--keep-targets` when you need to inspect the generated files afterward.\n- Use `scripts/check_generated_networking.sh <mission-dir>` to verify that\n  sublauncher `--ip` values control advertised `pHostInfo` identity, vehicle\n  `--shore` controls the broker route, and MOOSDB connections remain local.\n\n## Validation Checklist\n\n- `launch.sh --help`, `launch_vehicle.sh --help`, and\n  `launch_shoreside.sh --help` describe the real arguments.\n- `./launch.sh --just_make --nogui <warp>` succeeds.\n- Non-default port target generation succeeds, for example with\n  `scripts/check_generated_ports.sh`.\n- Custom-address target generation succeeds with\n  `scripts/check_generated_networking.sh`.\n- Generated targets include the intended ports, community names, apps, behavior\n  file name, and `MOOSTimeWarp`.\n- The top-level launcher opens at most one `uMAC` session.\n- Sublaunchers receive `--auto` from top-level `launch.sh`.\n- `clean.sh` removes generated targets and logs but does not call `ktm`,\n  `pkill`, or mission-specific teardown.\n- `README.md` explains how to run the mission.\n"},"changes":[],"summary":"First saved snapshot. No earlier version is available for comparison.","summary_kind":"deterministic","summary_metadata":{}}