Why teardown Is a Model Skill: Verified by Running It
機械翻訳 / Machine-translated
機械翻訳 / Machine-translated
Original article: Why teardown Is a Model Skill: Verified by Running It (cccskills)
Skill page: teardown
Key takeaways from this article
teardown is a skill that assembles a 3D simulator of a real machine — one that can be taken apart — into a single HTML file, and exports video and audio as well.
At cccskills, it was chosen as the first entry in the "Recommended" list as a model for how to write a skill.
This article gives three reasons why it qualifies as a model, and reports the results of running it locally and putting it through the standard runtime verification.
teardown is a skill that builds a "disassemblable 3D simulator" of a real machine into a single HTML file.
Engines, aircraft landing gear, walking mechanisms, and more can be operated by opening parts one at a time or viewing them in cross-section using buttons.
The surrounding gauges and graphs draw their numbers from the same calculations that drive the moving parts.
Left untouched, the page guides itself — moving the cursor around to highlight points of interest.
Clicking or dragging transfers control to the viewer, and after 25 seconds of inactivity the auto-guide resumes.
Using the same script, it exports video frame by frame at 60 fps and generates audio aligned to the same timeline.
cccskills selected this skill as the first entry in "cccskills Recommended."
The reason is not its eye-catching visuals, but the quality of how it's written.
Below, we walk through the reasons it qualifies as a model and the results of verifying it locally.
The central rule in teardown is: "Collect real-world measurements first, then drive everything from a single input."
For an engine, the input is crank angle; for aircraft landing gear, it's extension ratio from 0 to 1; for Strandbeest, it's wind speed.
Part orientation, panel readouts, and graphs are all computed as functions of that single input.
This makes it structurally impossible for on-screen numbers to contradict the motion.
Because no keyframes are set by hand, the interactive page, the recorded video, and the audio stay in sync.
SKILL.md even includes worked examples for cross-checking.
In the Cessna example, 32 teeth × module 4 mm gives a pitch circle diameter of 128 mm.
Half the circumference of that circle equals a stroke of 201 mm.
Checking by hand: π × 128 ÷ 2 = 201.06 mm.
The code constants — pinionR: 0.064 (32 teeth, module 4 mm) and stroke: 0.201 — match the documentation.
The Strandbeest example carries all 13 of Theo Jansen's dimensions (a = 38 through m = 15) exactly as published.
Rotating the crank through 720 frames and re-measuring each link length, the maximum deviation was 1e-14.
The vertical travel of the foot tip was 22.5, and the foot spent 155° of crank rotation within 1 unit of the ground — matching the code comment "approximately 155°."
The skill includes three fully realized examples: a V8 engine, the main landing gear of a Cessna 337, and Strandbeest.
All three are written with the same structural breakdown, and the rule is to start any new machine by copying the closest example.
| File | Role |
|---|---|
| kin.js etc. | Computation only. Takes real-world measurements and a single input; outputs orientation and display values. Does not include three.js. |
| engine.js etc. | Geometry. Builds parts in code and sets orientation via update(input). |
| console.js | Overlay of gauges and graphs. Redraws from frame state. |
| film.js | Script and a pure render(t) that draws one frame from time alone. |
| live.js | Interactive page. Left alone, it auto-guides through the script. |
| score.py | Audio aligned to the script's timeline. |
Because computation and rendering are separated, the computation can be cross-checked in Node alone.
render(t) is a pure function that draws one frame from time only — it must not use random numbers or the clock.
Searching the production code, Math.random and Date appear zero times; performance.now appears only in live.js for real-time interaction.
SKILL.md states: "You cannot watch the video.
All you can see is individual frames."
It then prescribes making a sheet of still images at each key moment, checking them against a checklist, fixing issues, and re-shooting.
The stopping condition is: "when a full pass finds nothing."
The checklist is specific.
Items include: are the right parts touchable; is nothing important within 60 px of the edge; is no text smaller than 34 px on a 1080-pixel screen.
It also gives numeric thresholds for cases where three.js visuals break down — emissive below 1.0, roughness at or above 0.45 for large metal surfaces, and so on.
Another strength is that the author has preserved a record of pitfalls they actually encountered.
Five entries — with explanations — include things like: on Windows ANGLE, reversed smoothstep arguments silently return 0; a single NaN pixel causes bloom to black out the entire screen.
We followed the README instructions on a Mac with an Apple M2 Ultra.
One issue arose on the Mac.
The lightweight Chromium that Playwright uses by default cannot create a WebGL context, causing recording to stall after 60 seconds.
Pointing the CHROMIUM environment variable to a full Chromium build resolved this, allowing GPU-accelerated rendering via Metal.
The recording script prints which GPU was used for each shot, so the cause was immediately obvious.
SKILL.md specifies: "All key-moment timestamps go in timeline.json; audio reads from the same file."
However, the timeline.json files for all three machines contained only the total video duration.
The score.py that generates V8 audio hard-codes the script timestamps as CLICKS = (3.5, 6.9, …).
The values currently match, so the audio is not out of sync.
But if the script timestamps change, the audio will be left behind.
Both --stills beats (which captures stills at key moments) and sheet.mjs (used for final review) produced only one frame or zero frames because no key-moment timestamps were present.
For this verification, we extracted the timestamps from the script and specified them directly in order to continue.
Since we are recommending this as a model, we report this gap too.
When incorporating elements into your own skill, verify not only that the rules are stated, but that the examples actually follow them.
cccskills runtime verification has Claude Code solve the same task with and without the skill, then compares results.
The verification environment has only Node.js and Python's standard library — no package installation, no internet access.
three.js, esbuild, Playwright, and ffmpeg, all of which teardown relies on, are unavailable in this environment.
Under these constraints, two tasks were automatically generated:
Both tasks were each run once with and without the skill. Since the solver cannot see the screen, the author opened the resulting pages in a browser and compared them.
The engine task was a draw.
Both produced a piston position of 30.875 mm at 90° (matching hand calculation), and both implemented cross-section view, camera control, and auto-guide.
The with-skill version followed SKILL.md's aesthetic preference of a bright background with one accent color.
The without-skill version was also clean and readable — too close to call.
The difference showed up in the Strandbeest task.
The auto-generated link table had two connections swapped (d and e, h and i).
Building from that table as written, our calculation shows the mechanism fails to close for 264° out of 360°.
The without-skill run kept the swapped connections and searched all combinations by brute force for solvable configurations.
The foot trajectory had no flat bottom, spending only 29° of crank rotation within 1 unit of the ground.
It compensated by loosening the ground-contact threshold to 6 units.
The with-skill run read SKILL.md and the Strandbeest example, then flagged that the foot triangle in the table differed from the original source.
It assembled the linkage using the correct original connections, achieving a 155° ground-contact interval — the same trajectory as the example.
Rule 1 — "build from references, not imagination" — and the existence of the example made the difference.
In short, even inside a sandbox where the tools don't work, the writing principles carried over.
On the other hand, teardown's strengths in the recording and review workflow were not measurable in this verification.
Judging this skill by runtime verification scores alone would miss half of what it offers.
The writing practices in teardown are not limited to mechanical 3D visualizations.
teardown is a skill whose strength lies not in the visual polish of the 3D output, but in the quality of the writing behind it.
It keeps all numbers at a single source, uses examples to establish a pattern, and prescribes procedures for verifying output that cannot be seen directly.
Local verification confirmed that the key numbers and visuals matched the SKILL.md documentation.
The empty timeline.json is a real gap, but the fix is straightforward.
If you write skills, read SKILL.md from start to finish at least once.
This article is a repost of the cccskills article "Why teardown Is a Model Skill: Verified by Running It."
Skill details and installation instructions are available on the teardown page at cccskills.
