build
The build slash command compiles a ROS 2 workspace using colcon, supporting full workspace builds or single-package builds with optional arguments. Use it during development to compile your workspace from its root directory, with automatic symlink installation, RelWithDebInfo build type for CMake packages, and detailed error reporting on build failures.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/harunkurtdev/ros2-claude-code-template/HEAD/.claude/commands/build.md -o ~/.claude/commands/build.mdbuild.md
Build the current ROS 2 workspace from its root (the directory that contains `src/`, `install/`, `build/`, `log/` — if you are in a package subdir, `cd` up until you find that root). Argument handling (`$ARGUMENTS`): * If empty: `colcon build --symlink-install --event-handlers console_cohesion+` * If the first token does **not** start with `-`, treat it as a package name: `colcon build --symlink-install --packages-up-to <pkg> $REST` * If the first token starts with `-`, pass everything through verbatim. Always: * Use `--symlink-install` unless the user passes `--no-symlink`. * Use `RelWithDebInfo` for CMake packages unless overridden: `--cmake-args ' -DCMAKE_BUILD_TYPE=RelWithDebInfo'`. * On failure, show the last ~40 lines of the failing package's `log/latest_build/<pkg>/stderr.log` so the user can see the real error. * On success, remind the user to source the overlay: `source install/setup.bash`. Do **not** wipe `build/`, `install/`, `log/` automatically. If a configure-time problem looks stale, ask whether to clean first.
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.
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.
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.
Use proactively before opening any gz-sim PR. Reviews a diff against the project's C++17 style, ECS conventions, plugin registration patterns, CMake structure, test placement, Migration.md / Changelog.md expectations, and pre-commit configuration. Returns a punch list, not a rewrite.
Use proactively before opening a PR that adds or changes a ros2_control controller, broadcaster, or hardware component (incl. URDF <ros2_control> bringup). Reviews a diff against ros2_controllers / ros2_control_demos conventions — controller & hardware lifecycle, command/state interface configuration, real-time safety of update()/read()/write(), generate_parameter_library usage, pluginlib registration, chainable-controller correctness, URDF wiring, and tests. Returns a punch list with file:line anchors, not a rewrite.
Use proactively before opening any ROS 2 / Nav 2 PR. Reviews a diff against this template's Clean Architecture, ROS 2 communication, lifecycle, testing, and Nav 2 plugin conventions. Returns a punch list with file:line anchors, not a rewrite.
Use proactively before opening a PR that touches a VDA 5050 connector / fleet bridge. Reviews a diff against VDA 5050 v3.0.0 protocol compliance (topics, QoS, header rules, base/horizon, action state machine, schema validation) and the template's Clean Architecture for the MQTT↔Nav 2 bridge. Returns a punch list with file:line anchors, not a rewrite.
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.