gz-new-system
The gz-new-system command scaffolds a complete Gazebo system plugin by creating a header file, source file, CMake configuration, and integration test stub in the appropriate directory structure. Use this command when starting a new system plugin for gz-sim to avoid manual boilerplate setup and ensure consistent project organization across your ROS 2 workspace.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/harunkurtdev/ros2-claude-code-template/HEAD/.claude/commands/gz-new-system.md -o ~/.claude/commands/gz-new-system.mdgz-new-system.md
You're scaffolding a new system in `gz-sim`. Arguments: * First token of `$ARGUMENTS` → directory name in `snake_case` (required). * Second token (optional) → class name in `CamelCase`. If missing, derive by converting the snake_case to CamelCase. If `$ARGUMENTS` is empty, ask the user for the names before doing anything. Steps: 1. Read the `new-system` skill end to end. 2. Verify `src/systems/<snake_case_name>/` does not already exist. 3. Create the directory plus `CamelCase.hh`, `CamelCase.cc`, and `CMakeLists.txt` using the templates in the skill. 4. Add `add_subdirectory(<snake_case_name>)` to `src/systems/CMakeLists.txt`, keeping the list alphabetical. 5. Create a stub `test/integration/<snake_case_name>_system.cc` and add the target to `test/integration/CMakeLists.txt`. 6. Run `pre-commit run --files <every file you touched>` and fix anything that comes back. 7. Report the list of new files and the build command the user should run. Do **not** start `cmake --build` yourself unless the user asks — the scaffold should compile, but they may want to inspect first.
Scaffold a Behavior Tree leaf node — plain BehaviorTree.CPP (SyncActionNode / StatefulActionNode / ConditionNode) or a BehaviorTree.ROS2 wrapper (RosActionNode / RosServiceNode / RosTopicPubNode / RosTopicSubNode) — with ports, factory/plugin registration, and XML v4 usage. Trigger when the user asks to write a behavior-tree node (not Nav 2-specific).
Use proactively before opening a PR that adds or changes BehaviorTree.CPP nodes or BehaviorTree.ROS2 wrappers (RosActionNode/RosServiceNode/RosTopicPub/SubNode, TreeExecutionServer). Reviews a diff against BT.CPP v4 conventions — node base-class choice, non-blocking ticks, ports/blackboard typing, factory/plugin registration, XML v4, and the ROS 2 wrapper contract. Returns a punch list with file:line anchors, not a rewrite.
Build the colcon workspace (optionally a single package) and report the outcome.
Use when a design decision touches Clean Architecture boundaries in a ROS 2 project — which layer a new behaviour belongs to, whether a port belongs in domain or application, whether a new node should be lifecycle-managed, whether to compose nodes or split packages. Returns an architectural recommendation with trade-offs, not implementation.
Author a new skill under .claude/skills/<name>/SKILL.md with valid frontmatter, following the template conventions, and index it in CLAUDE.md + README.md.
Use when a design decision touches the gz-sim ECS — where new state should live, which system phase should write it, how to avoid coupling, whether to add a component vs. a member variable, whether a new system should be split or merged with an existing one. Returns an architectural recommendation with trade-offs, not implementation.
Author a new asset for this .claude/ template — a rule, skill, slash command, or sub-agent — following the project's conventions and wiring it into the CLAUDE.md / README.md indexes. Trigger when the user wants to add or extend a command, skill, agent, or rule (make the template itself extensible).
Configure and build gz-sim from source using either CMake/Ninja directly or a colcon workspace. Trigger when the user asks to build, recompile, configure, or set up the gz-sim binary tree.