My Claude Code agent kept writing plausible-looking ROS 2 code that just didn't run — built skills that force it to verify against docs/hardware first

Ran into this enough times to build something for it: Claude (or any LLM coding agent) writes ROS 2 code that looks completely reasonable — compiles, follows conventions — but is wrong in ways that don't show up until runtime. Two recurring patterns:

• Wrong ground truth: TF declared with a flipped sensor orientation, everything downstream computes "correctly" from the wrong transform, nothing ever contradicts itself in logs.
• Wrong era: agent mixes Humble-era API names into Jazzy code because that's what's in its training data. Method sounds right, was renamed or never existed.

So I built a set of Claude Code skills for ROS 2 Jazzy that route to official docs and verified symbol names instead of baking API knowledge into the skill files: https://github.com/Leehyunbin0131/claude-ros2-skills

Covers rclcpp/rclpy, Nav2, Gazebo Harmonic, ros2_control, MoveIt 2, perception, testing, micro-ROS, SROS2.

The part I think is actually useful: a troubleshooting skill + scripts that check physical ground truth instead of trusting logs — IMU gravity direction, odometry displacement when you push the robot, TF mount angles, DDS QoS compatibility between pub/sub pairs.

I ran a small measured comparison (disclosed: self-graded, n=1, not a rigorous benchmark, but every artifact is committed for anyone to re-check) — same Nav2 MPPI prompt with and without the skills:

• haiku, no skills: ~21 invented/wrong parameters, wrong plugin namespace → Nav2 fails to start
• haiku, with skills: 0 — matched the pinned Jazzy nav2_bringup defaults

Full writeup: https://github.com/Leehyunbin0131/claude-ros2-skills/blob/main/evals/RESULTS.md

Genuinely looking for people to poke holes in this — especially anyone who can re-run the eval independently or tell me where the troubleshooting skill is wrong.