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

> Satyajit Ghana — Head of Engineering @ Inkers Technology
> canonical: https://ai.thesatyajit.com/articles/scenario-3d-os
> date: 2026-10-31
> tags: agent-skills, 3d, blender, mcp

A post from a Scenario employee, [@emmanuel_2m](https://x.com/emmanuel_2m/status/2116188727579918358), 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`](https://github.com/scenario-labs/skills), MIT, version 0.60.1.

<RepoCard repo="scenario-labs/skills" />

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.

<DepartmentMap />

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](https://agentskills.io) 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").

<SkillStrip />

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:**

<MeshAudit />

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](/articles/anatomy-machine-skill), which this site covers; its skill is the one vendored here as `isometric-figures`.