LC

leehyunbin0131/claude-ros2-skills

Developer tools
20 stars Quality 58 Trend 18Apache-2.0

Claude Code skills for ROS 2 Jazzy — establish the unknowns first, verify against the installed system, prove the result ran.

Overview

Three skills for , targeting : develop packages, verify tests and installed behaviour, and diagnose runtime faults. This repository packages contextual domain guidance, workflows, and executable diagnostics under the Agent Skills standard. Rather than claiming to enhance the intrinsic code generation capabilities of frontier language models, this project explores an engineering hypothesis: While individual tool functionality is validated on test fixtures, Choose your assistant. Automatic skill discovery is supported across environments. For Claude Code, choose either plugin or manual installation. The Codex skill locations are /.agents/skills and ~/.agents/skills for these two scopes. Choose one scope to avoid duplicate skill names. Each installed Codex skill includes the shared verification protocol, loaded when that skill is used. Existing AGENTS.md, CLAUDE.md, Codex configuration and unrelated skills are preserved; local edits stop an update.

README

Three skills for Claude Code and Codex, targeting Ubuntu 24.04 / ROS 2 Jazzy: develop packages, verify tests and installed behaviour, and diagnose runtime faults.

This repository packages contextual domain guidance, workflows, and executable diagnostics under the Agent Skills standard. Rather than claiming to enhance the intrinsic code generation capabilities of frontier language models, this project explores an engineering hypothesis: packaging environment-specific evidence checks and structured handoff records can reduce verification ambiguity and context-transfer overhead between sessions or collaborators. While individual tool functionality is validated on test fixtures, reduced handoff cost and overall developer productivity gains remain unproven.

Quickstart

Choose your assistant. Automatic skill discovery is supported across environments. For Claude Code, choose either plugin or manual installation.

Codex — native skills for an existing project:

git clone https://github.com/Leehyunbin0131/claude-ros2-skills.git
python3 claude-ros2-skills/scripts/install.py --agent codex --project /path/to/your-workspace
# Alternative: install for this user across all projects
# python3 claude-ros2-skills/scripts/install.py --agent codex --user

The Codex skill locations are /.agents/skills and ~/.agents/skills for these two scopes. Choose one scope to avoid duplicate skill names. Each installed Codex skill includes the shared verification protocol, loaded when that skill is used. Existing AGENTS.md, CLAUDE.md, Codex configuration and unrelated skills are preserved; local edits stop an update. Start a new Codex session in the target workspace. To select a skill explicitly in Codex CLI or the IDE, use $ros2-development or $ros2-troubleshooting. In the desktop skill picker, select the same skill by name.

Live ROS checks also need access to the intended ROS graph. In a restricted Codex environment, a denied ROS log directory can be redirected with ROS_LOG_DIR to a writable workspace directory. Discovered topics with no received messages can reflect sandbox/DDS transport constraints. Keep the workspace’s domain and discovery scope; widening discovery to SUBNET is not a general installation fix. Report unavailable observations as inconclusive. See the observed Codex runtime limitations.

Plugin — from a Claude Code session:

/plugin marketplace add Leehyunbin0131/claude-ros2-skills
/plugin install claude-ros2-skills@claude-ros2-skills

Start a new session. A SessionStart hook loads the protocol; plugin-root CLAUDE.md is not automatically loaded on its own. The default user scope applies to all projects. Prefer a project install when you want it limited to a ROS workspace.

Claude Code manual — into an existing project:

git clone https://github.com/Leehyunbin0131/claude-ros2-skills.git
python3 claude-ros2-skills/scripts/install.py --project /path/to/your-workspace
# Alternative: install for this user across all projects
# python3 claude-ros2-skills/scripts/install.py --user

The installer copies the skills and .claude/rules/ros2-verification.md. It preserves existing CLAUDE.md files and unrelated skills, refuses to overwrite local edits, and reports retired skill directories for manual review. Restart Claude Code afterwards. ROS, colcon and robot drivers are not installed by this pack; install the dependencies needed by your workspace. For these checks on an existing Jazzy installation:

sudo apt install python3-colcon-common-extensions python3-pytest \
  ros-jazzy-tf2-ros ros-jazzy-sensor-msgs ros-jazzy-nav-msgs
source /opt/ros/jazzy/setup.bash

Prefer Ubuntu/Jazzy’s test-tool versions or a separately verified environment. The tested Jazzy launch_testing plugin fails to start with pytest 9; our ROS-sourced checks use Ubuntu’s pytest 7.4.4. A runner crash is not evidence that the implementation’s assertions failed.

Skills

Skill When it helps What it adds
ros2-development Creating or modifying packages, nodes, interfaces, launch/config and tests Dependency-aware builds, installed-artifact verification, a check that rejects empty test runs, and an optional evidence tracking tool for task handoff
ros2-troubleshooting A live publisher, callback, TF, IMU or odometry behaves incorrectly Four executable diagnostics and focused frame, runtime and calibration references
ros2-microros MCU transport, agent, rclc or message memory work Source pointers and troubleshooting guidance; not MCU-validated

Both assistants can select a skill automatically from its description. To request it explicitly, mention its name in your task. Examples:

  • “Use ros2-development to add a service to this existing Jazzy package. Build its consumers, run the relevant tests, and show that the installed node works.”
  • “Use ros2-troubleshooting: /scan publishes, but my node’s callback never fires. Find the incompatible endpoints and verify the correction.”
  • “The robot is level but its IMU is mounted upside down. Check gravity using the declared TF; distinguish a correct mounting transform from a real error.”

Specify hardware versus simulation and the workspace when known. The agent should establish genuinely missing robot geometry or existing publishers before making assumptions about them.

Verification scripts

Scripts ship with their respective skill. In command examples, ROS2_SKILL_DIR is an illustrative variable set by the agent to the directory containing the loaded skill; it does not require user input. They are plain Python files, not ROS packages to invoke with ros2 run.

Script Evidence it checks
ros2-development/scripts/check_test_results.py --packages Check executed, passing cases in fresh colcon reports; use --require-test PACKAGE::test_name for the changed behaviour, since linters alone can otherwise pass
ros2-development/scripts/evidence.py begin / finish / inspect Opt-in workflow: Records caller-declared command metadata and inspects watched file hashes and selected environment values for handoff
ros2-troubleshooting/scripts/check_qos_compat.py --topic /scan Native Jazzy QoS compatibility for discovered publisher/subscriber pairs
ros2-troubleshooting/scripts/check_tf_tree.py --sensors laser_frame,imu_link TF connectivity and mounting RPY for physical comparison; an unusual angle is an advisory
ros2-troubleshooting/scripts/check_imu_gravity.py --topic /imu/data Measured gravity on +Z in --base base_link after declared TF or --assume-aligned; requires ≥2 samples; RMS sample variation >1.5 m/s² (adjustable via --max-variation) or missing TF is inconclusive; neither mode proves physical stillness, and gravity cannot establish yaw
ros2-troubleshooting/scripts/check_odom_direction.py --topic /odom Fresh odometry before and after an externally observed movement; direction only, not distance calibration

Diagnostic exit codes: 0 PASS, 1 FAIL, 2 INCONCLUSIVE or invalid request.

Evidence inspection exit codes: 0 Consistent, 1 Changed, 2 Incomplete.

Missing data, NaN, unavailable IMU fields, insufficient samples (<2), excessive sample variation, unknown QoS, no executed tests and insufficient motion must not become successful verification. The runtime scripts require a sourced Jazzy environment. They do not publish motion commands; the odometry check relies on movement performed outside the script. A check supports only the property it observes; IMU PASS confirms measured +Z gravity in the level base frame after declared TF or an explicit aligned-axis assumption, but cannot prove physical stillness or whole-robot correctness.

The evidence tool strictly separates caller-declared outputs from tool-observed file hashes. It does not execute or re-run user commands, does not guarantee freshness or absence of intermediate changes, and does not claim whole-robot health. See docs/DESIGN.md and references/handoff.md.

How it works

flowchart LR
    A[Development request] --> B[Protocol: verify local facts]
    B --> C[ros2-development: build and test]
    B --> D[ros2-troubleshooting: runtime evidence]
    C --> E[Installed behaviour and observed result]
    D --> E
    E --> F[Correct the defect and repeat the relevant check]

The protocol covers development across packages, Nav2, MoveIt and ros2_control; the focused skills add procedures and tools when those are useful. We do not restore large domain manuals merely to increase the skill count. The ros2-development workflow addresses a concrete gap: a successful test command can report zero tests. In the real package fixture, that command returns 0 while the bundled evidence check returns 2.

Validation and evidence limits

CI checks installation/update preservation, Python and shell code, deterministic verdicts, real Python/CMake and ament test wrappers, synthetic Jazzy pub/sub and TF, and independent acceptance-oracle controls. Commands are in CONTRIBUTING.md.

Real Claude Code Opus 5.5 High sessions completed three targeted workflows under both plugin and manual installation: a namespaced sensor package with installed YAML/launch, meaningful wheel-speed tests, and live IMU/TF diagnosis. Both loading smokes verified protocol delivery and actual bundled-script use. The three baseline sessions also passed: the observed task outcomes were the same. This is one run per method and task, not evidence of a performance gain or equivalent reliability. Follow-up runtime sessions review owned-process cleanup after a focused instruction fix; all attempts and limits are in the release acceptance report.

Codex support is tracked separately in the Codex compatibility report. Its operational evidence covers offline install, discovery, and two project-install workflows with model identity unrecorded; earlier Claude observations are not Codex performance evidence. The Codex installer embeds the protocol on skill activation; it does not install a session-wide hook.

A subsequent interface-migration study tested the frozen 0.1.2 snapshot across three matched variants with Python and C++ consumers using Opus 5.5 High. All six baseline/pack artifacts passed independent clean-build, runtime and regression checks. Verification reports, ambiguous project-rule compliance and process-cleanup limitations are assessed separately. In these runs, pack sessions had higher output token counts and API estimates; lower elapsed wall times were confounded by execution order, prompt caching, and probe backgrounding waits. There is no proven token, total-cost, or speed advantage, and none is claimed. Release 0.2.0 ships opt-in evidence handoff tools alongside targeted IMU fixes; that historical 0.1.2 study does not evaluate the new handoff tool.

Maintenance is reopened only for a concrete supported-scope defect, a required test regression, an observed environment compatibility change, or an explicit user scope expansion; upstream model updates alone are insufficient.

Physical robots, MCU firmware, calibration and full Nav2/MoveIt/Gazebo applications remain unverified. The small interface fixture does not establish general stale-overlay remediation, old/new DDS type interoperability, external C++ library consumption or the benefit of --packages-up-to guidance.

Evals

CAPABILITIES.md preserves historical scores and reconciles them with committed verdicts. Some reported scores cannot be reproduced because transcripts or re-grades are missing; they are not evidence that all domain knowledge is unnecessary. We do not advertise those scores as current results.

New skills should improve a real development task. Reproducible failure fixtures support tool correctness; before claiming an agent performance gain, compare matched tasks with and without the change. See authoring criteria and the evaluation method.

Updating

For a plugin installation:

claude plugin update claude-ros2-skills@claude-ros2-skills

For a manual installation, pull the repository and rerun the same installer command. Local edits are preserved by refusing the update until you review the conflict. Include --agent codex when updating Codex. Start a new session in the corresponding assistant afterwards.

Contributing

See CONTRIBUTING.md. Correctness fixes, useful development workflows and reproducible counterexamples are welcome. Keep historical transcripts intact and distinguish observed results from hypotheses.

License

Apache-2.0.

View the full README on GitHub

Recommended Tools

Try a different keyword or remove a filter.

Install

npx skillfish add leehyunbin0131/claude-ros2-skills
New to MCP? Start with the mcpskill.org guide →