本文へ移動
cccskills
無料GitHub で公開

audit-carla-docs

Finds undocumented and rotting documentation in a CARLA checkout — unreleased features, Python bindings missing from the API reference, documented API that no longer exists, sensors and catalogue actors missing from their reference pages, broken links, and pages unreachable from the nav. Static only, no build or server. Use when the user asks to "audit the docs", "find undocumented features", "what needs documenting", or is preparing a release or a new default branch.

インストール方法を見る

含まれるファイル(5)

  • SKILL.md5.8 KB
  • references/signals.md12.5 KB
  • scripts/audit_docs.py35.1 KB
  • scripts/check_env.sh1.4 KB
  • scripts/env.sh1.2 KB

SKILL.md(原文)

インストールする前に、エージェントに与えられる指示の中身を確認できます。

Audit CARLA documentation (static)

Reports what the repository documents badly or not at all, as a markdown list a human triages. It only reads files — so it is fast, repeatable and safe, and it is blind to anything that exists only at runtime. The companion runtime audit covers that; this skill will not let you forget it.

Paths. scripts/… and references/… are relative to the directory holding this SKILL.md, not to the user's working directory. Prefix them with its absolute path.

The deliverable is a report, never an edit. Deciding what to document, and writing it, are separate jobs — see document-carla-feature.

Instructions

Progress:
- [ ] Step 1: Check prerequisites (bash scripts/check_env.sh), clear FAILs
- [ ] Step 2: Run the audit, writing the report to a file
- [ ] Step 3: Read the summary table and triage by signal, not top to bottom
- [ ] Step 4: Tell the user a runtime (Tier B) audit is still owed

Step 1: Check prerequisites

bash scripts/check_env.sh

Only two things are hard blockers: no CARLA checkout, and no python3. A missing input file downgrades its signal to skipped rather than failing the run.

Step 2: Run the audit

python3 scripts/audit_docs.py --root "${CARLA_ROOT:?}" --out

Writes Docs/audit_carla_docs.md. Drop --out entirely to print to stdout instead; pass --out <path> to write somewhere else.

--signal <name> narrows the run, repeatable: changelog, binding, stale, catalogue-stale, sensor, catalogue, link, orphan. Narrow when iterating on one area; run them all before a release.

Step 3: Triage

The report opens with a count per signal. Work by signal, not in file order — the five differ enormously in effort per finding, and mixing them wastes time:

signalwhat it meanstypical effort
changelogevery unreleased feature, as a checklisthigh — you check each one by hand
bindingclass or member exposed to Python, absent from the ymlsmedium — edit the .yml, regenerate
staledocumented API that no longer exists in the bindingsmedium — usually a rename or a typo, not a deletion
catalogue-stalea catalogue page names an actor nothing knows aboutsmall — delete the entry and its image
sensorsensor id absent from ref_sensors.mdmedium
cataloguevehicle/walker/prop absent from its catalogue pagemedium
linktarget page or anchor missinglow — usually a one-line fix
orphanpage not in the mkdocs.yml navlow — nav entry, or delete the page

Two cautions the report cannot resolve for you, both in references/signals.md:

  • The changelog section makes no claim about whether anything is documented. It lists every unreleased feature as an unticked checkbox; you decide. Judging coverage automatically was tried and was too generous to trust — see the reference.
  • Docs/python_api.md is generated from PythonAPI/docs/*.yml by PythonAPI/docs/doc_gen.py. Fix a binding finding in the .yml and regenerate. Editing the .md is silently reverted by the next run.

Step 4: Say what this audit could not see

Always close by telling the user a runtime audit is still owed, and why. The script prints this too, but say it in your own summary — it is the single easiest thing to forget, and the gap it leaves is invisible.

A static pass cannot see the blueprint library, the available maps, or per-blueprint attributes: new vehicles, walkers and props are content, so they appear in no source diff.

Examples

Example 1: preparing a branch for release

User says: "audit the docs before we make ue58-dev the default"

bash scripts/check_env.sh
python3 scripts/audit_docs.py --root "${CARLA_ROOT:?}" --out

Result: Docs/audit_carla_docs.md with a count per signal. Report the totals, name the two or three heaviest items, and state that a runtime audit is still owed.

Example 2: checking one area while fixing it

User says: "are there still broken links in the docs?"

python3 scripts/audit_docs.py --root "${CARLA_ROOT:?}" --signal link

Result: the link findings on stdout. No file is written; nothing is changed.

Troubleshooting

Error: not a carla checkout (no CHANGELOG.md): <path> Cause: --root or CARLA_ROOT points somewhere else. Solution: pass --root /path/to/carla, or export CARLA_ROOT= before sourcing.

A signal reports 0 findings and you expected some Cause: its input is missing, so it was skipped — check_env.sh prints a WARN per missing input. Solution: re-read the check_env.sh output; a skipped signal is not a clean one.

link findings inside fenced code or HTML comments Cause: none — the audit strips both before scanning. A link reported as broken is in live prose.

Outputs

  • Docs/audit_carla_docs.md (or stdout) — findings grouped by signal, with a count table and the runtime-audit warning. The audit excludes this file from its own link and orphan signals.

レビュー

まだレビューはありません。使ってみた感想をお寄せください。

同じリポジトリのスキル

概要と使いどころ

Adds a new ROS 2 message type to CARLA's native ROS 2 interface — the hand-written POD struct under LibCarla/source/carla/ros2/types/msg, its Fast-CDR serialize/deserialize pair, the RIHS01 type hash computed in Docker, the CdrTopicInfo registration and the type-hash test. Use when the user asks to "add a ROS message type", "support sensor_msgs/X in CARLA", "add a carla_msgs type", "why is my type hash warning appearing", or needs a message CARLA does not publish yet. There is no IDL codegen — every step is manual.

日本語の概要は準備中です。原文の説明を表示しています。

carla-simulator/carla1.4万2026年10月14日 更新

Adds a new topic to CARLA's native ROS 2 interface — a publisher (BasePublisher + PublisherImpl, topic suffix, QoS, registration in ROS2::GetOrCreateSensor, a ProcessDataFrom* entry point and its call site in the UE4 plugin) or a subscriber that lets ROS drive an actor. Also covers adding a middleware (RMW) behind IPublisherMiddleware. Use when the user asks to "publish X to ROS from CARLA", "add a ROS topic/publisher/subscriber", "make the obstacle/lane-invasion sensor publish", "add odometry to ROS", or "add another RMW".

日本語の概要は準備中です。原文の説明を表示しています。

carla-simulator/carla1.4万2026年10月14日 更新

Reads and summarises ScenarioRunner output — the criteria pass/fail tables from --output/--file, the machine-readable --json and --junit result files, and the criteria JSON written alongside a --record recording — and runs the metrics module (metrics_manager.py) to compute custom measurements over a recorded run offline, without the simulator. Use when the user asks "did the scenario pass", "why did it fail", "summarise these results", "compare these runs", or wants distance/speed/lane metrics from a recording.

日本語の概要は準備中です。原文の説明を表示しています。

carla-simulator/carla1.4万2026年10月14日 更新

Gets actor and level 3D bounding boxes and projects them into a camera image as 2D boxes — the dataset-annotation workflow. Lists box geometry, draws 3D boxes in the world via debug, or captures one camera frame and writes an annotated PNG plus a JSON of 2D boxes for matching actors. Use when the user asks to "get bounding boxes", "draw boxes around the cars", "project boxes onto the camera", or "generate a detection dataset / annotations".

日本語の概要は準備中です。原文の説明を表示しています。

carla-simulator/carla1.4万2026年10月14日 更新

Builds CARLA (branch ue4-dev, Unreal Engine 4.26) from source on Linux end-to-end — UE4 fork, the Carla server (editor C++ modules), the LibCarla Python client wheel, and content — then verifies them against a from-source server. Optionally builds the native ROS 2 interface in (ROS2=1 → --ros2, Fast-DDS/CycloneDDS/Zenoh), which is compile-time only and cannot be enabled later. Use when the user asks to "build CARLA from source", "compile CARLA ue4-dev", "set up CARLA on Ubuntu (incl. 24.04)", "build CARLA with ROS2 support", or "produce a CARLA server + client wheel". Cooking a distributable Dist/ package is a separate skill (package-carla-ue4); running the build is run-carla-server.

日本語の概要は準備中です。原文の説明を表示しています。

carla-simulator/carla1.4万2026年10月14日 更新

Builds CARLA on Unreal Engine 5.8 from the ue58-dev branch using its CMake build system — configure a preset, then build the carla-unreal / carla-unreal-editor / carla-python-api-install / launch targets — with ROS 2, DLSS, RSS and cook-scope options, and the engine-side build of the CarlaUnreal UE 5.8 fork. There is no Makefile and no Util/BuildTools in this tree, so every UE4 `make` recipe is invalid here. Use when the user asks to "build CARLA UE5", "build ue58-dev", "compile CARLA with cmake", "rebuild the Python API", or hits a CMake configure or target failure.

日本語の概要は準備中です。原文の説明を表示しています。

carla-simulator/carla1.4万2026年10月14日 更新

carla-simulator のスキルをすべて見る

このスキルの問題を報告する