Update to MOOS-IvP Skills

{
  "description": "Create a user-owned MOOS-IvP extension repository from moos-ivp-extend: clone/customize the template, confirm the local MOOS-IvP dependency, configure PATH and IVP_BEHAVIOR_DIRS, initialize independent Git, and validate the baseline build before app, behavior, or mission work.",
  "included_files": [
    {
      "relative_path": "agents/openai.yaml",
      "size_in_bytes": 313
    },
    {
      "relative_path": "assets/moos-ivp-logo.png",
      "size_in_bytes": 1328624
    }
  ],
  "name": "moos-ivp-repo-builder",
  "skill_md_contents": "---\nname: moos-ivp-repo-builder\ndescription: \"Create a user-owned MOOS-IvP extension repository from moos-ivp-extend: clone/customize the template, confirm the local MOOS-IvP dependency, configure PATH and IVP_BEHAVIOR_DIRS, initialize independent Git, and validate the baseline build before app, behavior, or mission work.\"\n---\n\n# MOOS-IvP Repo Builder\n\n## Overview\n\nUse this skill to bootstrap a new external MOOS-IvP project modeled on the\ncourse `moos-ivp-extend` tree. The goal is a working user-owned repository that\nbuilds, has its `bin`, `scripts`, and behavior `lib` paths available from the\nshell, and is ready for custom apps, behaviors, and missions.\n\nThis skill owns the repo shell and environment setup. For code inside the new\nrepo, delegate follow-on work to:\n\n- `moos-app-builder` for custom MOOS apps\n- `ivp-behavior-builder` for custom IvP behaviors\n- `moos-ivp-mission-builder` for runnable missions\n\n## Defaults\n\n- Template source: `https://github.com/moos-ivp/moos-ivp-extend.git`\n- Git handling: fresh repo. Remove the template `.git/`, then run `git init`.\n- Environment file: `<repo>/env.sh`\n- Persistent shell integration: ask before editing a shell profile\n- Environment additions:\n  - add `<repo>/bin` and `<repo>/scripts` to `PATH`\n  - add `<repo>/lib` to `IVP_BEHAVIOR_DIRS`\n- Keep the example app, behavior, and missions unless the user asks for a\n  clean shell.\n\nUse a different template repo or skip the repo-local environment file only when\nthe user explicitly asks.\n\n## Confirmation Gate\n\nBefore cloning or editing files, collect and confirm:\n\n1. New repo name and target parent directory or full target path.\n2. Repository author name and optional organization string for customized\n   project text. This is not the same as Git commit identity.\n3. Whether examples should stay or be removed.\n4. Whether to add persistent shell integration by sourcing `<repo>/env.sh` from\n   the user's preferred shell profile. If yes, confirm the profile path.\n\nIf the user already gave these values and said to proceed, treat that as the\nconfirmation. Otherwise, stop and ask a concise confirmation question before\ncloning.\n\n## Guiding Vague Users\n\nWhen the user starts with a vague request such as \"I want a new MOOS-IvP repo\",\nguide them with one or two small questions at a time instead of dumping the\nwhole checklist at once.\n\nGood first move:\n\n1. Try to resolve `MOOS_IVP_ROOT` in the background.\n2. Say whether it was found.\n3. Ask for the repo name.\n\nThen ask for the target location, project display author, examples/defaults,\nand shell integration preference as needed. If the user says \"wherever is fine\",\nsuggest a concrete default path and confirm it. Prefer a sibling of the\nvalidated `moos-ivp` checkout, for example `~/my-new-repo` when\n`MOOS_IVP_ROOT` is `~/moos-ivp`. Do not default to nesting the new repo inside\nan unrelated active workspace. Explain that the project display author is for\nREADME/CMake text, not a Git committer email.\n\nWhen proposing persistent shell integration, show the concise block that would\nbe added to the selected profile:\n\n```bash\n# >>> moos-ivp repo: <repo-name> >>>\n[ -f \"<absolute-repo-path>/env.sh\" ] && . \"<absolute-repo-path>/env.sh\"\n# <<< moos-ivp repo: <repo-name> <<<\n```\n\nBefore side effects, summarize the resolved values in one sentence and ask for\nexplicit confirmation.\n\n## MOOS-IvP Root Resolution\n\nResolve `MOOS_IVP_ROOT` before cloning. Try, in order:\n\n1. Path explicitly provided by the user.\n2. `MOOS_IVP_ROOT` from the shell environment.\n3. A sibling or parent `moos-ivp` near the target path or current workspace.\n4. Common home locations:\n   - `~/moos-ivp`\n   - `~/src/moos-ivp`\n   - `~/repos/moos-ivp`\n   - `~/projects/moos-ivp`\n5. A bounded shallow home search for a directory named `moos-ivp`, suppressing\n   expected permission noise.\n\nValidate a candidate by confirming:\n\n- `ivp/src` exists\n- `build-moos.sh` exists\n- `build-ivp.sh` exists\n- `scripts/GenMOOSApp_AppCasting` exists and is executable\n- `scripts/GenBehavior` exists and is executable\n\nIf no valid checkout is found, stop and ask explicitly for the path to the\nlocal `moos-ivp` checkout. Do not clone, edit shell profiles, or create a\nplaceholder path.\n\nIf multiple checkouts are found, prefer the one nearest the target repo. State\nwhich path will be used in the confirmation.\n\n## Workflow\n\n1. Confirm setup values and validated `MOOS_IVP_ROOT`.\n2. Create or verify the target parent directory.\n3. Refuse to overwrite a non-empty target directory unless the user explicitly\n   asks to reuse it.\n4. Clone the template into the target path:\n\n   ```bash\n   git clone https://github.com/moos-ivp/moos-ivp-extend.git <target-repo>\n   ```\n\n5. Detach the template Git metadata and initialize a fresh repo:\n\n   ```bash\n   rm -rf .git\n   git init\n   git branch -M main\n   ```\n\n6. Customize repository text and build wiring.\n   - Keep one top-level README by default. Prefer `README.md`, migrate any\n     useful unique text from legacy `README` if needed, then remove `README`.\n     Keep both only if the user explicitly asks.\n   - Remove inherited template CI metadata by default, including\n     `.github/workflows/build_extend.yml` and `.gitlab-ci.yml`, and remove any\n     README badges or links that refer to the upstream template CI.\n   - Update README title and obvious references from `moos-ivp-extend` to the\n     new repo name in the retained README.\n   - Use the repository author name in the top-level CMake `# NAME:` line and\n     any newly written project text. Label this to the user as the project\n     display author, not Git commit identity. Do not rewrite upstream example\n     source file authors unless the user explicitly asks to claim or replace\n     example code.\n   - Update top-level CMake comments and `PROJECT(...)` only when a clear\n     project identifier is available. Use an uppercase, underscore-safe project\n     token.\n   - If the repo name appears in nested example docs such as\n     `missions/alder/README` or `src/lib_behaviors-test/README`, update only\n     path references needed for the examples to remain accurate.\n   - Scrub obvious visible template names in comments and docs that a user is\n     likely to open, including top-level `CMakeLists.txt`, `src/CMakeLists.txt`,\n     and mission/example README files. Do not churn source-file history\n     comments merely to remove upstream maintainer names.\n   - Make the resolved `MOOS_IVP_ROOT` effective for builds. Treat it as a\n     setup-time input, not a shell variable that users must keep forever. The\n     upstream\n     template only searches nearby relative paths, so a repo outside the same\n     parent as `moos-ivp` can fail unless the path is wired explicitly.\n     Update top-level `CMakeLists.txt` with the resolved absolute path:\n     - append `<moos-ivp-root>/build/MOOS/MOOSCore` to `CMAKE_PREFIX_PATH`\n       before `find_package(MOOS 10.0)`\n     - add `<moos-ivp-root>` to the\n       `find_path(MOOSIVP_SOURCE_TREE_BASE ... PATHS ...)` list\n     This makes normal future `./build.sh` runs work without requiring\n     `MOOS_IVP_ROOT` in `.bashrc`.\n   - Do not add repository automation files or remote GitHub setup unless the\n     user explicitly asks.\n7. If the user requested a clean shell, remove sample source and mission\n   directories carefully and keep the build skeleton valid. Otherwise retain\n   examples so the baseline build has known artifacts to verify.\n8. Create the repo-local shell environment file.\n   - Write `<repo>/env.sh`.\n   - Resolve the absolute paths for the new repo's `bin`, `scripts`, and\n     `lib` directories before writing the file.\n   - Make repeated sourcing idempotent so PATH and `IVP_BEHAVIOR_DIRS` do not\n     accumulate duplicate entries.\n   - Keep the file source-compatible with common Bash and zsh startup files.\n   - Use this shape:\n\n     ```bash\n     #!/usr/bin/env bash\n     # Source this file to use this MOOS-IvP extension repo.\n     case \":$PATH:\" in *\":<absolute-repo-bin>:\"*) ;; *) PATH=\"$PATH:<absolute-repo-bin>\" ;; esac\n     case \":$PATH:\" in *\":<absolute-repo-scripts>:\"*) ;; *) PATH=\"$PATH:<absolute-repo-scripts>\" ;; esac\n     case \":${IVP_BEHAVIOR_DIRS:-}:\" in *\":<absolute-repo-lib>:\"*) ;; *) IVP_BEHAVIOR_DIRS=\"${IVP_BEHAVIOR_DIRS:+$IVP_BEHAVIOR_DIRS:}<absolute-repo-lib>\" ;; esac\n     export PATH\n     export IVP_BEHAVIOR_DIRS\n     ```\n\n9. If the user opted into persistent shell integration, update the selected\n   shell profile.\n   - Ask for the profile path instead of assuming one. If the user named a\n     shell, suggest its usual profile, such as `~/.zshrc` for zsh or\n     `~/.bashrc` for Bash, and ask for confirmation. If the user did not name a\n     shell, ask which profile to update and offer common choices: `~/.zshrc`,\n     `~/.bashrc`, or no profile edit.\n   - Create the profile file if it does not exist.\n   - Preserve user content.\n   - Append the managed source block near the end of the profile so it runs\n     after earlier PATH setup. Do not insert it before later lines that reset or\n     export PATH.\n   - Use a clearly marked block:\n\n     ```bash\n     # >>> moos-ivp repo: <repo-name> >>>\n     [ -f \"<absolute-repo-path>/env.sh\" ] && . \"<absolute-repo-path>/env.sh\"\n     # <<< moos-ivp repo: <repo-name> <<<\n     ```\n\n   - If the user opted out, leave the profile unchanged and tell them they can\n     run `. <repo>/env.sh` in a shell session.\n10. Validate the baseline.\n   - Run `./build.sh` from a normal tool-capable shell, not from a shell whose\n     profile has hidden basic build tools. The repo CMake should already have\n     the resolved `moos-ivp` path wired in, so build validation should not\n     depend on `MOOS_IVP_ROOT` being exported.\n   - If examples were retained, confirm:\n     - `bin/pXRelayTest` exists and is executable\n     - `lib/libBHV_SimpleWaypoint.dylib` on macOS or\n       `lib/libBHV_SimpleWaypoint.so` on Linux exists\n   - Validate `<repo>/env.sh` separately by sourcing it in a shell and\n     confirming the new absolute `bin`, `scripts`, and `lib` paths appear in\n     `PATH` / `IVP_BEHAVIOR_DIRS`.\n   - If a persistent profile source block was added, validate that applying the\n     selected profile reaches the same environment.\n   - If sourcing the user's profile hides build tools such as `mkdir`, `make`,\n     or `cmake`, report that as a profile/tooling issue, not as a repo build\n     failure.\n   - Run `which pXRelayTest` or `command -v pXRelayTest` only after applying\n     `<repo>/env.sh` or the selected profile.\n11. Initialize the first commit when the user asked for Git setup or when they\n    asked for a ready fresh repo, but only if Git identity is already\n    configured or the user supplied both a commit author name and email.\n    Repository author text collected earlier is for project files, not enough\n    to invent a Git committer email:\n\n    ```bash\n    git add .\n    git commit -m \"chore: initialize MOOS-IvP extension repo\"\n    ```\n\n    Skip the commit if Git user identity is missing and report the exact\n    blocker instead of inventing identity values. Do not ask for Git email\n    during the initial setup unless the user specifically wants the first\n    commit completed in the same turn.\n12. If no remote was attached, mention the natural next step: create an empty\n    GitHub repository under the user's account or organization, add it as\n    `origin`, and push `main`. Do not perform this unless the user explicitly\n    asks. Remind the user that if their GitHub credentials are connected, the\n    AI agent can create the GitHub repo, add the remote, and push for them.\n\n## Environment Editing Rules\n\n- Expand `~` to an absolute path before writing shell profile blocks.\n- Quote paths in shell exports.\n- Do not edit any shell profile unless the user opts into persistent shell\n  integration and confirms the profile path.\n- Do not remove an existing matching block for another repo.\n- If replacing a block for the same repo path, replace only the managed block\n  with the same marker.\n- Keep profile edits idempotent: running the skill twice should not append\n  duplicate path entries.\n- Keep the repo-local `env.sh` as the source of the PATH and\n  `IVP_BEHAVIOR_DIRS` details; shell profiles should only source that file.\n\n## Validation Checklist\n\n- Target repo was cloned from the intended template.\n- Template `.git/` was removed before `git init`.\n- `git remote -v` is empty unless the user asked to attach a remote.\n- The resolved local `moos-ivp` checkout was validated.\n- The new repo's build can find the resolved `moos-ivp` checkout, even when the\n  repo is not a sibling of `moos-ivp`.\n- `./build.sh` succeeds, or the exact compiler/configuration blocker is\n  reported.\n- `PATH` and `IVP_BEHAVIOR_DIRS` setup was written to `<repo>/env.sh`.\n- If requested, the selected shell profile sources `<repo>/env.sh`.\n- Generated `bin/` and `lib/` artifacts are not treated as source changes.\n- Final message names the new repo path, env file path, profile path if\n  updated, validation result, and the next appropriate skills.\n\n## Failure Handling\n\n- Missing `MOOS_IVP_ROOT`: stop and ask for the local checkout path.\n- Non-empty target path: stop unless the user explicitly asked to reuse it.\n- Clone failure: report the template URL and Git error.\n- Build failure: report the first actionable CMake or compiler error.\n- Shell profile write failure: leave the repo intact and tell the user to\n  source `<repo>/env.sh` manually.\n- Git commit failure due to identity: leave files initialized and staged state\n  as-is; tell the user to configure Git identity.\n"
}