[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6DCNASR2XH80M69B10P2AS7":3,"skill-same:01M6DCNASR2XH80M69B10P2AS7":90},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":68,"commitSha":69,"skillDirectory":70,"forksCount":71,"repositoryHtmlUrl":72,"repositoryHomepageUrl":6,"ownerHtmlUrl":73,"ownerBlogUrl":6,"ownerDescription":74,"updatedAt":75,"install":76,"resources":89},"01M6DCNASR2XH80M69B10P2AS7","dream-loop",null,"Build stunning 3D scenes via a concept-art fidelity loop.","zapabob\u002FSkills","zapabob","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F130830376?v=4","01M6DBMYZAGRTFQDSQYW3W764P","峯岸 亮","01M6DBMZ3GKDSJ01NZ9XTZD7JD",2,"MIT","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002F18\u002F188dac5e2989504115152585737de670b470eb4e09f1816ccf2847fb1080c42c\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000016","图像与多媒体",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"loop","dream loop","dream","p5js","image","generation","visual","scenes","build","image-generation","Art","creative","webgl","design","github","3D","Video","https","research","linux","2026-11-10 10:12:30",false,"---\nname: dream-loop\ndescription: \"Build stunning 3D scenes via a concept-art fidelity loop.\"\nversion: 1.0.0\nauthor: Anshu Chimala (adapted by Nous Research)\nlicense: MIT\ndependencies: []\nplatforms: [linux, macos]\nmetadata:\n  hermes:\n    tags: [3d, games, webgl, threejs, image-generation, visual-fidelity, creative]\n    category: creative\n    related_skills: [p5js, claude-design, manim-video]\n    upstream: https:\u002F\u002Fgithub.com\u002Fachimala\u002Fdream-loop\n---\n\n# Dream Loop Skill\n\nAn autonomous process for building extremely impressive visuals, especially 3D\nscenes (games, apps, usually browser three.js\u002FWebGL): generate photorealistic\nconcept art of the ideal result, build it, screenshot the live build, have a\njudge score screenshot vs concept against a gated ladder, and iterate until\nconvergence. Goal: the most visually stunning result at an acceptable frame\nrate for the target platform (e.g. 60 fps browser, 120 fps modern mobile).\n\nThis skill does NOT cover general web-app functionality, 2D UI design, or\nnon-visual quality — only the visual-fidelity loop.\n\n## When to Use\n\n- User says \"dream loop\" or asks for a game\u002Fscene\u002Fapp built to a very high\n  level of graphical fidelity.\n- Follow-up refinement passes on an existing visual product (see Follow-up\n  loops below).\n\n## Prerequisites\n\n- **Concept art**: the `image_generate` tool. If unavailable, stop and ask the\n  user for a concept image (or an image-generation API to connect to).\n- **Screenshots**: `browser_exec` — serve the build locally\n  (`python3 -m http.server` for static builds), then `new_tab(url)`,\n  `wait_for_load()`, `capture_screenshot()`.\n- **Judging**: `vision_analyze` (see Judge section for the one-image-per-call\n  workaround).\n- **Optional**: Blender for asset modeling — see the `blender-3d-automation`\n  skill. `delegate_task` for parallel asset work and fresh-context judging.\n\nIf you don't have the tools needed for the full loop, flag that to the user\nearly and stop.\n\n## Quick Reference\n\n| Stage | What happens | Artifacts (`.dream-loop\u002F`) |\n|---|---|---|\n| 1. Target | Get\u002Fconfirm the user's description | notes |\n| 2. Concept | Generate \"in-engine screenshot\" concept art | `concept.png` |\n| 3. Budget | Record time budget & start time (if given) | notes |\n| 4. Build | Implement the concept as well as possible in one go | source, plans |\n| 5. Screenshot | Capture live build at concept resolution | `round-N.png` |\n| 6. Self-check | Rigorous side-by-side audit before judging | assessment log |\n| 7. Judge | Ladder-scored comparison, actionable directives | verdict log |\n| 8. Iterate\u002FExit | Address directives or exit per criteria | — |\n\n## Procedure\n\n### 1. The target concept\n\nIf the user provided a description of a game, scene, or app, proceed — don't\nask for clarification unless it's too vague to generate concept art from. If\nthey didn't, ask for it.\n\nPut working context\u002Ffiles in `.dream-loop\u002F` and gitignore it (unless told\notherwise).\n\n### 2. Concept art\n\nThe concept is a realistic, high-quality, impressive target: the look of a\ncurrent AAA game running in real time. Physically plausible materials (wet\nstone, brushed metal, cloth, glass) with real roughness and normal detail,\ncorrect proportions, atmosphere (fog, haze, rain, dust, volumetric light),\ncinematic lighting with a clear key and rich shadows. It should NOT be\nstylized or an artistic rendition — it should look like a true screenshot of\nthe ideal result.\n\nAvoid these failure modes when generating with `image_generate`:\n\n- **Overbaked**: photographic clutter, film grain, hundreds of unique small\n  objects, excessive detail on every surface that reads as noise. A real-time\n  build with modeled assets won't match this, and it won't even look good.\n- **Oversimplified**: cartoon or toy look, flat shading, blobby primitive\n  shapes, empty surfaces. Boring; will not impress the user.\n\nAim for the middle ground: beautiful surfaces and materials that shaders\nrender well, strong atmosphere and lighting, an interesting palette, and\nfocused hero elements with fine detail that draws the eye (not every element\nfighting for attention).\n\nPrompt for \"in-engine screenshot\" more than \"concept art\" and discourage the\nnoisy\u002Fgrainy look. Review the image with `vision_analyze`; if it hits a\nfailure mode, pass it back to `image_generate` in edit mode and ask it to fix\nthe issue. Save it as `.dream-loop\u002Fconcept.png`.\n\nIf you generated the art (the user didn't supply it), pause and confirm it\nmatches the user's vision before starting the build loop.\n\n### 3. Time budget\n\nIf the user gives a time budget, record the start time and check the clock\nbetween rounds. Don't degrade visual fidelity to hit the budget — strive for\nthe absolute best result, and don't rush work to the judge. Parallelize or\ndistribute work (e.g. `delegate_task` for independent assets) to hit the\ntime goal, but no shortcuts: it's better to hit the time limit with\nmeaningful, beautiful progress than with something broadly complete but ugly.\n\nIf no time budget is given, run until an exit criterion — but warn upfront\nthat this may consume a lot of tokens.\n\n### 4. Build loop\n\nLook at the concept art and implement it in one go, making that first pass\ncount across every tier of the score ladder: composition, textures, lighting,\ndetails. Sculpt and model assets carefully (or use external ones if allowed);\ndon't settle for basic procedural elements and flat surfaces unless the art\nstyle calls for it. Write intermediate files\u002Fplans to `.dream-loop\u002F`.\n\n- If Blender is installed and the concept involves 3D assets, prefer modeling\n  in Blender (see the `blender-3d-automation` skill). For complex assets,\n  delegate to subagents via `delegate_task`.\n- If the user allows external assets, prefer them over modeling unless the\n  asset is simple. If unspecified, assume NO external assets from the web.\n- Do not be lazy with key environmental details (scenery, flooring,\n  buildings): simple shapes look blocky, shiny, flat, and fake. Tiny details\n  and texturing matter and need custom sculpting.\n- Use `image_generate` for textures, normal maps, skyboxes, etc. — better\n  looking and faster than procedural ones.\n\n### 5. Screenshot\n\nServe the build (e.g. `python3 -m http.server` in the build dir), then via\n`browser_exec`: `new_tab('http:\u002F\u002Flocalhost:8000')`, `wait_for_load()`, allow\nthe scene to settle, `capture_screenshot()`. Target the same resolution and\naspect ratio as the concept art so the comparison is fair. Save as\n`.dream-loop\u002Fround-N.png`.\n\n### 6. Self-check before judging\n\nEach time, review the candidate screenshot yourself before submitting. Do not\nsubmit half-baked work. Compare screenshot and concept side by side and log an\nhonest assessment of judge-readiness; only submit if confident you've\nsignificantly improved the score. Be rigorous and audit every pixel: big stuff\n(missing\u002Fincorrect objects, wrong scale, perspective, positioning) and small\nstuff (rendering glitches, flat untextured surfaces, ugly lighting, poor\ncontrast, washed-out or oversaturated color, speckles, ugly shadows). Scan\nsurface by surface, object by object, and list findings.\n\n### 7. Judge\n\nJudging should ideally be done by a fresh subagent with a clean context each\nround (`delegate_task`), to keep it objective and cheap. Give the judge the\nlatest screenshot, the concept, and (from round 2 on) the previous round's\nscreenshot and verdict.\n\nMechanics: `vision_analyze` takes one image per call. Either have the judge\nmake sequential calls (concept, then screenshot, then compare from memory of\nits own descriptions), or — better — stitch a labeled side-by-side composite\nwith ImageMagick (`convert concept.png shot.png +append compare.png`) or PIL\nand analyze that single image.\n\nJudge prompt:\n\n> You are an art director reviewing a real-time render against its concept\n> art. Compare the screenshot to the concept and score it 0-10 using this\n> ladder. The ladder is gated: a frame cannot score above a tier's cap until\n> every requirement of the tiers below it is fully met. Be strict about the\n> gates.\n>\n> - **Tier 1, shape (0-3):** camera, framing, composition, and the position\n>   and rough scale of every major object match the concept. Layout, not\n>   finish: every major element present, in the right region of the frame\n>   (within ~10% of frame width\u002Fheight), at roughly the right size (within\n>   ~25%). Right place and vaguely correct outline passes even if edges and\n>   surface are wrong; save precision nitpicks for Tier 4. Cap 3 until true.\n> - **Tier 2, light and color (3-5):** key light direction and color, overall\n>   exposure (no clipping to black or white), shadow depth, palette,\n>   contrast, atmosphere. Attend to reflections, glows, etc. Ensure the scene\n>   is not too bright or dark relative to the concept. Judge the whole frame,\n>   not tiny details (Tier 4). Cap 5 until lighting\u002Freflections\u002Fcolor\u002F\n>   contrast are generally right.\n> - **Tier 3, materials and surfaces (5-7):** every surface reads as the\n>   right material at a glance: textures, roughness, translucency, wetness,\n>   reflections. Assets must not look procedural, blocky, smooth\u002Fplastic;\n>   frame-dominating elements should be properly sculpted and detailed. Cap 7\n>   until true.\n> - **Tier 4, fine detail (7-9):** the small things. Nitpick relentlessly;\n>   inspect every little object up close. Layout aligns near-perfectly;\n>   materials extremely convincing. Cap 9 until right.\n> - **Tier 5, indistinguishable (9-10):** holds up side by side and zoomed\n>   in. Nitpick every pixel.\n>\n> If a previous verdict and screenshot are provided: you are one reviewer in\n> a sequence, not the first. Maintain consistency. First mark each previous\n> directive LANDED, PARTIAL, or NOT DONE against the new screenshot; carry\n> forward anything PARTIAL or NOT DONE. Don't reverse a prior directive\n> unless the result is clearly worse — and if you do, say so and why.\n>\n> Output format:\n> 1. Score on the first line; \"Tier N\" (highest fully-passed gate) on the\n>    second.\n> 1b. If given a previous verdict: the LANDED \u002F PARTIAL \u002F NOT DONE list.\n> 2. \"Blocking:\" the specific failures of the *next* tier's gate. The builder\n>    must clear these before anything else counts. Name the element and the\n>    change, with magnitudes: \"Rocks: replace the stacked ovoid boulders with\n>    one continuous fractured slab; cracks 2-5cm wide, dark interiors, add\n>    surface texture so they don't look flat\u002Fplastic\" — not \"the rocks look\n>    artificial\".\n> 3. Then at most 4 further directives from higher tiers, same style, ordered\n>    by points recoverable.\n>\n> No non-actionable feedback (\"this looks synthetic\") — name the specific\n> causes. Every directive must be actionable this round. Don't round up: if a\n> gate isn't fully passed, the cap holds.\n\n### 8. Exit criteria\n\n- **Score >= 8 and target FPS acceptable**: done. Show the user the latest\n  screenshot; ask if they want more iterations.\n- **Score >= 8 but FPS unacceptable**: optimize — lossless wins first, then\n  minimal-visual-impact ones. Re-judge afterwards to confirm no regression.\n- **Stall approaching** (best score hasn't improved a full point in 2 rounds,\n  or the judge named the same gap 3 times): stop incremental tweaks. Step\n  back and ask what about the *approach* is capping the score. Make one big\n  structural change in a round: swap asset strategy (sculpt in Blender, pull\n  real models\u002Ftextures\u002FHDRIs if allowed), rewrite the lighting model, rebuild\n  the composition, change the camera. Self-check carefully — big changes\n  break things. Only repeat parameter tuning if you can articulate why it\n  would work this time.\n- **Stalled** (already tried a big structural change, score flat 3 rounds,\n  judge is nitpicking or demanding intractable things like raytracing on a\n  GPU-less machine): stop, tell the user why you're blocked, give options.\n- **Otherwise**: address all or most heavy-hitting gaps this round, not just\n  the top one — rounds are expensive. Prioritize gaps that move the needle\n  most (lighting, textures, mesh detail). Only revert if the score dropped a\n  full point or more; small dips are judge noise, and reverting a whole round\n  throws out good changes with bad. If one change clearly regressed, undo\n  just that change. Loop.\n\n## Follow-up loops\n\nWhen building on an existing product (or the user re-invokes the skill for\nrefinements), don't create new concept art in a vacuum — it may diverge from\nwhat exists. Instead capture a live screenshot of the current product and\nprompt `image_generate` to render the best possible version of it (current\nscreenshot → AAA-graphics version of the same shot), then use that as the\ntarget. Multiple screens can run parallel judge loops if asked, at higher\ntoken cost.\n\n## Pitfalls\n\n- Overbaked or oversimplified concept art (see failure modes) — fix the\n  concept before building against it.\n- Submitting half-baked screenshots to the judge; the self-check gate exists\n  for a reason.\n- Screenshot at a different resolution\u002Faspect than the concept — unfair\n  comparison, noisy verdicts.\n- Tunnel-visioning on incremental tweaks when the judge says you're off base.\n- Judging both images in one `vision_analyze` call — it takes one image;\n  composite them first.\n- Screenshotting before the scene loads\u002Fsettles — add a wait after\n  `wait_for_load()` for asset streaming and animation warm-up.\n\n## Verification\n\n- `.dream-loop\u002Fconcept.png` exists and passed the failure-mode review (and\n  user confirmation, if generated).\n- Each round has a screenshot, a logged self-assessment, and a judge verdict\n  with score + tier + directives.\n- Exit only via an explicit exit criterion; final screenshot shown to the\n  user with the final score and FPS measurement.\n\n---\nAdapted from [dream-loop](https:\u002F\u002Fgithub.com\u002Fachimala\u002Fdream-loop) by Anshu\nChimala (MIT). Upstream license vendored as `LICENSE.txt`.\n","# Dream Loop Skill\n\nAn autonomous process for building extremely impressive visuals, especially 3D\nscenes (games, apps, usually browser three.js\u002FWebGL): generate photorealistic\nconcept art of the ideal result, build it, screenshot the live build, have a\njudge score screenshot vs concept against a gated ladder, and iterate until\nconvergence. Goal: the most visually stunning result at an acceptable frame\nrate for the target platform (e.g. 60 fps browser, 120 fps modern mobile).\n\nThis skill does NOT cover general web-app functionality, 2D UI design, or\nnon-visual quality — only the visual-fidelity loop.\n\n## When to Use\n\n- User says \"dream loop\" or asks for a game\u002Fscene\u002Fapp built to a very high\n  level of graphical fidelity.\n- Follow-up refinement passes on an existing visual product (see Follow-up\n  loops below).\n\n## Prerequisites\n\n- **Concept art**: the `image_generate` tool. If unavailable, stop and ask the\n  user for a concept image (or an image-generation API to connect to).\n- **Screenshots**: `browser_exec` — serve the build locally\n  (`python3 -m http.server` for static builds), then `new_tab(url)`,\n  `wait_for_load()`, `capture_screenshot()`.\n- **Judging**: `vision_analyze` (see Judge section for the one-image-per-call\n  workaround).\n- **Optional**: Blender for asset modeling — see the `blender-3d-automation`\n  skill. `delegate_task` for parallel asset work and fresh-context judging.\n\nIf you don't have the tools needed for the full loop, flag that to the user\nearly and stop.\n\n## Quick Reference\n\n| Stage | What happens | Artifacts (`.dream-loop\u002F`) |\n|---|---|---|\n| 1. Target | Get\u002Fconfirm the user's description | notes |\n| 2. Concept | Generate \"in-engine screenshot\" concept art | `concept.png` |\n| 3. Budget | Record time budget & start time (if given) | notes |\n| 4. Build | Implement the concept as well as possible in one go | source, plans |\n| 5. Screenshot | Capture live build at concept resolution | `round-N.png` |\n| 6. Self-check | Rigorous side-by-side audit before judging | assessment log |\n| 7. Judge | Ladder-scored comparison, actionable directives | verdict log |\n| 8. Iterate\u002FExit | Address directives or exit per criteria | — |\n\n## Procedure\n\n### 1. The target concept\n\nIf the user provided a description of a game, scene, or app, proceed — don't\nask for clarification unless it's too vague to generate concept art from. If\nthey didn't, ask for it.\n\nPut working context\u002Ffiles in `.dream-loop\u002F` and gitignore it (unless told\notherwise).\n\n### 2. Concept art\n\nThe concept is a realistic, high-quality, impressive target: the look of a\ncurrent AAA game running in real time. Physically plausible materials (wet\nstone, brushed metal, cloth, glass) with real roughness and normal detail,\ncorrect proportions, atmosphere (fog, haze, rain, dust, volumetric light),\ncinematic lighting with a clear key and rich shadows. It should NOT be\nstylized or an artistic rendition — it should look like a true screenshot of\nthe ideal result.\n\nAvoid these failure modes when generating with `image_generate`:\n\n- **Overbaked**: photographic clutter, film grain, hundreds of unique small\n  objects, excessive detail on every surface that reads as noise. A real-time\n  build with modeled assets won't match this, and it won't even look good.\n- **Oversimplified**: cartoon or toy look, flat shading, blobby primitive\n  shapes, empty surfaces. Boring; will not impress the user.\n\nAim for the middle ground: beautiful surfaces and materials that shaders\nrender well, strong atmosphere and lighting, an interesting palette, and\nfocused hero elements with fine detail that draws the eye (not every element\nfighting for attention).\n\nPrompt for \"in-engine screenshot\" more than \"concept art\" and discourage the\nnoisy\u002Fgrainy look. Review the image with `vision_analyze`; if it hits a\nfailure mode, pass it back to `image_generate` in edit mode and ask it to fix\nthe issue. Save it as `.dream-loop\u002Fconcept.png`.\n\nIf you generated the art (the user didn't supply it), pause and confirm it\nmatches the user's vision before starting the build loop.\n\n### 3. Time budget\n\nIf the user gives a time budget, record the start time and check the clock\nbetween rounds. Don't degrade visual fidelity to hit the budget — strive for\nthe absolute best result, and don't rush work to the judge. Parallelize or\ndistribute work (e.g. `delegate_task` for independent assets) to hit the\ntime goal, but no shortcuts: it's better to hit the time limit with\nmeaningful, beautiful progress than with something broadly complete but ugly.\n\nIf no time budget is given, run until an exit criterion — but warn upfront\nthat this may consume a lot of tokens.\n\n### 4. Build loop\n\nLook at the concept art and implement it in one go, making that first pass\ncount across every tier of the score ladder: composition, textures, lighting,\ndetails. Sculpt and model assets carefully (or use external ones if allowed);\ndon't settle for basic procedural elements and flat surfaces unless the art\nstyle calls for it. Write intermediate files\u002Fplans to `.dream-loop\u002F`.\n\n- If Blender is installed and the concept involves 3D assets, prefer modeling\n  in Blender (see the `blender-3d-automation` skill). For complex assets,\n  delegate to subagents via `delegate_task`.\n- If the user allows external assets, prefer them over modeling unless the\n  asset is simple. If unspecified, assume NO external assets from the web.\n- Do not be lazy with key environmental details (scenery, flooring,\n  buildings): simple shapes look blocky, shiny, flat, and fake. Tiny details\n  and texturing matter and need custom sculpting.\n- Use `image_generate` for textures, normal maps, skyboxes, etc. — better\n  looking and faster than procedural ones.\n\n### 5. Screenshot\n\nServe the build (e.g. `python3 -m http.server` in the build dir), then via\n`browser_exec`: `new_tab('http:\u002F\u002Flocalhost:8000')`, `wait_for_load()`, allow\nthe scene to settle, `capture_screenshot()`. Target the same resolution and\naspect ratio as the concept art so the comparison is fair. Save as\n`.dream-loop\u002Fround-N.png`.\n\n### 6. Self-check before judging\n\nEach time, review the candidate screenshot yourself before submitting. Do not\nsubmit half-baked work. Compare screenshot and concept side by side and log an\nhonest assessment of judge-readiness; only submit if confident you've\nsignificantly improved the score. Be rigorous and audit every pixel: big stuff\n(missing\u002Fincorrect objects, wrong scale, perspective, positioning) and small\nstuff (rendering glitches, flat untextured surfaces, ugly lighting, poor\ncontrast, washed-out or oversaturated color, speckles, ugly shadows). Scan\nsurface by surface, object by object, and list findings.\n\n### 7. Judge\n\nJudging should ideally be done by a fresh subagent with a clean context each\nround (`delegate_task`), to keep it objective and cheap. Give the judge the\nlatest screenshot, the concept, and (from round 2 on) the previous round's\nscreenshot and verdict.\n\nMechanics: `vision_analyze` takes one image per call. Either have the judge\nmake sequential calls (concept, then screenshot, then compare from memory of\nits own descriptions), or — better — stitch a labeled side-by-side composite\nwith ImageMagick (`convert concept.png shot.png +append compare.png`) or PIL\nand analyze that single image.\n\nJudge prompt:\n\n> You are an art director reviewing a real-time render against its concept\n> art. Compare the screenshot to the concept and score it 0-10 using this\n> ladder. The ladder is gated: a frame cannot score above a tier's cap until\n> every requirement of the tiers below it is fully met. Be strict about the\n> gates.\n>\n> - **Tier 1, shape (0-3):** camera, framing, composition, and the position\n>   and rough scale of every major object match the concept. Layout, not\n>   finish: every major element present, in the right region of the frame\n>   (within ~10% of frame width\u002Fheight), at roughly the right size (within\n>   ~25%). Right place and vaguely correct outline passes even if edges and\n>   surface are wrong; save precision nitpicks for Tier 4. Cap 3 until true.\n> - **Tier 2, light and color (3-5):** key light direction and color, overall\n>   exposure (no clipping to black or white), shadow depth, palette,\n>   contrast, atmosphere. Attend to reflections, glows, etc. Ensure the scene\n>   is not too bright or dark relative to the concept. Judge the whole frame,\n>   not tiny details (Tier 4). Cap 5 until lighting\u002Freflections\u002Fcolor\u002F\n>   contrast are generally right.\n> - **Tier 3, materials and surfaces (5-7):** every surface reads as the\n>   right material at a glance: textures, roughness, translucency, wetness,\n>   reflections. Assets must not look procedural, blocky, smooth\u002Fplastic;\n>   frame-dominating elements should be properly sculpted and detailed. Cap 7\n>   until true.\n> - **Tier 4, fine detail (7-9):** the small things. Nitpick relentlessly;\n>   inspect every little object up close. Layout aligns near-perfectly;\n>   materials extremely convincing. Cap 9 until right.\n> - **Tier 5, indistinguishable (9-10):** holds up side by side and zoomed\n>   in. Nitpick every pixel.\n>\n> If a previous verdict and screenshot are provided: you are one reviewer in\n> a sequence, not the first. Maintain consistency. First mark each previous\n> directive LANDED, PARTIAL, or NOT DONE against the new screenshot; carry\n> forward anything PARTIAL or NOT DONE. Don't reverse a prior directive\n> unless the result is clearly worse — and if you do, say so and why.\n>\n> Output format:\n> 1. Score on the first line; \"Tier N\" (highest fully-passed gate) on the\n>    second.\n> 1b. If given a previous verdict: the LANDED \u002F PARTIAL \u002F NOT DONE list.\n> 2. \"Blocking:\" the specific failures of the *next* tier's gate. The builder\n>    must clear these before anything else counts. Name the element and the\n>    change, with magnitudes: \"Rocks: replace the stacked ovoid boulders with\n>    one continuous fractured slab; cracks 2-5cm wide, dark interiors, add\n>    surface texture so they don't look flat\u002Fplastic\" — not \"the rocks look\n>    artificial\".\n> 3. Then at most 4 further directives from higher tiers, same style, ordered\n>    by points recoverable.\n>\n> No non-actionable feedback (\"this looks synthetic\") — name the specific\n> causes. Every directive must be actionable this round. Don't round up: if a\n> gate isn't fully passed, the cap holds.\n\n### 8. Exit criteria\n\n- **Score >= 8 and target FPS acceptable**: done. Show the user the latest\n  screenshot; ask if they want more iterations.\n- **Score >= 8 but FPS unacceptable**: optimize — lossless wins first, then\n  minimal-visual-impact ones. Re-judge afterwards to confirm no regression.\n- **Stall approaching** (best score hasn't improved a full point in 2 rounds,\n  or the judge named the same gap 3 times): stop incremental tweaks. Step\n  back and ask what about the *approach* is capping the score. Make one big\n  structural change in a round: swap asset strategy (sculpt in Blender, pull\n  real models\u002Ftextures\u002FHDRIs if allowed), rewrite the lighting model, rebuild\n  the composition, change the camera. Self-check carefully — big changes\n  break things. Only repeat parameter tuning if you can articulate why it\n  would work this time.\n- **Stalled** (already tried a big structural change, score flat 3 rounds,\n  judge is nitpicking or demanding intractable things like raytracing on a\n  GPU-less machine): stop, tell the user why you're blocked, give options.\n- **Otherwise**: address all or most heavy-hitting gaps this round, not just\n  the top one — rounds are expensive. Prioritize gaps that move the needle\n  most (lighting, textures, mesh detail). Only revert if the score dropped a\n  full point or more; small dips are judge noise, and reverting a whole round\n  throws out good changes with bad. If one change clearly regressed, undo\n  just that change. Loop.\n\n## Follow-up loops\n\nWhen building on an existing product (or the user re-invokes the skill for\nrefinements), don't create new concept art in a vacuum — it may diverge from\nwhat exists. Instead capture a live screenshot of the current product and\nprompt `image_generate` to render the best possible version of it (current\nscreenshot → AAA-graphics version of the same shot), then use that as the\ntarget. Multiple screens can run parallel judge loops if asked, at higher\ntoken cost.\n\n## Pitfalls\n\n- Overbaked or oversimplified concept art (see failure modes) — fix the\n  concept before building against it.\n- Submitting half-baked screenshots to the judge; the self-check gate exists\n  for a reason.\n- Screenshot at a different resolution\u002Faspect than the concept — unfair\n  comparison, noisy verdicts.\n- Tunnel-visioning on incremental tweaks when the judge says you're off base.\n- Judging both images in one `vision_analyze` call — it takes one image;\n  composite them first.\n- Screenshotting before the scene loads\u002Fsettles — add a wait after\n  `wait_for_load()` for asset streaming and animation warm-up.\n\n## Verification\n\n- `.dream-loop\u002Fconcept.png` exists and passed the failure-mode review (and\n  user confirmation, if generated).\n- Each round has a screenshot, a logged self-assessment, and a judge verdict\n  with score + tier + directives.\n- Exit only via an explicit exit criterion; final screenshot shown to the\n  user with the final score and FPS measurement.\n\n---\nAdapted from [dream-loop](https:\u002F\u002Fgithub.com\u002Fachimala\u002Fdream-loop) by Anshu\nChimala (MIT). Upstream license vendored as `LICENSE.txt`.\n",{"name":5,"author":52,"license":15,"version":53,"metadata":54,"platforms":65,"description":7,"dependencies":67},"Anshu Chimala (adapted by Nous Research)","1.0.0",{"hermes":55},{"tags":56,"category":38,"upstream":61,"related_skills":62},[57,58,39,59,36,60,38],"3d","games","threejs","visual-fidelity","https:\u002F\u002Fgithub.com\u002Fachimala\u002Fdream-loop",[30,63,64],"claude-design","manim-video",[46,66],"macos",[],"main","0d1434f89f4bc6b07e9d272accd8c1013768820f","archive\u002Fskill-md-reviewed\u002Fsha256\u002F18\u002F188dac5e2989504115152585737de670b470eb4e09f1816ccf2847fb1080c42c",0,"https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills","https:\u002F\u002Fgithub.com\u002Fzapabob","The Open University of JAPAN　2019-now\r\n\r\nTokyo University of Science　2007-2010","2026-10-26 16:29:01",{"source":8,"skillName":5,"commands":77,"prompt":87,"zipAvailable":88},[78,81,84],{"tool":79,"command":80},"npx","npx skills add zapabob\u002FSkills --skill dream-loop",{"tool":82,"command":83},"bunx","bunx skills add zapabob\u002FSkills --skill dream-loop",{"tool":85,"command":86},"pnpm","pnpm dlx skills add zapabob\u002FSkills --skill dream-loop","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Farchive\u002Fskill-md-reviewed\u002Fsha256\u002F18\u002F188dac5e2989504115152585737de670b470eb4e09f1816ccf2847fb1080c42c\u002FSKILL.md",true,[],[91,123,155,180,207,224],{"skillNo":92,"name":93,"nameZh":6,"description":94,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":95,"categories":96,"keywords":108,"publishedAt":47},"01M6GJTE1GESGGF9K028Y7753E","xurl","X\u002FTwitter via xurl CLI: post, search, DM, media, v2 API.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fxurl\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[97,100,103],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000010","后端与接口",{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000030","开发工程师","PROFESSION","适用职业",[93,109,66,110,41,46,111,112,113,44,114,115,116,117,118,119,68,120,121,122],"openclaw","cli","windows","official","search","social-media","api","Media","hermes","hermes agent","twitter","social","via","post",{"skillNo":124,"name":125,"nameZh":6,"description":126,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":127,"categories":128,"keywords":138,"publishedAt":47},"01M6GJT8S1PXQ8WPXT1HSNBWH2","writing-plans","Write implementation plans: bite-sized tasks, paths, code.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwriting-plans\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[129,130,133,134,135],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":131,"categoryName":132,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000018","写作与文案",{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},{"categoryNo":136,"categoryName":137,"taxonomyType":106,"taxonomyTypeDesc":107},"01JBSEEDCAT000000000000036","内容创作者",[139,140,141,40,66,142,46,143,111,144,145,146,147,148,149,150,151,152,153,154],"writing","writing plans","plans","review","workflow","documentation","tasks","development","code","planning","code-review","subagent","write","superpowers","paths","test-driven-development",{"skillNo":156,"name":157,"nameZh":6,"description":158,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":159,"categories":160,"keywords":162,"publishedAt":47},"01M6GJST0H5X7WHBJ3BZK0DVKH","whisper","OpenAI's general-purpose speech recognition model. Supports 99 languages, transcription, translation to English, and language identification. Six model sizes from tiny (39M params) to large (1550M params). Use for speech-to-text, podcast transcription, or multilingual audio processing. Best for robust, multilingual ASR.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwhisper\u002Fvariants\u002Fhermes-agent-optional\u002FSKILL.md",[161],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[157,66,46,163,164,165,166,167,168,169,170,171,172,173,174,175,176,177,178,179],"openai","speech","multimodal","Transformers","ASR","Audio","text","model","speech recognition","use","general","multilingual","translation","english","identification","processing","Audio Processing",{"skillNo":181,"name":182,"nameZh":6,"description":183,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":184,"categories":185,"keywords":189,"publishedAt":47},"01M6GJSMRQ8EETZTYMG72P70EA","weights-and-biases","W&B: log ML experiments, sweeps, model registry, dashboards.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fweights-and-biases\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[186],{"categoryNo":187,"categoryName":188,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000013","分析与可视化",[190,66,191,192,111,193,194,195,196,197,198,170,199,200,201,202,203,204,205,206],"weights and biases","tensorflow","experiments","pytorch","visualization","registry","real-time","tuning","dashboards","experiment","log","time","Experiment Tracking","Model Registry","Hyperparameter Tuning","WandB","Real-Time Visualization",{"skillNo":208,"name":209,"nameZh":6,"description":210,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":211,"categories":212,"keywords":214,"publishedAt":47},"01M6GJS19KDPRY112JTR326S06","watchers","Poll RSS, JSON APIs, and GitHub with watermark dedup.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fwatchers\u002Fvariants\u002Fhermes-agent-optional\u002FSKILL.md",[213],{"categoryNo":101,"categoryName":102,"taxonomyType":21,"taxonomyTypeDesc":22},[209,66,215,41,46,216,217,218,219,220,221,117,118,222,223],"terminal","automation","http","monitoring","cron","json","rss","devops","with",{"skillNo":225,"name":226,"nameZh":6,"description":227,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":228,"categories":229,"keywords":232,"publishedAt":47},"01M6GJRHJD2A6Q830SWF9W48BC","serving-llms-vllm","vLLM: high-throughput LLM serving, OpenAI API, quantization.","https:\u002F\u002Fgithub.com\u002Fzapabob\u002FSkills\u002Fblob\u002Fmain\u002Fregistry\u002Fskills\u002Fvllm\u002Fvariants\u002Fhermes-agent\u002FSKILL.md",[230,231],{"categoryNo":98,"categoryName":99,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":104,"categoryName":105,"taxonomyType":106,"taxonomyTypeDesc":107},[233,234,235,46,45,163,236,237,238,166,239,115,240,241,242,243,244,245,246,247],"llms","vLLM","serving llms vllm","openai api","tensor","Inference Serving","Production","llm serving","High Throughput","PagedAttention","Continuous Batching","Quantization","Tensor Parallelism","high-throughput","throughput"]