Installs into .claude/skills of the current project.
Are you the author of Customization And Analysis?
Add the live security badge to your README. It updates with every re-scan.
[](https://www.skillsdirectory.com/skills/vectorspacelab-customization-and-analysis)
---
name: customization-and-analysis
description: "Extend OpenCDA localization, perception, behavior, and control
modules while preserving runtime contracts, and analyze KF/EKF output with
safe diagnostics."
disable-model-invocation: true
metadata:
disco-role: operating
license: NOASSERTION
---
# Customization and Analysis
Use this sub-skill when an OpenCDA module must be subclassed or replaced, or
when localization filters and their debug output need to be inspected. Keep
custom modules under the package's public `opencda/customize/...` convention
where possible, preserve the contracts in [references/extension-contracts.md](references/extension-contracts.md),
and wire the replacement explicitly; localization, perception, and behavior
are not discovered from YAML by the stock `VehicleManager`.
## Route the work
1. Identify one seam: `LocalizationManager`, `PerceptionManager`,
`BehaviorAgent`, or the controller object selected by `ControlManager`.
2. Read [references/extension-contracts.md](references/extension-contracts.md)
before changing a signature or an object shape.
3. For a KF/EKF change or numerical investigation, use
[filter-and-debugging.md](filter-and-debugging.md). Prefer a bounded,
non-interactive diagnostic over starting a simulator.
4. If an import, YAML selection, or plotting operation fails, follow
[references/troubleshooting.md](references/troubleshooting.md).
5. Validate with the native KF/EKF and debug-helper tests when available, then
run a synthetic seam check that exercises the changed input/output contract.
Do not claim live-simulation validation unless a CARLA server was actually
available.
## Non-negotiable limits
The inspected environment proved Python 3.8, OpenCDA 0.1.3 imports, the CARLA
0.9.12 client import, numerical/plotting dependencies, and core manager imports.
It did not prove a live CARLA server, SUMO, ScenarioRunner, torch, or YOLOv5.
Sensor spawning, ML perception, and co-simulation therefore remain external
backend gates rather than local guarantees. Keep diagnostics headless and do
not require those backends for filter-only checks.