Scenario Agent Skills

The public skills library of Scenario, a generative-media company: 122 skills that teach a coding agent how to produce images, video, audio, textures, skyboxes, 3D assets and custom-trained models through the company’s MCP server, installed with npx skills add scenario-labs/skills. Sixty-five are core skills, one directory and one SKILL.md each, organized around a hub skill that teaches the generation loop — discover a capability, read the schema, run the job, wait, display, download. The other fifty-seven are expert tools: five families of a lead plus specialists that drive applications installed on the user’s own machine, ZBrush, Blender, Maya, Unreal Engine and Unity. Both tiers answer to a written authoring contract — a 1,000-word body target with a hard 2,500-word cap, a fixed shape, frontmatter limited to name, description and license, and a test suite for every script a skill ships. Continuous integration and a pre-commit hook enforce the mechanical half; a clean-room agent that never sees the repository, and whose tool-call plan is graded against the live tool reference, is the bar for merging. It is MIT-licensed, was created on 2026-08-12, and carries 794 stars.

Who built itA repository owned by Scenario Labs, the company behind Scenario. Hervé Nivon wrote 129 of its 148 commits; a release bot accounts for fourteen, and Emmanuel de Maistre, one other Scenario account and a fifth account share the remaining five. One hundred and forty-six of the 148 commits carry at least one co-author trailer, and the census is 126 naming a Claude model, four Codex, one Cursor, fourteen the release bot and one a human colleague — because the repository’s own guide prescribes how the model is named.

1. 01

   A hundred and twenty-two skills in seven weeks

   The repository was created on 2026-08-12 and last pushed to on 2026-09-30. In that window it took 148 commits, eighty-five of them in August after the twelfth and sixty-three in September, and grew to 968 files. Of the 128 SKILL.md files in the tree, 122 are published: 65 core skills sitting one directory each under skills/, and 57 expert tools in five families, split by the pull request that ported them into ZBrush 9, Blender 13, Maya 11, Unreal Engine 10 and Unity 14. The other six are two Anthropic skills vendored for agents working on the repository itself, and four maintainer commands. Releases are how a change reaches a user, because an install always fetches the latest copy from main and nothing is version-pinned: fourteen releases, from skills-v0.37.3 on 2026-08-28 to skills-v0.48.0 on 2026-09-26, roughly one every two days. The changelog they generate holds 47 entries — 29 features, 17 bug fixes and one documentation change — while version.txt reads 0.48.0 and a release pull request for 0.48.1 was still open on 2026-09-28. Around the code sit 794 stars, 93 forks and fourteen open issues.

2. 02

   Who, or what, wrote it

   Five accounts appear in the history. Hervé Nivon wrote 129 of the 148 commits, 128 of them from an address at scenario.com; a release bot accounts for fourteen; Emmanuel de Maistre and one other Scenario account for two each; and a fifth account for one. What makes this history worth reading is the trailers. 146 of the 148 commits carry at least one co-author line, and the census is 126 naming a Claude model — thirty-eight of them the bare word “Claude”, thirty-eight “Claude Fable 5”, twenty-five “Claude Fable 5.1”, and the rest Opus and Sonnet variants — plus four Codex, one Cursor, fourteen the release bot and one a human colleague. That is written policy rather than habit. The repository’s agent guide has a section titled “Codex commit attribution” which prescribes the trailer down to its fields, model, reasoning effort and speed tier, tells the author to use the settings of the contributing session rather than repository defaults, to omit an unknown field instead of guessing, and to carry the trailers into the final squash message so attribution survives the squash workflow. A separate rule makes the same point from the other end: only feat, fix, docs, perf and revert commits reach a release, so a change to shipped skill content must be typed as one of them or it waits for someone else’s release to publish it.

3. 03

   A contract, twelve scripts and a nine-step gate

   The repository is organized by a document. AGENTS.md runs to 37,286 characters of authoring contract: frontmatter limited to name, description and license; a name that must equal the directory name; a description in the third person that starts with “Use when”, describes triggering conditions only and stays under 500 characters; a body of 1,000 words as the target with a hard 2,500-word cap; and a fixed shape of Overview, Quick reference, one worked example and Common mistakes. A supporting file may sit beside a SKILL.md only when its content is too large to inline, and must be linked directly from it, because a reference chained through another file may never be read. A script a skill ships lives inside the skill directory, but its test suite lives at the repository root in tests/<name>/, one directory per skill that ships one: fourteen test directories in all. Twelve repository scripts sit around that, and the pre-commit hook runs them in order — sorting the spell-check dictionary, regenerating the plugin manifest, then pnpm validate, which is nine checks: house style and the body budget, formatting, supporting files, groupings, the generated manifest, the README mirror of those groupings, the dictionary, spelling, and the Agent Skills spec validator. The same file records a bug against itself: committing from a git worktree fails the spec check because git exports GIT_DIR into hooks, so validation has to run from a shell without it and the commit be made with --no-verify.

4. 04

   The test that decides whether a skill actually teaches

   Mechanical validation checks a file against a format; a second protocol checks whether the text teaches, and it is the thing the pull request threads argue about. /skills:validate <name> writes a use case, installs the working-tree copy into a clean-room agent with no repository context, hands it only that skill, the core scenario skill that real installs ship alongside it, and one realistic task, then asks for a numbered tool-call plan with exact tool names and argument shapes: planning only, no execution, no browsing, and an instruction to flag uncertainty rather than guess. The plan is graded against the tool reference, fetched fresh rather than recalled. One invented tool name is a fail. A generative model id asserted as a constant is a fail. A plan that reaches for the REST API, the SDK or a command line where an MCP tool exists is a fail. And anything asserted that appears in neither the skill nor the tool reference counts as a guess, even when it happens to be right. A failure is treated as a defect in the text and re-run with a new agent, because a failed agent is contaminated by its own mistake. A new skill also gets a baseline probe with nothing installed, to confirm it earns the context it costs. Runs are pre-registered with a budget, and one in the report was written down as two still runs, twenty-four clip runs and 700 CU.

5. 05

   Rules that were bought with a failure

   The discussions record what did not work. One pull request taught a way to make a prompt depend on a branch of a workflow graph; the independent run produced the right prompt and a workflow job that never left in-progress, because a branch skips only the node wired to its own handle. The rule was withdrawn and replaced with three shapes that were each validated live, plus a conditional expression inside one text transform. Another added a parallax-background lane and failed on live visual acceptance, five model runs and six dry runs in: asking one generation for “the layers” returns a single picture of stacked layers, so the lane now either splits a finished painting or runs one generation per depth plane. A third taught agents to convert HEIC photos before upload; the API release shipped, HEIC stopped being refused, and the paragraph had to be reframed, with the branch reset onto main and force-pushed and the thread keeping both the earlier position and the reason it changed. Elsewhere the record walks a claim back: a matched test showed that capabilities credited to a new comparison skill were already carried by the core skill and the public tool contracts. Two rules read like scars — sweep a delivered video into contact sheets rather than checking one frame per shot, because a defect that fades in mid-shot passed a spot check at 10.5 s on a clip whose artifact appears at 11.0 s — and stop hunting a mechanism after roughly two inconclusive controlled runs.

6. 06

   Fifty-seven skills ported, with the verification notes left in

   The largest single change is the expert tier: fifty-seven skills in five families, ported from Emmanuel de Maistre’s own expert-skill repositories and merged on 2026-09-25 with the credit in the pull request. They were distilled from expert videos, talks and documentation, then graded blind against the same model without them. Each family is a lead skill plus specialists named after a topic, and the specialists import the lead’s scripts, which is why a family installs as one set. The apparatus is uniform and enormous: every one of the fifty-seven ships references/sources.md, and nearly all ship procedures.md, critique.md and expert-notes.md — 57, 53, 52 and 52 files — with gui-paths.md in forty-one, and 148 Python scripts whose largest is a 196,922-character Maya lighting module, a file larger than the 54,000-character README. Each family folder carries a README recording how the family was built and how far it was verified, and the honesty survives the merge: one change deleted the “not yet run inside Maya or the engine” status notes from the module docstrings and the family README while listing, in its own body, the files where the same notes remained, and the Unity family claims every procedure was run live in Unity 6.3.