new-launch
The new-launch command scaffolds a modular ROS 2 launch file in Python or XML format within an existing package, following established configuration patterns. It creates the launch file with declared arguments and parameter loading, generates a stub configuration YAML, updates package metadata for proper installation, and lints all modified files. Use this when adding a new launch entry point to a ROS 2 package that requires composable nodes, parameter management, or lifecycle node orchestration.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/harunkurtdev/ros2-claude-code-template/HEAD/.claude/commands/new-launch.md -o ~/.claude/commands/new-launch.mdnew-launch.md
Add a new launch file to an existing package.
Argument handling (`$ARGUMENTS`):
1. `<package>` — required, must exist under `src/`.
2. `<launch_name>` — without `.launch.py` / `.launch.xml` suffix.
3. `<format>` — optional, defaults to `python`.
Process:
1. Read the `ros2_launch_config` skill end to end.
2. Place the file at `src/<package>/launch/<launch_name>.launch.<ext>`.
3. Use the skill's modular template:
* `LaunchDescription` returned from `generate_launch_description()`.
* Declared `LaunchArgument`s for every tunable parameter.
* `IncludeLaunchDescription` for any sub-launch composition.
* `ParameterFile` / `ParameterValue` rather than inline dicts.
* `LifecycleNode` instead of `Node` if the underlying node is
lifecycle-managed.
4. Add a stub parameter YAML at `config/<launch_name>.yaml` and load
it via the launch arg.
5. Update `setup.py` / `CMakeLists.txt` so `launch/` and `config/` are
installed.
6. Update `package.xml` `<exec_depend>` to include every package the
launch references.
7. `pre-commit run --files <touched files>`.
8. Print: files created and the test command
(`ros2 launch <package> <launch_name>.launch.<ext>`).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.