sdf
Skill1 starsChanged 3 months agoMITView on GitHub
SDFormat/SDF model and world authoring, validation, and simulator handoff. Use for `.sdf` files, SDFormat XML, models, worlds, links, joints, poses, frames, inertials, visual/collision geometry, mesh URIs, sensors, lights, physics, plugins, includes, Gazebo, static SDF review, or simulator-specific metadata. Do not use for signed-distance-field geometry.
1 other project uses a version of this, 1 of them edited.
Adopted by
Most recently taken up by
- tlinedeep/claude-skillsedited, first seen Jun 3, 2026
Other versions1 project uses a version of this.
Word for word · 0
None found.
Edited · 1
- tlinedeep/claude-skills★ 036% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository32 other files it gives its agents.
- advertising-imagery-agentSkill
- agent-watchSkill
- aria-intelligenceSkill
- bambu-labsSkill
- cadSkill
- cad-viewerSkill
- dataset-engineeringSkill
- design-business-agentSkill
- design-loopSkill
- dxfSkill
- elite-engineeringSkill
- emil-deign-skillSkill
- env-harnessSkill
- gcodeSkill
- human-writingSkill
- implicit-cadSkill
- inference-engineeringSkill
- kernel-engineeringSkill
- lamp-method-first-principles-thinkingSkill
- marketing-and-advertising-agentSkill
- model-evalSkill
- new-project-architectureSkill
- opportunity-hunterSkill
- rlmSkill
- rlSkill
- sendcutsendSkill
- sftSkill
- srdfSkill
- step-partsSkill
- synthesys-bug-triageSkill
- taste-maxSkill
- urdfSkill
The file
Show its rules and text
We split this skill into the rules it gives an agent
15 rules. About 0 are common, 7 are distinctive, and 8 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
This author's own choices. Worth a look.
8
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Distinctive: line 9
Use the installed local skill files as the runtime source of truth.
- Distinctive: line 12
Use this skill when the deliverable is an SDFormat document.
- Distinctive: line 23
Use SI units unless the target explicitly requires otherwise: meters, kilograms, seconds, radians.
- Very specific: line 24
Prefer version="1.12" for new outputs unless the target consumer constrains the version.
- Very specific: line 26
Write relative_to / expressed_in explicitly on every nontrivial pose and axis.
- Distinctive: line 27
Do not infer spatial transforms from visual impression alone.
- Very specific: line 28
When the robot already has a URDF, derive the SDF from it instead of re-authoring geometry.
- Very specific: line 30
After authoring, run available checks: bundled validation, optional gz sdf --check, simulator load, joint motion, and plugin/sensor startup.
- Distinctive: line 35
Use this skill for SDFormat outputs.
- Distinctive: line 44
Read or create the design ledger comment block.
- Very specific: line 45
Read references/frame-semantics.md before editing any <pose>, <frame>, joint axis, relative_to, expressed_in, nested scope, sensor frame, …
- Very specific: line 48
Run target-consumer smoke tests when available (references/smoke-tests.md).
- Very specific: line 54
Run with the project or workspace Python environment.
- Distinctive: line 76
When finishing an SDF task, include a compact report:
- Very specific: line 116
Use python scripts/snapshot --help for the complete current command interface.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
SDF
Provenance: maintained in earthtojake/text-to-cad. Use the installed local skill files as the runtime source of truth; the repository link is only for provenance and release review.
Use this skill when the deliverable is an SDFormat document. SDFormat describes simulator and world behavior: models, worlds, frames, poses, links, joints, inertials, visuals, collisions, sensors, lights, physics, plugins, includes, and simulator metadata.
This skill is for SDFormat, not signed-distance-field geometry.
The .sdf file is the source of truth: author and edit the XML directly. There is no gen_sdf() contract.
Core rules
- Author
.sdfXML directly and validate every created or modified file withscripts/validatebefore reporting completion. - Identify the target consumer before editing: Gazebo/libsdformat version, another simulator, visualization-only tooling, model package, or world handoff.
- Decide document kind: model-level SDF, world-level SDF, or model-in-world. Prefer model-level SDF for reusable robot/object exports.
- Use SI units unless the target explicitly requires otherwise: meters, kilograms, seconds, radians.
- Prefer
version="1.12"for new outputs unless the target consumer constrains the version. - Establish the design ledger before writing poses, frames, joint axes, mesh scales, inertials, sensors, or plugins, and keep it as a comment block at the top of the
.sdf. Usereferences/design-ledger.mdandreferences/llm-guardrails.md. - Write
relative_to/expressed_inexplicitly on every nontrivial pose and axis. Implicit frame defaults are the top SDF failure mode. Seereferences/frame-semantics.md. - Do not infer spatial transforms from visual impression alone. Derive poses, axes, scale, mass, inertia, and frame names from upstream source data, drawings, simulator documentation, measured values, or explicit assumptions. Never freehand computed numbers — use formulas or a throwaway helper script (inertia tensors, unit conversions).
- When the robot already has a URDF, derive the SDF from it instead of re-authoring geometry; see
references/interoperability.md. - Regenerate upstream geometry, mesh, robot-description, render, topology, or package assets with their owning workflows before editing SDF that references them.
- After authoring, run available checks: bundled validation, optional
gz sdf --check, simulator load, joint motion, and plugin/sensor startup. - Report assumptions, skipped checks, unresolved resource paths, and target-specific compatibility risks.
Scope
Use this skill for SDFormat outputs. Do not use it for signed-distance-field modeling, raw geometry generation, planning semantics, or to paper over incorrect upstream robot/source data unless the task is explicitly simulator-only.
CAD Viewer Handoff
After completing SDF work that creates or modifies a .sdf, you must ALWAYS hand the explicit file path to $cad-viewer when that skill is installed. $cad-viewer must start CAD Viewer if it is not already running and return link(s) to the relevant created or updated file(s); if $cad-viewer is unavailable or startup fails, report that instead of silently omitting the handoff.
Workflow
- Locate the target
.sdfand its consumers. - Read or create the design ledger comment block.
- Read
references/frame-semantics.mdbefore editing any<pose>,<frame>, joint axis,relative_to,expressed_in, nested scope, sensor frame, or plugin frame. - Author the XML directly, following the worked examples in
references/examples.md. - Validate the explicit target with
scripts/validate; treat bundled validation as a guardrail, not simulator proof. - Run target-consumer smoke tests when available (
references/smoke-tests.md). - Hand the file to
$cad-viewer. Static rendering does not execute SDF plugins or read file-authored motion metadata. - Report checks run, checks skipped, and assumptions.
Commands
Run with the project or workspace Python environment. Treat python in examples as an interpreter placeholder; if bare python is unavailable, substitute python3, a project virtualenv interpreter, or the configured interpreter path. The validator uses only the Python standard library.
python scripts/validate path/to/model.sdf
python scripts/validate path/to/a.sdf path/to/b.sdf
python scripts/validate path/to/model.sdf --strictThe validator checks document shape, name scopes, pose/frame graphs, joints, geometry, mesh URIs, inertials, sensors, and plugins, and prints per-file findings plus a summary. --strict treats warnings as failures. It exits nonzero if any target fails.
Optional external checking:
python scripts/validate path/to/model.sdf --gz-check auto
python scripts/validate path/to/model.sdf --gz-check required
python scripts/validate path/to/model.sdf --gz-check nevergz sdf --check is optional target-consumer validation. It should be reported as skipped when unavailable unless explicitly required.
Required report shape
When finishing an SDF task, include a compact report:
Validated: path/to/model.sdf
Checks run:
- bundled SDF validation: passed
- gz sdf --check: skipped, gz not installed
- simulator load: skipped, target simulator unavailable
- viewer handoff: `$cad-viewer` link returned
Assumptions:
- Assumed mesh units are meters.
- Assumed lidar frame is coincident with lidar_link.
Risks:
- Camera plugin filename was not verified in the target simulator environment.Snapshot Tool
scripts/snapshot renders the robot to a PNG still or an orbit GIF, using the same shared
CLI and headless browser runtime every rendering skill uses — so a snapshot matches what
the CAD Viewer shows.
python scripts/snapshot --input path/to/robot.sdf --output review.png
python scripts/snapshot --input path/to/robot.sdf --output turntable.gif --mode orbitIt accepts .sdf only. Pose the robot with the job field "jointValues" (joint name to
degrees, defaulting to the rest pose) rather than --params, which is STEP-only; robots
are authored in metres and are framed on the robot scene scale automatically.
Theme settings live under one --theme, mirroring the viewer's Theme tab. The default
theme is snapshot — Workbench Light with the ground grid, origin axis and shadows
removed, because in a still image those read as geometry. There is no --display: display
settings (mode, clip, exploded, edges) are CAD topology settings, and a robot carries none.
Link meshes are resolved relative to the description, so they must be present: an
unhydrated Git LFS pointer fails as "No link mesh loaded for robot". Run
git lfs checkout <mesh dir> first.
Use python scripts/snapshot --help for the complete current command interface.
References
- SDF workflow:
references/sdf-workflow.md - Worked examples (golden skeletons):
references/examples.md - LLM guardrails:
references/llm-guardrails.md - Design ledger:
references/design-ledger.md - Frame semantics:
references/frame-semantics.md - Validation scope:
references/validation.md - Smoke tests:
references/smoke-tests.md - Interoperability notes (URDF-derived SDF, meshes, Gazebo):
references/interoperability.md
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

