Scenario's 3D OS: counting the 80 skills and what is in them

mdjsonmcpcopy↗ai

2026-10-31 · 14 min · agent-skills · 3d · blender · mcp

Why read this

Solid· top 85%

Parses all 167 skills, checks the '6 departments, 80 skills' claim against the repo, and tests the audit definitions on five procedural meshes.

• Original analysis
• Concrete numbers to act on
• Open code or weights

·Agents & harnesses·API only·MIT·Practitioner teardown

How this was scored

Is it new?

0 of 3: Repackaging or news of a known thing

Can I trust it?

2 of 3: Measures key facts from files, code or configs

Can I run it?

2 of 3: Open code or weights with real limits

Will I understand it?

1 of 3: Partial mechanism

Can I act on it?

2 of 3: A concrete recipe, numbers or comparison

Will it last?

1 of 3: Relevant for months

Does it affect many?

1 of 3: A specialist community

Only here?

2 of 3: A teardown or measurement few others did

Score 49 of 100, ranked 552 of 666 rated articles. Each question is answered 0–3 by hand, and a 3 is rare. How articles are scored

A post from a Scenario employee, @emmanuel_2m, says: "We just open-sourced an entire 3D studio. Introducing 3D OS by Scenario. It gives your coding agent 6 departments and 80 skills." Below it sits a folder tree: Animation, Art, Modeling, Look Dev and Lighting, Worlds, Pipeline, and a seventh folder called Expert Tools. The repo is behind a "comment 3D" gate, so I went looking and found it without the comment: scenario-labs/skills, MIT, version 0.60.1.

I wanted to know what "80 skills" and "six departments" mean in files. So I cloned it and counted. This is a read-and-count piece, not a benchmark. Labels used below: measured means I computed it from the files; reported means the repo or the post says it and I did not check it; reasoned means my inference.

What I did, and what I could not do

Measured. I cloned commit 7f4b801 (shallow, blobless, 80 MB), and wrote a script that parses every SKILL.md: frontmatter keys, body words, shipped scripts and references, and whether the text mentions model_run, dry_run, Blender or a GPU. I also re-implemented, in about 80 lines of stdlib Python, the topology definitions from the repo's mesh audit script and ran them on five meshes I generated.

Not run. I tried to run the repo's own Python test suites with unittest and the sandbox's permission layer refused to execute downloaded third-party code. I did not work around it. So no script from the repo ran here. I also did not install Blender (disk was nearly full), and I have no Scenario account, so I made no MCP calls. Every price, every model id, every statement about what a generation returns below is reported from the skill text, which itself says "at authoring time".

The count: 80 is the cloud tier

Measured. The repo holds 167 SKILL.md files. 80 sit directly under skills/. 87 sit under skills/dcc/ (Blender 15, Maya 11, ZBrush 9) and skills/game-engines/ (Unity 14, Godot 14, Roblox 14, Unreal 10). The README says the same thing in prose: the expert tools "work differently", driving software on your machine, and need "the application, not the Scenario MCP server".

So "80 skills" is the first tier alone. The tweet's final line, "the expert tools drive Blender, Maya, ZBrush, Unreal, Unity, Godot and Roblox", adds the second. A literal reader of "6 departments and 80 skills" would think 80 skills run the 3D pipeline. In the files, 167 skills exist and most of the 80 have nothing to do with 3D.

Here is what the 80 are. Measured: 72 of the 80 mention model_run in the skill body, and 74 including their references/. That is the Scenario MCP tool that runs a paid generation. 70 mention dry_run, the flag that prices a call without running it. The rest are admin, analytics, workflow authoring and a few local-only tools. Names in the 80 include scenario-ideogram, scenario-kling, scenario-veo, scenario-elevenlabs, scenario-minimax-music, scenario-caption-studio, scenario-ad-variants, scenario-ugc. The 3D members are scenario-3d, scenario-meshy, scenario-rodin, scenario-sparc3d, scenario-3d-worlds, scenario-patina-retexture, scenario-orbit-views, scenario-walkable-room, plus textures, skyboxes and video-to-motion.

The six departments are not in the repository

Measured. I grepped for "department" and "3D OS" across every file. The word "departments" appears only in a few expert reference files, in the ordinary sense ("handoff to other departments: EXR"), and "3D OS" appears nowhere. skills.sh.json, the file that groups skills for the installer, has 23 groupings: "Images", "Game art and 3D", "Video and audio", "Socials", then one grouping per model family and one per expert application. No Animation, no Pipeline.

This is a marketing layer over the repo, which is a normal thing for a launch post. But it matters for a reader who installs "the Pipeline department" and looks for a folder. There is none.

Reasoned. I assigned skills to the six departments myself, from each skill's description. The widget below shows the result. It is one defensible assignment, not the only one.

On my assignment, 17 of the 80 core skills and 42 of the 87 expert skills land in a department. The other 63 core skills (images, video, audio, brand, admin) and 45 expert skills (mostly game-engine gameplay, UI, networking, monetisation, Luau) fall outside all six. The 3D claim is true of roughly a third of the repo.

Two checks on the mapping. Animation and Pipeline are populated almost entirely by the expert tier: Animation has four core skills against nine expert, Pipeline has none from the core tier. That follows from how each tier works. scenario-video-to-motion can rig a character and animate it from a video in the cloud, but retopology, UV baking and export are done by an agent driving Blender or Maya, not by a generation model.

What a skill is here

Measured. All 167 files have exactly three frontmatter keys: name, description, license. name equals the directory name in all 167. The license is MIT in all 167, and the repo's LICENSE file reads "MIT License, Copyright (c) 2026 Scenario Inc." That is a clean answer to a question that is usually messy for skill collections. I read the licence field, not any per-skill vendor notes; a skill that distils a third-party tutorial inherits the question of derived content, which the repo handles by recording sources (the Blender retopology skill ships a sources.md).

This matches the Agent Skills format the README cites, and the same shape as the skills in this repo's own brand-crew/skills/, which also use name and description frontmatter. Differences I can see in the files:

• Licence field. Theirs on every skill; ours omit it.
• Description style. Measured: core descriptions run about 480 characters at the median. They begin "Use when…" and end with a "Keywords:" tail in several cases I read. Ours (new-post, explainer-films) also open with a task and a trigger, in plain prose.
• Size cap. Theirs is enforced. scripts/check-style.sh fails any body over 2,500 words (I read the line; it prints "over the 2500-word hard cap"). Ours has none, and three of ours exceed it: isometric-figures at 5,219 words, math-reels at 4,944, explainer-films at 3,884 (those counts include frontmatter, so they overstate slightly).
• Sibling references. Measured: 166 of 167 bodies contain the same sentence about loading a missing sibling with skill_get (an MCP tool that fetches a skill by name) or asking the user to install it. It is a dependency declaration in prose, since the format has no dependency field.

On Anthropic's skill conventions as I know them (a short, trigger-oriented description, a body that loads when triggered, and extra files read on demand), this repo follows them. Bodies hold the procedure; references/ holds the long material; scripts/ holds code the agent executes instead of reading.

Size: the cap shapes the corpus

Measured. Total body text is 298,631 words. Core skills have a median of 1,212 words (min 598, max 2,496); expert skills a median of 2,275 (min 1,776, max 2,499). The repo's style guide has a 1,000-word target and the 2,500 cap. The core tier mostly honours the target; the expert tier does not (the expert-tools doc says "bodies run near the cap").

53 of the 87 expert skills sit in the top bin, 2,250 to 2,499 words. None exceeds 2,499. That is what a hard cap does to authors: they write to it. It also means the 2,500 figure is not a measure of how much each skill had to say. The extra material lives in references/: the Blender retopology skill has a 2,273-word body and 1,175 lines of reference markdown behind it.

Measured, shipped code. 15 of the 80 core skills ship scripts, 14,193 lines in total. All 87 expert skills do, 224,314 lines. The Blender toolkit alone is about 26,000 lines of Python across 18 bx_*.py files, such as bx_rig.py at 3,120 lines and bx_retopo.py at 2,872. This is where the repo's weight is. If you count what an agent executes rather than what it reads, 94 percent of the shipped lines belong to the expert tier.

What needs what

Measured. Every core skill that generates something needs the Scenario MCP server at mcp.scenario.com, authenticated by OAuth or an API key, and spends Scenario "CU" credits. The root scenario skill says the free plan has an allowance of 50 a day. Reported: the scenario-3d skill quotes one LLM-based 3D member at 1,300 CU at default effort against 45 for a single-image Tripo generator, and warns that a step marked requires_plan_upgrade fails with a 403 only after earlier paid steps ran. I did not verify these numbers; they show the order of magnitude that dry_run is meant to expose.

The expert tier needs the application: Blender 5.2 ("tested on 5.2.1"), Unity 6000.3, and so on. Only one expert skill's body names model_run, so these skills largely work with no Scenario account at all. Measured: 38 of the 87 mention Blender in their text (the Blender family plus cross-references); 27 mention a GPU or CUDA, most of them as render or shader advice rather than a hard requirement.

Reported verification. The family READMEs state how far each tier was checked, and the claims differ:

• Blender: tested on 5.2.1, with a CI workflow that runs a live gate "against planted defects" whenever a Blender script changes.
• Unity: the README says every procedure ran live in Unity 6000.3.21f1 on macOS (Apple Silicon), and lists what it could not run, such as phone installs and store uploads.
• Unreal: the README says outright that the engine "was not installed when these skills were built" and in-engine code paths are unverified until a first live run.

I give that last one full credit. A skill collection that says "not verified inside Unreal" is more useful than one that says nothing. It also means "80 skills" and "87 expert skills" are not the same class of artefact.

Five skills read in depth

The skill-design question is whether the file teaches the model something it would not already know. A model that has read the web knows what retopology is. It does not know what a particular endpoint's parameter is called this month.

1. scenario-rodin (738 words). Reported. Teaches parameter dialects the model cannot guess: image-to-3D takes images as an array even for one still; qualityMeshOption is a single enum string like "18K Quad" fusing topology and budget; the full lane's addons: "HighPack" is a string, the Fast lane's highPack is a boolean; on a quad mesh HighPack multiplies faces about 16 times; Extreme High bills double. The "Common mistakes" list is the useful part. The weakness is built in: the file says "at authoring time" and tells the agent to treat model_schema_get as the contract, so the skill's own advice is to distrust its specifics. Useful, but it decays.

2. scenario-3d (2,496 words). The best of the core tier. The valuable lines are procedural facts a model would have to learn by paying: run recommend for every later step before step 1, because a plan-gated step fails after earlier steps are billed; never dry_run a downstream rig with a placeholder id, because file ids resolve before plan access is checked and the 404 "proves nothing"; request GLB for the LLM-based members, which store a Blender file; the FBX output "embedded only two images". It is also at the cap, and a reader scrolling the table of tools and the worked example will feel the length.

3. scenario-walkable-room (1,436 words plus 1,698 in references). A seven-step recipe adapted from the open-source image-blaster pipeline: describe the photo and list movable objects, erase them to a clean plate, cut out each object, generate a splat world, turn cut-outs into PBR meshes, make impact sounds, then calibrate and assemble a physics viewer. It says steps 1 and 7 are "the agent's own work on downloaded files" and the rest are MCP calls. This is an orchestration skill: the novelty is the ordering and the calibration notes, not any one call. I cannot say whether it works end to end; I did not run it.

4. scenario-blender-retopology (2,273 words, 2,872-line script). The strongest on the "teach what the model doesn't know" test. It converts expert practice into numbers: loops close around eyes, mouth and joints; 3 loops per joint; upper count equals lower count on lids; poles at valence 3 or 5, only where nothing moves; "a crease is 1 loop on it plus 2 hugging it". Claims carry a tutorial timestamp or are tagged "[added]" when they are the author's own. One claim with a number in it: on the sheep, QuadriFlow "gave no rings around eyes or mouth and tore a thin ear". The cost: all of it is reported distillation of video talks, and the page cannot tell you whether an agent following it produces better topology than one without. The repo's claim of a live gate in CI is the only evidence offered, and it tests defects, not taste.

5. scenario-sparc3d (628 words). The thinnest of the five. A parameter table (requestType 1 is bare mesh, 3 textured; resolution strings differ per member; face absent on 2.0), the rule that images slots are positional (front, back, left, right), and a note on long jobs. Two lines earn their place: views are positional, and the numeric enum. The rest the schema already says. I would rather a model read the schema than this file, which is exactly what the file recommends.

Aggregate, measured. The phrase "at authoring time" appears 179 times across 55 of the 80 core skills and zero times in the expert tier. The core tier is a snapshot of a moving catalogue; the expert tier teaches durable practice about software that changes more slowly.

A check on the audit definitions

The expert Blender toolkit's quality gate is bx_audit.py: quad percentage, valence histogram, poles, non-manifold edges, edge-length variation. Its docstring gives reference values from Blender Studio's production retopology: a head with 3,890 faces at 99.9 percent quads; pole density about 2 percent on a head, 5 percent on a body; edge-length coefficient of variation of 0.6 to 0.8 for a hand-planned layout and "~0.2 to 0.35" for a uniform remesh.

The script needs Blender's bmesh and I did not run it. What I could do is re-implement the metrics it defines (interior vertices only, poles being valence 3 and 5-plus) and apply them to meshes with known structure. Measured, on my code:

Three things came out of it. First, the "uniform remesh reads 0.2 to 0.35" claim holds on my cube sphere (0.19) and UV sphere (0.31). Second, the coefficient of variation is a weak detector of hand-planning: I pushed loop density hard toward the corners of the cube sphere and reached only 0.39, well short of the 0.6 to 0.8 the docstring gives for studio work. The docstring says as much ("NOT a quality score"), but an agent reading cv as a signal would be misled by a mesh with the density changes in the wrong place. Third, the pole and valence rules assume quads. A subdivided icosphere, a perfectly good triangle mesh, has 642 interior vertices all of valence 5 or 6 and a pole density of 50 percent. For a game low-poly that ships as triangles, the headline numbers are noise, and a model told to drive them toward the studio values would be solving the wrong problem. The skill's own text says game assets "ship triangles", so the guidance exists, but the audit does not branch on it as far as I read.

What holds, and what is thin

Genuinely useful. The expert tier is real engineering: 224,000 lines of scripts, timestamped sources, a live CI gate for Blender and Godot, and honest "not verified" notes. The Blender retopology and rigging skills encode judgement an agent cannot get from a prompt. The core tier's value is operational: the plan-gate and pricing traps in scenario-3d save money, and the MIT licence on every file removes the usual doubt.

Thin or overstated.

• "80 skills" is the cloud tier, mostly 2D and audio, and it is a thin wrapper over one commercial API. About 72 of 80 are only useful with a Scenario account.
• The six departments are a presentation, not structure. Anyone looking for skills/animation finds nothing.
• Several core skills (sparc3d, rodin, runway, reve) are 600 to 740 words of parameter notes that the live schema duplicates and that go stale. They are the cheapest to write and the first to be wrong.
• Quality is unmeasured end to end. Nothing in the repo compares an agent with these skills against one without. A 224,000-line toolkit and a 2,500-word cap tell you effort went in; neither tells you the output is better.

For your own skills. Two habits here are worth copying. A hard word cap in CI, with long material pushed into references/. And a README that states what was never run. The thing to avoid is the hedge baked into text: when a skill says "at authoring time" 179 times, it is a signal that the right place for that fact is a schema the agent reads live, not a markdown file. For the isometric-figure side of skills, see the Anatomy machine skill, which this site covers; its skill is the one vendored here as isometric-figures.