new-vda5050-connector
Scaffold a Clean-Architecture VDA 5050 v3.0.0 connector (MQTT/JSON ↔ Nav 2) — domain entities, ports, application handlers, MQTT + Nav 2 adapters — in the chosen code format.
mkdir -p ~/.claude/commands && curl -fsSL https://raw.githubusercontent.com/harunkurtdev/ros2-claude-code-template/HEAD/.claude/commands/new-vda5050-connector.md -o ~/.claude/commands/new-vda5050-connector.mdnew-vda5050-connector.md
Scaffold a VDA 5050 connector / fleet bridge package.
Argument handling (`$ARGUMENTS`):
1. `<package>` — new package name (required), created under `src/`.
2. `[lang]` — `python` (pydantic idiom) or `cpp` (struct + nlohmann
idiom). Default `python`.
3. `[side]` — `robot` (AGV side, default) or `fleet` (master control).
If anything is missing, ask before scaffolding.
Process:
1. Read the skill `vda5050_integration`, the format guide
`vda5050_implementation_formats.md`, and the spec
`vda5050_messages.md`. Pick the matching reference impl to mirror:
* python + fleet → `~/nav2_ws/src/isaac_mission_dispatch`
* python/cpp + robot (ROS 2) → `~/nav2_ws/src/isaac_ros_cloud_control`
and the template's `~/nav2_ws/src/vda5050_connector`
* cpp core → `~/nav2_ws/src/vda5050_core`
2. Scaffold the Clean Architecture layout (see `clean_architecture.md`):
* **domain/entities** — message models for `order`, `state`,
`action`, `connection`, `factsheet` (pydantic camelCase, or C++
struct + snake_case). **No MQTT / no `rclpy` / no `*_msgs`.**
* **domain/interfaces** — ports: `MqttClientInterface`,
`NavigationAdapterInterface`.
* **application** — `OrderHandler` (graph traversal, base/horizon,
stitching), `StateAssembler`, `InstantActionHandler` (actionStatus
state machine).
* **infrastructure** — `MqttBridge` (paho / PahoMqttCpp; topic
`vda5050/v3/<mfr>/<serial>/<topic>`, QoS 0 except `connection` QoS 1
+ `CONNECTION_BROKEN` last will; JSON validated against
`~/nav2_ws/src/VDA5050/json_schemas/`), `Nav2Adapter`
(order→`NavigateThroughPoses`, telemetry from `/amcl_pose`,`/odom`,
`/battery_state`), composition-root node.
3. Use **v3.0.0 enum spellings** (`CONNECTION_BROKEN`, `TEACH_IN`,
`SINGLE`, `HIBERNATING`, `RETRIABLE`) — not the v2 spellings in the
reference repos (see the v2→v3 table in
`vda5050_implementation_formats.md`). `version = "3.0.0"`.
4. Wire build files (`setup.py`/`package.xml` for Python;
`CMakeLists.txt`/`package.xml` for C++) and a launch + params file.
5. Add tests: domain entities + handlers without ROS/broker; one
round-trip (order JSON → Nav 2 goal; telemetry → state JSON validated
against the schema).
6. `pre-commit run --files <touched files>`.
7. Print: files created, the layer map, and how to run it against a local
MQTT broker.
Keep the protocol out of the domain (it is an infrastructure concern),
never mutate a released base, and increment `headerId` per topic.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.
Build the colcon workspace (optionally a single package) and report the outcome.