agentleFS
LeonxlnxLeonxlnx/cook/SKILL.md

cook

Skill6 starsChanged 11 days agoMITView on GitHub

Runs the Cook Loop for ambitious visual builds that must match reference images, screens or videos through long autonomous iteration. Use it for 3D worlds made in code (three.js, WebGL, shaders), code-rendered films, launch and motion videos, games and polished UI that must hold up next to references, especially runs of many hours or days while the user is away. Trigger when the user types /cook or $cook, says "cook", "go cook", "let it cook", "iterate until it matches", "match the references", "99%", "99.9%", "9/10 minimum" or "at least 8h", or attaches reference images and asks for a recreation in code. It runs one intake, then loops build, stills, zero-context critics and fixes against a numeric bar, and holds the final render until the user approves.

14 other projects use a version of this.

Adopted by

Most recently taken up by

Used with

Projects with it also use csv-translator, upgrade-app and 3 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • pass-with-high-scoreSkill

    csv-translator

    Specialized skill for translating large CSV files. It follows a multi-step process of planning, counting lines, splitting large files into manageable chunks, translating chunks, merging, and finally importing translations into Android resource files. Use when the user needs to translate a CSV file, especially large ones.

    Also in 3 projects that use this

  • pass-with-high-scoreSkill

    upgrade-app

    Automates the process of upgrading the app version. Bumps versionCode and versionName in build.gradle.kts, updates the changelog, verifies the build, commits, pushes, and creates a GitHub release. Use when the user says "upgrade app", "release new version", or "bump version".

    Also in 3 projects that use this

  • apetrovSkill

    github-issue-manager

    Manage GitHub issues in the current repo via gh CLI. Use when asked to look up, inspect, design/plan, create, or implement a specific GitHub issue; or to update issue title/body/labels/state with explicit confirmation.

    Also in 3 projects that use this

  • Google CloudSkill

    fix

    Plan a remediation strategy after a test failure.

    Also in 3 projects that use this

  • SentrySkill

    skill-creator

    Create new agent skills following the Agent Skills specification. Use when asked to "create a skill", "add a new skill", "write a skill", "make a skill", "build a skill", or scaffold a new skill with SKILL.md. Guides through requirements, writing, registration, and verification.

    Also in 3 projects that use this

The file

Show its rules and text

We split this skill into the rules it gives an agent

17 rules. 0 are common, 13 are distinctive, and 4 are very specific to this project.

  • 0

    Common

    Most of the 12 edited versions we read keep these.

  • 13

    Distinctive

    This author's own choices. Worth a look.

  • 4

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    All run state lives in cook/ at the project root.

    line 16
  2. Distinctive:

    After every context compaction, do the same before your next action.

    line 29
  3. Very specific:

    Ask every open question in one message, each with a default, so the user can answer by number or reply "defaults".

    line 37
  4. Very specific:

    Write cook/SHOTS.md: one shot per reference image, with camera, framing, time of day and what to take from it (light, color, composition, …

    line 47
  5. Distinctive:

    Write a number per dimension into BRIEF.md: composition, light, color, materials, detail density (near and far), motion.

    line 53
  6. Distinctive:

    Keep measured numbers (a command produced them) apart from eyeballed ones (critic scores).

    line 56
  7. Distinctive:

    Before round 1, build the harness: a fixed camera preset per shot, a still renderer and a color check.

    line 77
  8. Distinctive:

    Run the Stop check. If it fails, start the next round now.

    line 88
  9. Very specific:

    Never stop when it first works.

    line 90
  10. Distinctive:

    After every round, send the stills with a short note: what changed, scores, next focus.

    line 94
  11. Distinctive:

    Never start the final render, or any other long and costly export, before the user approves the stills in chat.

    line 96
  12. Distinctive:

    Stop only when all of these are true:

    line 104
  13. Distinctive:

    Every dimension in every shot meets the bar, by critic median after calibration.

    line 105
  14. Distinctive:

    Ask a question after intake.

    line 113
  15. Distinctive:

    Start the final render before the user approves the stills.

    line 114
  16. Distinctive:

    Use 100% of a usage window.

    line 118
  17. Distinctive:

    Put API keys, tokens or private information in anything you publish.

    line 119

“Common” is measured: kept by at least 6 in 10 of the 12 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Cook

Give your agent a target, a bar and time, then let it cook.

This skill runs the Cook Loop: one intake, then a long autonomous loop of build, render, compare, critique and fix until the work holds up next to the references. It is made for runs of 10 to 40 hours or more. The references carry the look. The brief sets the bar, the rules and the time.

Optional companions: /unlazy for effort and completion discipline (the Depth Tree), and any goal, loop or long-run mode the harness offers. Cook works without them.

State files

All run state lives in cook/ at the project root. These files are your memory across context resets and the handoff to any other agent.

PathHolds
cook/BRIEF.mdTarget, bar, rules, time, deliverable, permissions. Written once after intake.
cook/SHOTS.mdOne shot per reference: camera, framing, what to take from it.
cook/ROUNDS.mdThe ledger. Copy templates/ROUNDS.md and add one entry per round.
cook/refs/The references, numbered R01, R02 for images and V01, V02 for videos.
cook/stills/rNN/, cook/compare/rNN/Renders and side-by-side images of round NN.

Start or resume

  • cook/BRIEF.md exists and the run is not shipped: you are resuming. Read BRIEF, SHOTS and the last two ROUNDS entries, then start the next round (step 6). Do not re-ask, restart or rebuild what works.
  • After every context compaction, do the same before your next action.
  • cook/ holds a shipped run: move it to cook-archive/<date>/ and start at step 1.
  • No cook/ folder: start at step 1.

The Cook Loop

1. Intake (once)

Ask every open question in one message, each with a default, so the user can answer by number or reply "defaults". Skip what the prompt, the attachments or a filled templates/brief.md already answer. If nothing is open, say so and start. Questions and defaults: references/intake.md.

Collect: what to build, references, bar, time budget, hard rules, deliverable, hardware, usage limits, and what you may download or publish.

Then write cook/BRIEF.md and cook/ROUNDS.md and start. From now on, never ask a question. The user may be asleep. Decide, log the decision under Decisions in ROUNDS.md, and keep working.

2. Target

References are the minimum bar, not inspiration.

  • Study every reference at full size before building anything.
  • Write cook/SHOTS.md: one shot per reference image, with camera, framing, time of day and what to take from it (light, color, composition, materials, timing).
  • Motion references: analyze them frame by frame into a list of effects, transitions and timings. Take from many, never copy one element 1:1.
  • Getting references for 3D, UI and motion, and the analysis steps: references/target-and-bar.md.

3. Bar

Write a number per dimension into BRIEF.md: composition, light, color, materials, detail density (near and far), motion.

  • Stills: a stretch target such as 99.9% similarity. Video: a score out of 10. References at about 8.5 mean a target of 9 or more.
  • Models rate themselves too high. When the user gives an estimate, log the gap as the calibration offset and apply it to every later score.
  • Keep measured numbers (a command produced them) apart from eyeballed ones (critic scores).

4. Rules

Defaults unless the brief says otherwise. Full rules: references/rules.md.

  • Zero external assets: every mesh, texture, shader and effect in code, when the point is the flex.
  • Sound: code-made only if it truly holds up. Otherwise licensed free libraries, credited.
  • Launch videos: real logos and real photos beat drawn SVG people.
  • Slop ban list: eyebrow labels, monospace uppercase text, random serif fonts, purple gradients, beige, 01/02/03 counters, glowing orbs, shockwave rings popping out of things, decorative particles, em dashes.
  • Color matches the references: never grey or washed out, never oversaturated.
  • Weak GPU: keep realtime cheap and get the quality from offline rendering (sub-frame accumulation for motion blur, soft shadows, depth of field, anti-aliasing).

5. Time

  • Demos get a floor: at least 8h, and done after 2h means something is wrong. Big builds can take days. Small jobs get a hard cap.
  • Log the start time. Read the clock at every round boundary.
  • Pace usage: about 20% of a 5h window per hour, about 99% per window, never 100%.
  • Depth over breadth: make one shot, scene or element exceptional before you expand.

6. Loop

Before round 1, build the harness: a fixed camera preset per shot, a still renderer and a color check. For side-by-side images use scripts/side-by-side.mjs from this skill (Node 18+ and ffmpeg): node <skill>/scripts/side-by-side.mjs --out cook/compare/r01/all.jpg cook/refs/R01.png cook/stills/r01/R01.png .... Every round reuses the harness.

Each round:

  1. Focus: open user feedback first, else the weakest dimension in the weakest shot.
  2. Fix it in depth. Split independent parts across parallel subagents.
  3. Render stills from the shot presets, same framing and aspect as each reference. For motion, render contact sheets and short clips.
  4. Make side-by-side images: reference left, render right.
  5. Measure what can be measured: color per region, frame time, seconds per rendered frame.
  6. Score with fresh-context critics: subagents with zero context that get only the side-by-side images and the rubric, optionally from another model. Your own score is logged, never decisive.
  7. Log the round in cook/ROUNDS.md.
  8. Send the stills to the user (Gate) and keep going.
  9. Run the Stop check. If it fails, start the next round now.

Never stop when it first works. Never claim a check that was not run. If something was not measured, write "not measured". Round details, critic prompts and pacing: references/loop-and-critics.md.

7. Gate

  • After every round, send the stills with a short note: what changed, scores, next focus. Do not pause, and do not end your turn to wait for a reply.
  • User feedback beats critic priorities. Log the exact words and address them in the next round.
  • Never start the final render, or any other long and costly export, before the user approves the stills in chat. While you wait, keep refining and test the render pipeline on a few short frames.

8. Ship

After approval, render the final deliverable and check the file. For a video on X: the first frame is the thumbnail and must be impressive, best scene first, a new scene every 6 to 7 seconds, no text on screen, licensed music credited, 1080p 30fps is enough. For a public repo: README, credits, the real prompt and honest numbers. Push or publish only if BRIEF.md allows it. Details: references/ship.md.

Stop check

Stop only when all of these are true:

  • Every dimension in every shot meets the bar, by critic median after calibration.
  • The time floor is reached (capped jobs have no floor).
  • The user approved the stills, and the final deliverable is rendered and its file checked.

Done before the floor means the bar was read too low. Reread the references at full size, check far distance, color and the weakest shot, and start another round. If a hard cap or a usage stop comes first, finish the round, log it and report plainly what is still below the bar.

Never

  • Ask a question after intake.
  • Start the final render before the user approves the stills.
  • Copy one reference element 1:1, or name third-party reference clips in public files.
  • Let your own score decide a stop.
  • Report a number you did not measure or a check you did not run.
  • Use 100% of a usage window.
  • Put API keys, tokens or private information in anything you publish.

Files in this skill

FileRead when
references/intake.mdStep 1: questions, defaults, writing BRIEF.md.
references/target-and-bar.mdSteps 2 and 3: references, shot list, motion analysis, rubric, calibration, measuring.
references/loop-and-critics.mdSteps 6 and 7: round details, critic prompts, user feedback, pacing, long runs.
references/rules.mdStep 4, and whenever you add anything visible or audible.
references/ship.mdStep 8: final render, video spec, repo, honest numbers, privacy scan.
templates/brief.mdWhen a user wants to write the brief themselves.
templates/ROUNDS.mdAt the start of a run: copy it to cook/ROUNDS.md.
scripts/side-by-side.mjsEvery round: reference left, render right, one row per shot.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.