Update to MOOS-IvP Skills

{
  "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"
}