new-node
The `new-node` command scaffolds a new ROS 2 node into an existing package with support for standard, lifecycle, or component node types in Python or C++. Use this when adding functionality to a ROS 2 workspace to automatically generate the node class, entry points, configuration files, launch fragments, and smoke tests while enforcing Clean Architecture separation between infrastructure, application, and domain layers.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/harunkurtdev/ros2-claude-code-template/HEAD/.claude/commands/new-node.md -o ~/.claude/commands/new-node.mdnew-node.md
Add a new ROS 2 node to an existing package.
Argument handling (`$ARGUMENTS`):
1. `<package>` — existing package under `src/` (required).
2. `<node_name>` — `snake_case` for Python files / `CamelCase` for C++ class.
3. `<kind>` — one of `standard`, `lifecycle`, `component`.
4. `<lang>` — `python` or `cpp`.
If anything is missing, ask the user before scaffolding.
Process:
1. Verify the package exists and matches the requested language
(look at the build type in `package.xml`).
2. Read the relevant skill:
* `ros2_node_creation` for `standard`.
* `ros2_lifecycle` for `lifecycle`.
3. Place files following Clean Architecture:
* **Infrastructure** layer hosts the ROS 2 adapter (the actual Node).
* **Application** layer hosts the use-case the node orchestrates.
* **Domain** stays ROS-free.
4. Wire entry points:
* Python: `setup.py` `entry_points={'console_scripts': [...]}` and
`setup.cfg` if needed.
* C++: add the executable / component target to `CMakeLists.txt`
with `rclcpp_components_register_nodes(...)` for component nodes.
5. Add a parameters YAML stub at `config/<node_name>.yaml` and a minimal
launch fragment at `launch/<node_name>.launch.py` that loads it.
6. Add a smoke test (`test/test_<node_name>.py` or
`test/<NodeName>_test.cpp`) that just constructs the node and shuts
it down — guards against import errors.
7. `pre-commit run --files <touched files>`.
8. Print: files created, the launch command to try it
(`ros2 launch <package> <node_name>.launch.py`).
Never just dump a Node subclass into `__main__` — it must follow the
Clean Architecture layout enforced by `.claude/rules/clean_architecture.md`.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.