菜单
Run unit, integration, performance, and benchmark tests for gz-sim, filter by name, and debug a single failing case. Trigger when the user asks to test, rerun a test, debug a flaky test, or check that a change didn't regress something.
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/harunkurtdev/ros2-claude-code-template --skill gz-test命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Author a new asset for this .claude/ template — a rule, skill, slash command, or sub-agent — following the project's conventions and wiring it into the CLAUDE.md / README.md indexes. Trigger when the user wants to add or extend a command, skill, agent, or rule (make the template itself extensible).
Bootstrap a complete ROS 2 colcon workspace from scratch — directory layout, .gitignore, top-level README, this .claude/ config, an interfaces package and a first Clean Architecture package, and a bringup package. Trigger when the user asks to create a new workspace / start a new ROS 2 project from zero.
Scaffold a Behavior Tree leaf node — plain BehaviorTree.CPP (SyncActionNode / StatefulActionNode / ConditionNode) or a BehaviorTree.ROS2 wrapper (RosActionNode / RosServiceNode / RosTopicPubNode / RosTopicSubNode) — with ports, factory/plugin registration, and XML v4 usage. Trigger when the user asks to write a behavior-tree node (not Nav 2-specific).
基于 SOC 职业分类
正在显示 SKILL.md
| name | gz-test |
| description | Run unit, integration, performance, and benchmark tests for gz-sim, filter by name, and debug a single failing case. Trigger when the user asks to test, rerun a test, debug a flaky test, or check that a change didn't regress something. |
gz-sim ships three kinds of tests, all wired through CTest:
| Kind | Source root | Target prefix |
|---|---|---|
| Unit (next to source) | src/**/<Name>_TEST.cc | UNIT_<Name> |
| Integration | test/integration/<name>.cc | INTEGRATION_<name> |
| Performance | test/performance/<name>.cc | PERFORMANCE_<name> |
| Benchmark | test/benchmark/<name>.cc | BENCHMARK_<name> |
| Plugins (helpers) | test/plugins/ | built as test fixtures, not run directly |
ctest --test-dir build --output-on-failure -j"$(nproc)"
CI requires this to be clean before merge.
# only integration tests
ctest --test-dir build -R '^INTEGRATION_' --output-on-failure
# one specific suite
ctest --test-dir build -R '^UNIT_EntityComponentManager$' -V
# exclude slow/flaky ones during local iteration
ctest --test-dir build -E 'PERFORMANCE_|BENCHMARK_'
This is the fastest way to debug a single failing case, because you get full gtest filter / repeat / shuffle flags:
./build/bin/INTEGRATION_diff_drive_system \
--gtest_filter='DiffDriveTest.*' \
--gtest_repeat=10 \
--gtest_shuffle
Most GUI tests need a display. Wrap with xvfb:
xvfb-run -s '-screen 0 1280x1024x24' \
ctest --test-dir build -R '^INTEGRATION_' --output-on-failure
cmake --build build -j$(nproc) --target INTEGRATION_foo../build/bin/INTEGRATION_foo --gtest_filter=Bar.*.-DCMAKE_CXX_FLAGS="-fsanitize=thread").gdb --args ./build/bin/INTEGRATION_foo --gtest_filter=Bar.NameOfCase
test/worlds/ — many integration
tests load a world from there../build/bin/BENCHMARK_each --benchmark_min_time=2 \
--benchmark_out=/tmp/each.json --benchmark_out_format=json
Avoid running benchmarks under load — they're noisy on shared machines.
ctest --test-dir build -R '^PYTHON_'
These exercise the pybind11 bindings.
Tell the user what you ran and which counts came back (e.g. "148 pass / 0 fail / 2 skipped"). Don't claim success without numbers.