When to Use

The user gives a video (YouTube link), an article, a press release or a description of a technology and asks whether it can work, how it works, or what limits it. Also when the user wants a tech demo explained or debunked with animation. One subject per run; a video with several products gets one run per product the user picks.

Not for: pure market or business feasibility (no physics to test), or a figure of a known mechanism with no feasibility question (use anatomy alone).

Procedure

1. Intake.
   • Video: skill_run(name="youtube-analysis", args="<url>"), then read transcript.md to the end and every sheets/*.jpg (the youtube-analysis Procedure step 2). Note timestamps for every claim.
   • Text or a link: read it fully (web_fetch), then search for independent coverage.
   • Research with the web-research habits: two sources for every number that matters, note dates, separate the company's claims from independent measurements. Search for the published specs the source leaves out.
2. Claims. List every testable claim with its number and its source (references/method.md §1). Translate marketing words into the physical requirement they imply.
3. Scaffold. skill_run(name="engineering-feasibility", args="scaffold reports/feasibility/<slug>"). It finds the installed anatomy skill, makes kit/ shims to it and copies the template (model.mjs, fig1.mjs, fig1.live.js, page.mjs, helpers.mjs, feasibility.json). Add --example roadster to start from the complete worked example (five figures, two of them 3D) instead.
4. Model and verdict. Write model.mjs (one pure function per claim returning required, limit, margin) and fill feasibility.json. Use skill_run(… args="calc list") and calc <name> key=value for tanks (real gas), nozzles, rockets, ballistics, landings, suction, vessels and batteries; references/physics-checklist.md lists the test and the trap per domain. Classify each claim and the whole (references/method.md §4–5): run the favourable case before calling anything impossible.
5. Tell the user the verdict first (a short message with the deciding numbers), then size the animation with anatomy's tiers: a Figure or a Hero you build; an Epic (a whole vehicle, several systems, 3D on more than one subject) needs the user's yes, unless they already asked for it or the run is unattended.
6. Figures. Pick them from the claims with references/figure-patterns.md: mechanism figures when feasible, limit and failure figures for every impossible core claim. Build each with the anatomy skill's workflow (read its SKILL.md first): real object, parts list, recorder + A.settle + --audit to zero, scripts/lines.mjs, 3D figures with T.build and the orbit audit (--quick in the background first). Every readout and every motion comes from model.mjs.
7. Page. Add each figure to page.mjs (one .rr-figure section and one { … } live block each), the verdict tiles and the limits ledger come from feasibility.json. node page.mjs and node page.mjs --dark; capture desktop and 390 px in both themes with anatomy's scripts/capture.mjs and look at every shot.
8. Report. Write report.md from references/report-template.md, linking the page.
9. Check. skill_run(name="engineering-feasibility", args="check reports/feasibility/<slug>"); fix every problem and run it again until status: ok.
10. Deliver. Publish page.html where the host allows (an artifact or the document viewer), then reply with the verdict in one sentence, 3–6 deciding numbers, the page and the report. State the assumptions that could change the verdict.

Rules

• Numbers decide. No verdict without required vs limit for each core claim; no figure value that is not computed by model.mjs.
• Separate what the source claims, what is independently reported, and what you assumed. Label assumptions on the page and in the report.
• Be fair to the claim: test its most favourable reasonable reading before calling it impossible, and the conservative reading before calling it fine.
• Say "limited" with the envelope (how long, how many times, on what surface) rather than a bare yes.
• The animation explains, it does not decorate: each figure answers one claim or one limit.
• Never modify the installed anatomy skill; work in the scaffolded folder through kit/ shims.
• Use skill_run for this skill's scripts; anatomy's build and check scripts run with shell (node …).

Gotchas

Read references/gotchas.md before building; the ones that cost the most:

• Real gas: ideal-gas tank mass at 700 bar is ~50% too high; usable gas can be half of the stored gas.
• Body-fixed thrusters rotate with the body; landings need a braking burn in the propellant budget.
• glLayer turns an array of length 2–4 into a vec2–vec4: declare vec4, not float[4].
• In 3D, objects a free group flies over must be world parts in the same live layer.
• Headless captures of shader pages are slow; use a time hash hook and long waits.

Verification

check returns status: ok (SinoBee also runs it by itself before the task may finish, once report.md is written, and sends every problem back to fix); every anatomy figure's --audit ends audit passed (3D: turn audit with no separation, cycles, posed or layers problems; remaining swaps/continuity inspected at the named angle and reported); the page has no console errors and no sideways scroll at 390 px in light and dark; every number in the report appears in feasibility.json or the page and traces to model.mjs.

Example

assets/example-roadster/ is a complete run: Tesla Roadster Rocket (cold-gas thrusters, 2 g suction, 600 L at 690 bar). Verdict limited: 151 kg of 313 kg usable, 4.3 s hover, 84 kg per jump-and-flip. Figures: a thrust stand with a WebGL jet (shock diamonds, separation, condensation), a COPV skid draining on its dials, a 3D tilt rig from floor to ceiling, a 3D free-body jump with a 360° roll over five vehicles, and a limits panel.