ROS 2 engineering skills for coding agents: v1.5.0

Projects
,
1

Hi everyone, I’m YuJin Hong, a robotics software developer based in South Korea.

I’ve been building ros2-engineering-skills, a collection of guidance, reference docs, and validation tools that coding agents such as Claude Code and Codex can use when working on ROS 2 projects. It installs as a Claude Code plugin with optional hooks, or as a knowledge-only skill for Codex, Cursor, and Gemini CLI, which read the same reference files without the hooks.

I think generating ROS 2 code is quite different from figuring out whether its QoS settings are appropriate, whether lifecycle transitions are handled properly, and what the test results actually let us claim.

This project gives agents material to consult when reviewing those questions. It covers Nav2, TF, lifecycle, QoS, SROS2, deployment, and hardware testing. It’s organized so the agent can find the references relevant to the task without reading every document each time.

I’ve just released v1.5.0. A lot of the work in this version went into checking details against upstream sources and correcting inaccurate guidance, including SROS2 enclaves and certificate rotation, and quaternion and covariance handling. It also adds a small supervisor for running a launch file and handling SIGINT on POSIX.

I also spent time on how verification results should be interpreted. Passing local tests doesn’t necessarily mean something is ready to run on a real robot, and a user approving a test doesn’t mean the technical conditions for running it have been met. At the same time, I wanted to cut down on cases where editing a few lines of documentation turns into an inspection of the entire ROS environment.

This release passed 1,342 Python tests and container integration checks across Humble, Jazzy, Kilted, Lyrical, and Rolling. These checks validate the repository’s tools and examples. I haven’t yet run a controlled comparison of agent work quality with and without the skill.

Installation instructions are in the README, and the changes are listed in the v1.5.0 release notes.

If you use coding agents for ROS 2 work, I’d really appreciate hearing how this behaves in your projects. Please let me know about incorrect explanations, missing topics, or instructions that make the work more cumbersome. Concrete examples of where it helped, or where it pointed the agent in the wrong direction, would be especially helpful!

2 Likes
ROS News for the Week of September 7th, 2026
5

1. Python launch API fundamentals

ROS 2 uses Python launch files (*.launch.py) as the primary launch mechanism. XML and YAML launch formats exist but lack the full power of Python conditionals and event handling. Always use Python launch files for production systems.

I know a lot of people (including myself) who would disagree. I’d recommend watching @emersonknapp’s ROSCon 2025 talk: Escape Velocity: Smarter, Cleaner ROS 2 Launch Patterns. A more declarative style (vs imperative) is also worth considering, especially for section 2 on that page.

3 Likes
6

Good to see this framed as a verification problem rather than a code generation problem — that matches what we see building agentic workflows. In our experience the reference docs matter far less than whether the agent can check its own output. Two things that made the biggest difference:

  1. Make the checks runnable by the agent itself. If a hook can run colcon build, ros2 doctor, or a small introspection script that dumps actual QoS profiles / lifecycle states, and the raw output goes back into the context, the agent iterates instead of guessing. Written guidance about QoS only starts to pay off once the agent can observe that its chosen durability/reliability actually mismatched the publisher it is talking to.

  2. Prefer decision tables over prose for anything conditional. For QoS, lifecycle transitions, and sensor-vs-control patterns, a compact table (“sensor data → BEST_EFFORT, keep_last, depth N”; “command → RELIABLE, keep_last, depth 1”) gets followed much more consistently than a paragraph of explanation, and it stays stable when the underlying model changes.

One thing I would be curious about: have you tried scoring the skill set on regressions, i.e. a fixed set of ROS 2 tasks where you compare the agent’s diff and CI outcome with and without the skills installed? That is the part most skill collections skip, and it is the only way I have found to tell whether a doc actually changes behaviour or just adds tokens.

2 Likes
7

Haha yeah, I’d reframe that entire section with this introduction:

ROS 2 uses launch files as the primary mechanism to start groups of nodes together.
A Python API exists but should be considered the implementation backend, with most end usage writing XML and YAML launch files.
The Python interface has the ability to write complex logic, but launch should not be complicated, it should in most cases be a simple list of nodes with parameter and remapping inputs.
Never use Python launch files in production systems unless you have a well-justified reason for extra launch complexity.

(and you probably don’t have a good justification)

7 Likes
8

I think that this is a really cool idea especially as agents start to integrate into the ROS ecosystem. I am curious though, how did you get the information for all these skills? If I’m to assume the skills were written by agents, the skills probably lack some of the best practices, as mentioned above. Being able to load this with all of the library best practices in mind, would be pretty sweet.

That being said, you have the experts that have actually created the core code for each of the segmented skills right here on this forum. Is there any interest in community-lead effort to rewrite this in a “more expert” manner, or would a SKILL.md file in each package just be a better way to go? Additionally, you also have all the previous ROSCON talks and therefore presentations to perhaps sculpt this better.

2 Likes
9

Thanks everyone, I really appreciate the feedback.

I’ve been building this project with a lot of help from AI, so I know there are gaps I may not catch on my own. The launch guidance here was a good example. I learned a lot from @christophebedard and @emersonknapp’s comments, and I’ve updated it in v1.6.1 after checking the points against the ROS 2 docs and upstream code.

The comments from einfachai and CursedRock17 also made me realize there is still a lot to improve around verification, evaluation, and how the guidance is sourced and reviewed.

I still have plenty to learn about ROS and engineering practices myself, so working through all of this properly may take some time. I’m also using translation tools when writing in English, so some of my wording may be a little awkward haha.

But this is exactly why I wanted to share the project here. Thanks again for taking the time to look through it and share these suggestions. :slightly_smiling_face:

Discourse only lets me mention two users in a post right now, so I couldn’t tag everyone directly.

1 Like