[{"_1":2,"_300":-5,"_301":-5},"loaderData",{"_3":4,"_8":9,"_23":24},"root",{"_5":-5,"_6":7},"user","countable",true,"routes/_main",{"_5":-5,"_10":11},"recentPosts",[12,17,20],{"_13":14,"_15":16},"slug","claude-code-agent-teams","title","What Claude Code's Agent Teams Feature Does",{"_13":18,"_15":19},"claude-code-goal-command","How Claude Code's /goal Command Works",{"_13":21,"_15":22},"claude-code-routines-vs-loop","Claude Code Routines vs /loop: What's the Difference?","routes/creators.$handle",{"_25":26,"_27":26,"_28":29,"_30":31,"_32":33,"_298":31,"_299":111},"handle","img2threejs","displayName","profileUrl","https://github.com/img2threejs","verified",false,"skills",[34],{"_35":36,"_13":37,"_38":39,"_40":26,"_41":42,"_43":44,"_45":46,"_47":48,"_49":50,"_51":52,"_54":55,"_61":62,"_63":64,"_65":66,"_81":82,"_83":-5,"_84":85,"_86":87,"_88":89,"_90":91,"_92":93,"_94":-5,"_95":96,"_97":26,"_30":31,"_98":31,"_99":87,"_100":101,"_102":87,"_103":87,"_104":105,"_106":107,"_134":135,"_170":171,"_221":222,"_272":273,"_284":285,"_294":295,"_296":297},"id","gh__img2threejs__img2threejs__root","image-to-procedural-three-js-img2threejs","name","Image to Procedural Three.js","canonicalName","tagline","Transform images into animation-ready 3D models with code.","description","Turn an object or character reference image into a quality-gated, animation-ready procedural Three.js model built in code. Use for image-to-3D reconstruction, detail-accurate object rebuilds, stylized/likeness-maximized human characters, sculpt specs, and staged code generation.","longDescription","img2threejs is a powerful tool designed for developers and designers looking to convert reference images into procedural Three.js models. Unlike traditional methods such as photogrammetry or mesh extraction, this skill focuses on a code-only reconstruction process. It employs a staged sculpting pipeline that includes an AI-vision self-correction loop, ensuring that the resulting models are not only accurate but also suitable for animation and further manipulation. This approach allows for detailed object rebuilds and stylized human character reconstructions, making it versatile for various applications in game development and 3D modeling.\n\nThe workflow begins with the user providing a reference image. The skill then guides the user through a series of steps, ensuring that each phase of the model creation is validated and documented. This includes assessing the image for suitability, defining a quality contract, and meticulously building the model in passes from blockout to optimization. Each step requires evidence and validation, allowing for a transparent development process that encourages iterative improvement. Users can easily debug the modeling process by tracing decisions made at each stage, making it easier to refine the output.\n\nThis skill is particularly useful for those involved in game design, animation, or any field that requires high-quality 3D models derived from 2D images. Whether you are creating props, characters, or complex mechanical parts, img2threejs provides a structured approach to achieving your goals. The agent-agnostic nature of the tool means it can be utilized across various AI coding platforms, making it a flexible addition to your development toolkit.","primaryCategory","development","subcategory","code-generation","secondaryCategories",[53],"design","tags",[56,57,58,59,60],"threejs","3d-modeling","image-to-3d","procedural-models","game-development","skillType","workflow","complexity","intermediate","platforms",[67,68,69,70,71,72,73,74,75,76,77,78,79,80],"claude-code","claude-api","codex-cli","cursor","antigravity","github-copilot","windsurf","opencode","cline","roo-code","goose","kiro","continue","trae","delivery","source-link","skillFileUrl","pricing","free","price",0,"thumbnailType","icon","thumbnailIcon","rocket","thumbnailColor","cyan","thumbnailImageUrl","sellerId","gh__img2threejs","sellerName","featured","downloads","views",3,"rating","reviewCount","status","active","metrics",{"_108":109,"_110":111,"_112":111,"_113":109,"_114":115,"_116":117,"_118":119,"_120":121,"_122":123,"_124":101,"_125":126,"_127":128,"_129":87,"_130":131,"_132":133},"freshnessScore",100,"mirrorCount",1,"skillCountInRepo","qualityScore","popularityScore",82,"trustScore",60,"repoOpenIssues",55,"repoStars",10633,"repoWatchers",34,"repoContributors","overallScore",88,"repoCreatedAt","2026-07-15T02:58:39Z","daysSinceUpdate","repoForks",800,"repoPushedAt","2026-08-10T08:31:14Z","source",{"_136":26,"_137":138,"_139":140,"_145":26,"_146":-5,"_143":147,"_148":149,"_150":31,"_151":152,"_153":154,"_160":161,"_162":7,"_163":164,"_165":166,"_167":168,"_169":168},"owner","repoUrl","https://github.com/img2threejs/img2threejs","author",{"_28":29,"_141":142,"_38":26,"_25":26,"_143":144},"avatarUrl","https://github.com/img2threejs.png","type","User","repo","commitSha","github","branch","main","isOfficial","path","","license",{"_38":155,"_156":157,"_158":159},"Apache License 2.0","spdxId","Apache-2.0","url","https://github.com/img2threejs/img2threejs/blob/main/LICENSE","sourceUpdatedAt","2026-08-06T05:23:34.000Z","redistributable","permalink","https://github.com/img2threejs/img2threejs/blob/main/SKILL.md","repoFullName","img2threejs/img2threejs","lastSyncedAt","2026-08-11T01:20:53.270Z","firstSeenAt","seo",{"_172":173,"_184":185,"_186":187,"_205":-5,"_206":207,"_213":214,"_215":216,"_217":218,"_219":220},"useCases",[174,178,181],{"_15":175,"_176":177},"Creating Game Characters","body","Use img2threejs to transform character reference images into detailed, animation-ready 3D models for your game.",{"_15":179,"_176":180},"Designing Props for Animation","Convert object images into procedural models that can be easily animated and integrated into your scenes.",{"_15":182,"_176":183},"Developing Mechanical Parts","Utilize the skill to reconstruct complex mechanical components from reference images, ensuring accuracy and detail.","whenNotToUse","This skill is not suitable for users looking for quick, one-off mesh generation or those who require photorealistic results without manual adjustments.","faqs",[188,193,196,199,202],{"_189":190,"_191":192},"q","What types of images can I use with img2threejs?","a","You can use any reference image that is suitable for 3D modeling, such as objects, characters, or environments. The skill includes a validation step to ensure the image is appropriate for conversion.",{"_189":194,"_191":195},"Can I use img2threejs for quick mesh generation?","No, img2threejs focuses on a detailed, step-by-step reconstruction process rather than quick mesh generation. It is designed for users who need high-quality, procedural models.",{"_189":197,"_191":198},"Is this skill compatible with all AI coding agents?","Yes, img2threejs is agent-agnostic and works with various platforms, including Claude Code, Codex, and others that support image reading and processing.",{"_189":200,"_191":201},"How does the debugging process work in img2threejs?","The skill emphasizes transparency in the modeling process, allowing users to track changes, provide evidence for each step, and identify discrepancies, making debugging straightforward.",{"_189":203,"_191":204},"What output can I expect from using img2threejs?","You can expect a procedural Three.js model that is animation-ready, along with detailed documentation of the modeling process and any limitations or approximations.","ogImageUrl","keywords",[208,209,210,211,212],"image to 3D model","Three.js procedural generation","3D modeling from images","animation-ready models","code-based 3D reconstruction","whenToUse","Use img2threejs when you have a reference image and need a procedural Three.js model for animation or game development.","metaTitle","Image to Procedural Three.js - Transform Images into 3D Models","problemSolved","This skill eliminates the need for manual 3D modeling from scratch by automating the conversion of images into detailed procedural models.","metaDescription","Convert reference images into quality-gated, animation-ready 3D models with img2threejs.","content",{"_223":224,"_225":226,"_252":253,"_263":264,"_265":31,"_266":267,"_270":271},"bundledFiles",6,"fileTree",[227,234,237,240,243,246,249],{"_151":228,"_229":230,"_143":231,"_232":233},"CHANGELOG.md","size",13167,"file","language","markdown",{"_151":235,"_229":236,"_143":231,"_232":233},"CLAUDE.md",2825,{"_151":238,"_229":239,"_143":231,"_232":233},"CONTRIBUTING.md",4181,{"_151":241,"_229":242,"_143":231},"LICENSE",11337,{"_151":244,"_229":245,"_143":231,"_232":233},"README.md",26688,{"_151":247,"_229":248,"_143":231,"_232":233},"ROADMAP.md",14904,{"_151":250,"_229":251,"_143":231,"_232":233},"SKILL.md",48766,"codeExamples",[254,258,261],{"_232":255,"_256":257},"text","snippet","~/.claude/skills/img2threejs -> \n~/.codex/skills/img2threejs -> ",{"_232":259,"_256":260},"bash","python3 forge/state.py init --reference --profile character --spec object-sculpt-spec.json\npython3 forge/next.py --state .img2threejs/state.json\npython3 forge/state.py mark image-analysis --evidence analysis.md",{"_232":259,"_256":262},"IMG2THREEJS_SHOWCASE_ROOT=/path/to/img2threejs-showcase python3 forge/tests/test_subdivision.py\nIMG2THREEJS_SHOWCASE_ROOT=/path/to/img2threejs-showcase python3 -m unittest discover -s forge/tests\nIMG2THREEJS_SHOWCASE_ROOT=/path/to/img2threejs-showcase python3 forge/tests/test_showcase_tsc_smoke.py","skillMd","# img2threejs — Image to procedural Three.js\n\nRebuild the object visible in a reference image as a **code-only** procedural Three.js model,\ngated by a staged sculpting pipeline and an AI-vision self-correction loop. This is\nreconstruction-by-code, **not** photogrammetry, mesh extraction, or downloaded art packs.\n\nAgent-agnostic: works under Claude Code, Codex, or OpenCode. Wherever this doc says \"agent\nvision\" or \"agent browser tool\", use whatever the host provides — native image reading, a\nbrowser MCP (playwright/chrome-devtools), the project preview, or a user-supplied screenshot.\n\n## Canonical shared checkout\n\nKeep one checkout of this repository and let every host enter it through a symlink, so Claude and\nCodex execute the same code instead of drifting apart:\n\n```text\n~/.claude/skills/img2threejs -> \n~/.codex/skills/img2threejs -> \n```\n\n## When To Use\n\nThe user attaches/points to an object image and wants a procedural Three.js model, a\nreconstruction/animation/destruction plan, a sculpt spec, or code. Also for material studies,\naction-ready props, game objects, botanical/mechanical parts, and stylized reconstructions.\n\n## Core Promise\n\nSculpt from a photo, in order — never one-shot a mesh:\n1. **Run `python3 forge/next.py ` first, or `python3 forge/next.py --state .img2threejs/state.json`.** The state form reports the ordered local checklist, exact next command, evidence status, and bounded correction-loop status; it never replaces the spec/pass gates.\n1. **Use local state first.** Initialize it once, then run\n `python3 forge/next.py --state .img2threejs/state.json []` at every start/resume and before\n every correction iteration. Obey a hard stop; never continue from memory.\n2. **Validate** the image is a suitable 3D target (`grimoire/intake/validation_rubric.md`).\n3. **Assess** object class + complexity, then write a `qualityContract` before any code.\n3. **Spec** it: component hierarchy, materials, lighting, pivots, sockets, action anchors.\n4. **Build pass-by-pass** from blockout → structure → form → material → lighting → interaction → optimization.\n5. **Verify** each pass with a screenshot compared against the reference; fail a pass if an identity-defining feature is wrong even when the global score looks fine.\n\nState explicitly when output is approximate/stylized/low-poly. A single image cannot reveal\nhidden sides or guarantee exact geometry — say so instead of faking confidence.\n\n## Resumable local workflow\n\nFor a cross-agent or multi-session reconstruction, initialize the local state before intake:\n\n```bash\npython3 forge/state.py init --reference --profile character --spec object-sculpt-spec.json\npython3 forge/next.py --state .img2threejs/state.json\npython3 forge/state.py mark image-analysis --evidence analysis.md\n```\n\n`generic`, `character`, and `cs2` profiles insert their required intake gates in order. Every\ncompleted step needs evidence; every skipped step needs a reason. The state file is a resumability\nindex, not visual evidence: renders, specs, review history, and deterministic gates remain the\nauthoritative artifacts.\n\n## Transparency and Process Debugging (Critical — from Bowie Knife reconstruction)\n\n**The problem:** When the user cannot tell what was done or where something went wrong, they cannot debug the process. Over-claiming (reporting success when features still don't match) destroys trust and makes iterative improvement impossible.\n\n**Rule:** Be transparent + don't over-claim. State exactly what changed each pass, with evidence, and name what still doesn't match:\n- After each pass, explicitly list what changed: \"Updated guard shape to extend left edge from -0.56 to -0.48 for handle overlap\"\n- Provide evidence: reference the specific values, coordinates, or parameters that changed\n- Name what still doesn't match: \"Handle silhouette traced but still flat plane (no Z palm-swell), procedural crosshatch not reference's exact dot-grid knurl\"\n- Explain why a change was made: \"Extended guard left edge because handle ends at X=-0.42 and guard ended at X=-0.20, causing visual gap\"\n- Never claim a feature is \"done\" when it's only \"improved\" — use precise language\n- When a gate passes but visual inspection shows issues, explain the limitation: \"2D gate passed (fidelity 0.83) but three-quarter render shows blade reads as toy (no grind wedge) — 2D gates are blind to 3D realism\"\n\n**The user needs to be able to debug the process, not just the output.** If something is wrong, they should be able to trace which decision led to the error and correct it. Opaque processes force restarts; transparent processes enable refinement.\n## Transparency and Process Debugging\n\nReport what changed each pass with evidence (exact values/coordinates), name what still doesn't\nmatch, and never claim \"done\" when only \"improved\". A passing gate is not proof of 3D realism.\nFull rule + examples: `grimoire/review/self_correction.md`.\n\n## GLB-mediated v2 render-fidelity track (1.5 alpha)\n\nWhen the user supplies a GLB as an intermediate reference, use the browser-rendered GLB\nas the structural and visual baseline, then author an independent procedural factory. The\nraw GLB is never pixel evidence and its topology/materials are never copied into the factory.\n\nBefore any factory edit:\n\n1. Run `forge/stage1_intake/probe_glb.py` and inspect `semanticDecomposition`. A merged\n one-node/one-mesh/one-primitive/one-material asset is `insufficient` for reliable semantic\n labels; connected-component/curvature/normal/UV segmentation is hypothesis evidence only.\n Request a multipart GLB or capture a browser semantic-ID pass before claiming exact regions.\n2. Author and validate one shared `render-profile.v2` with\n `forge/stage4_review/validate_render_profile.py`. Both GLB and procedural routes must use\n the same output color space, linear working space, tone mapping/exposure, PMREM environment,\n viewport/DPR, camera, background and lighting settings.\n3. Capture six passes for every admitted view: `beauty`, `alpha-silhouette`, `semantic-id`,\n `depth`, `normal`, and `roughness-material-id`. Use\n `forge/stage4_review/compare_region_passes.py` for deterministic global/per-region evidence;\n missing semantic-ID data blocks per-region confidence instead of falling back to whole-image\n color or silhouette scores.\n4. Use region-specific continuous geometry/material strategies. Do not replace a face/head volume,\n cloth shell, kasa, staff, or tail with a generic collection of floating primitives when the\n region's silhouette or attachment requires a continuous surface.\n5. Run one correction group per loop in this order: `camera → silhouette → face → clothing →\n accessory → materials → lighting`. Recapture the full pass set after each group and record\n the changed group, hashes and score. Never combine groups when diagnosing improvement.\n\nThe machine-readable contract lives in `docs/specs/render-profile.v2.schema.json` and\n`docs/specs/render-profile.v2.example.json`. The executable manifest bridge accepts\n`--render-profile` and exposes `record-pass`; its `glb-mediated-v2` validation is fail-closed.\n\n## Required Inputs\n\n- one image path / screenshot / URL / attached image (if missing or unreadable, ask)\n- intended use: prop, game object, hero render, playable/destructible object, animation rig\n (default: real-time browser prop with interactive performance)\n- for a CS2 request, an authoritative classification record (family/subtype and evidence refs) or\n an explicit request for the user/vision provider to supply one; heuristic detection alone is not\n enough to select a geometry adapter\n\n## Mandatory Local State Gate\n\nConversation context is disposable; `.img2threejs/state.json` is the local checklist authority.\nInitialize it once per reconstruction:\n\n`python3 forge/state.py init --state .img2threejs/state.json --reference --profile `\n\nAt every fresh start, resume, or correction loop, run\n`python3 forge/next.py --state .img2threejs/state.json [object-sculpt-spec.json]` before touching\ncode. It prints the current step, pass, incomplete mandatory steps, exact next command, and\n`loop/max`. Exit code 3 or `status=stopped` is a hard stop: report the reason and request input.\nNever bypass it by reconstructing progress from chat history.\n\nAfter evidence exists, record it with\n`python3 forge/state.py mark --state .img2threejs/state.json --evidence `.\nMark a non-applicable step `skipped` only with `--reason`; silent omission is forbidden. Loop counts\nare derived from `reviewHistory` actions `refine-spec`/`refine-code`, not agent memory. Defaults are\n3 corrections per pass and 6 total.\n\nProfiles add mandatory gates rather than changing the core order: `cs2` requires classification,\nmanifest, and a machine-readable CS2 review before AI review; `character` requires the character\ncontracts and landmark evidence. Every profile records suitability, projection applicability, and\nmaterial-evidence applicability; conditional steps require evidence or an explicit skip reason.\n\n## The Loop (scripts do enforcement; agent vision does judgment)\n\nRun scripts from the skill root (`forge/...`). Pure Python 3.10+ stdlib, no pip installs.\nFull flags: `grimoire/scripts.md`. Never let a script *score* visuals — that is the agent's job.\n\n1. **Analyze the image first** (agent vision, before any script): work the layered observation\n protocol in `grimoire/intake/image_analysis.md` — identify/classify, decompose macro→meso→micro,\n map part relationships, name materials in PBR terms, list identity-defining features, and flag\n what the single view hides. Observation before inference; controlled 3D vocabulary; 3D\n object-space not 2D image-space. This is generic for any subject and feeds every field below.\n Then probe local images: `forge/stage1_intake/probe_image.py ` (metadata only, not a visual check).\n1a. **Local Spec Search** — after image analysis and before writing or refining a spec, local\n evidence is a pipeline stage, not an optional memory lookup, whenever the request needs\n domain-specific anatomy, PBR, wear, geometry, runtime, or physics specifications. The pre-spec\n command automatically runs BM25, chooses `cs2` for CS2 targets and `core_3d` otherwise, and\n writes a `localSpecSearch` evidence bundle into the assessment:\n `python3 forge/stage2_spec/new_pre_spec_assessment.py \"Name\" --image --out assessment.json`.\n Add observed terms with repeatable `--spec-query \"\"`; use `--collection ` only\n when the automatic collection choice is insufficient. `new_sculpt_spec.py --assessment` carries\n that bundle into the final spec, including snippets, `source_refs`, and `evidence_refs`.\n For extra focused retrieval, the direct CLI remains available:\n `python3 forge/stage1_intake/search_specs.py \"\" --collection --limit 3 --snippet-chars 250 --json`.\n For CS2, include the anatomical and the colloquial name, for example\n `--spec-query \"safety ring finger ring\"` or `search_specs.py \"roughness matte\" --collection cs2`.\n Expand queries with object names,\n component names, material/finish terms, behavior terms, and known aliases; retry focused\n alternatives when the first result is incomplete. Build the spec from returned evidence and do\n not invent domain specs when local evidence exists. Search caches are local/generated only;\n preserve JSONL records and source provenance rather than replacing them with cache output.\n1aa. **Optional fidelity evidence adapters** — use them only when they improve an observed weak\n point; the stdlib core remains authoritative. Route thin/complex masks to local SAM2, character\n face/pose evidence to MediaPipe, and weak front/back cues to Depth Anything V2:\n `python3 forge/stage1_intake/run_vision_adapter.py ...`.\n Every adapter emits provenance. Confirm SAM2 selected the intended component; treat monocular\n depth as relative only; review landmarks before copying them into anatomy. For browser work,\n prefer Chrome DevTools MCP for live console/network/performance diagnosis, use\n threejs-devtools MCP read-only to inspect scene/material/renderer state, and reserve Playwright\n MCP for cross-browser or host fallback. MCP-only scene mutations never count as implementation:\n write the proven change back to the spec or TypeScript, rebuild, and recapture. Use Context7\n only with the target project's installed Three.js version; local types, typecheck and runtime\n smoke tests override live docs. Full routing and commands:\n `docs/integrations/reference_fidelity_tooling.md`.\n1b. **CS2 intake manifest** — for a CS2 request, create and validate `cs2-intake.json` before\n pre-spec authoring. Run admission and probing for every source view, record the heuristic signal\n as non-authoritative evidence, attach the classification record, resolve the supported family,\n and choose `route` independently from `exactnessTier`. Missing classification, insufficient\n coverage, or a contradictory high-confidence class is `request-input`; unsupported families do\n not continue into spec generation.\n2. **Pre-Spec Assessment Gate** — classify + score complexity + write the quality contract:\n `forge/stage2_spec/new_pre_spec_assessment.py \"Name\" --image --complexity --out assessment.json`. Rules: `grimoire/intake/quality_contract.md`.\n Set `objectClass.primaryDomain` (`object` | `character` | `hybrid`) and fill the seeded\n `detailInventory` (its `targetMinDetails` scales with complexity). **Supported CS2 knife skins\n and Glock-18 assets**: always pass `--cs2`, which defaults the complexity tier to `ultra-complex`\n (`targetMinDetails` 16) — the finish/wear/hardware is the item, so CS2 is held to the top\n fidelity bar; `targetMinDetails` never drops below the 9 floor even if downgraded by hand.\n **Author procedural GEOMETRY (blade/guard/grip profiles) but make the FINISH a de-lit\n reference-crop PROJECTION, not a procedural finish material** — projecting the photo's own\n pixels is what reaches reference fidelity for patterned skins (Doppler/Gamma/Marble/Fade), and\n is what the v1.3 baseline demos do; a procedural finish for a patterned skin reads visibly wrong\n against the reference. Take the projection path in step 2c (it generalizes from characters to\n any reference-matched surface). Procedural finish is the fallback ONLY when live view-dependent\n response matters more than matching this one reference. Finish routes + rulebook:\n `grimoire/build/cs2_finishes.md`; optional exact-texture acquisition:\n `grimoire/intake/cs2_texture_acquisition.md`.\n1a. **Local Spec Search** — after image analysis, before writing or refining a spec, pull local\n domain evidence (anatomy/PBR/wear/geometry/runtime/physics) rather than inventing it:\n `python3 forge/stage2_spec/new_pre_spec_assessment.py \"Name\" --image --out assessment.json`\n (auto-runs BM25, auto-picks `cs2`/`core_3d` collection, writes a `localSpecSearch` bundle that\n `new_sculpt_spec.py --assessment` carries into the spec). Full query-expansion recipe\n (bilingual terms, focused `search_specs.py` retrieval, cache rules):\n `grimoire/intake/local_spec_search.md`. MUST read it before retrying an incomplete or\n domain-specific query.\n1b. **CS2 intake manifest** — for a CS2 request, create and validate `cs2-intake.json` before\n pre-spec authoring (admission, heuristic signal, classification, family/route resolution).\n MUST read `grimoire/intake/cs2_intake_contract.md` completely before creating the manifest or\n running pre-spec assessment.\n2. **Pre-Spec Assessment Gate** — classify + score complexity + write the quality contract:\n `forge/stage2_spec/new_pre_spec_assessment.py \"Name\" --image --complexity --out assessment.json`. Rules: `grimoire/intake/quality_contract.md`.\n Set `objectClass.primaryDomain` (`object` | `character` | `hybrid`) and fill the seeded\n `detailInventory` (its `targetMinDetails` scales with complexity). **Supported CS2 knife\n skins**: always pass `--cs2`, which defaults the complexity tier to `ultra-complex`\n (`targetMinDetails` 16, floor 9) — the finish/wear/hardware is the item, so CS2 is held to the\n top fidelity bar. Author procedural GEOMETRY but route the FINISH through the projection path in\n step 2c — a procedural finish for a patterned skin (Doppler/Gamma/Marble/Fade) reads visibly\n wrong against the reference. Finish routes + rulebook: `grimoire/build/cs2_finishes.md`;\n optional exact-texture acquisition: `grimoire/intake/cs2_texture_acquisition.md`.\n2b. **Detail inventory** (do not skip for detailed subjects) — scan zones and enumerate every\n identity-defining small detail (gloss, bevel, fasteners, linework, contours, stains):\n `forge/stage1_intake/build_detail_inventory.py --mode grid-3x3 --out-dir --out di.json`.\n Each detail MUST map to a `component.localFeatures` or `material.localOverrides` entry — never\n prose only. Taxonomy + 3D-term recipes: `grimoire/intake/detail_inventory.md`.\n2c. **Projection-first fidelity (characters AND reference-matched surfaces — supported CS2 skins, decals,\n painted patterns)** — when the goal is matching a specific reference's surface, put the photo's\n own pixels on the mesh instead of approximating them procedurally. This is the single biggest\n fidelity lever; a procedural material for a patterned surface is the #1 reconstruction failure.\n Recipe (`grimoire/character/likeness_maximization.md` — its two levers, align-mesh+camera and\n project-the-photo, generalize past characters): solve the camera\n (`stage1_intake/solve_camera_pose.py` → `referenceCamera`), **de-light** the reference so it is\n free of baked lighting (`stage1_intake/delight_albedo.py`, hard requirement — this is what makes\n projection safe, not the flat-lit icon), then project the de-lit crop onto the mesh and bake it\n into UVs (`stage3_build/bake_projected_texture.py --mesh-id `). For a CS2 skin the mesh is the\n procedural family-specific component tree you author in the spec, and the projected de-lit crop IS the finish\n (front + back from the two views) — no procedural Doppler material. For characters, first capture\n landmarks (`stage1_intake/extract_landmarks.py --out anatomy.json`), fill `preSpecAssessment.anatomy`,\n route `grimoire/character/reconstruction.md`. A single view cannot show hidden sides — report\n per-region confidence and request more views when it matters.\n Character sub-routes, in the order they are needed — decide what parts exist before shaping any\n of them, and shape the head before the hair that sits on it:\n - **Parts** — `grimoire/character/structure_decomposition.md`: which parts the figure is made of,\n and where each one's boundary falls.\n - **Head** — `grimoire/character/head_construction.md`: skull, face plane and feature placement,\n the sub-route the likeness gate reads against.\n - **Hair** — `grimoire/character/stylized_hair_threejs.md`, with the parameter contract in\n `grimoire/character/threejs_hair_parameter_contract.json`. Lock topology first: material\n tuning cannot repair wrong lock topology, so run it only after the silhouette review passes.\n2d. **Reference-free humanoid** — when the request is a generic figure with no reference image\n (\"a low-poly humanoid\"), there is nothing to measure, so fill anatomy from public canon with\n `forge/stage2_spec/humanoid_proportions.py --style-heads 8 --in-place`. It writes\n `anatomy.source: \"canon-table\"` so canon is never mistaken for measured evidence, refuses to\n run at all when the spec names a reference image, and lists what the corpus does NOT supply\n under `anatomy.unsourced`. Only complete head counts are derivable (currently 8); anything\n else fails with the missing landmark named rather than being interpolated.\n3. Author the spec from the assessment:\n `forge/stage2_spec/new_sculpt_spec.py \"Name\" --image --assessment assessment.json --manifest cs2-intake.json --out object-sculpt-spec.json`.\n Replace generic starter `featureReviewTargets` with the object's real identity-defining\n systems (≤5 critical, ≤3 important per pass); for characters add `anatomy-proportion`,\n `face-landmark-placement`, `pose-silhouette`, `outfit-and-palette`. Use 3D-graphics terms only\n (`grimoire/glossary/3d_vocabulary.md`), never \"nice/smooth/shiny\". Classify every component's\n `topologyClass`/`topologyRationale` per `grimoire/intake/surface_topology.md` before picking a\n `primitive` — this is what prevents a continuous organic form from being picked as a box.\n4. When material fidelity matters and a source image exists, analyze each material's **finish** then\n extract reference PBR evidence, both per crop (crop the correct region — verify the crop is on the\n part you think it is):\n - `forge/stage1_intake/analyze_texture.py --spec spec.json --material-id --in-place`\n classifies the finish (`gem-metal | gemstone | painted-metal | worn-composite | brushed-steel |\n plastic`), extracts the gradient palette, and writes doc-grounded MeshPhysicalMaterial scalars\n (metalness/roughness/clearcoat/transmission/ior/anisotropy/envMapIntensity) onto the material.\n Recipes + Three.js texture/PBR rules (colorSpace, CanvasTexture/DataTexture, height→normal) live\n in `grimoire/build/threejs_texture_reference.md`. Rule of thumb: **solid albedo for flat paint,\n real reference crop for patterned finishes** (doppler/quartz/hydro-dip/camo).\n - `forge/stage1_intake/extract_pbr_evidence.py --out-dir --material-id --target-threshold 0.7`.\n Confidence < 0.7 is a stop/refine-input signal, not a pass. It is inference, not inverse rendering.\n - For multiple named regions, use `forge/stage1_intake/material_region_analysis.py --manifest regions.json --out-dir material-evidence --out material-analysis.json`. Resolve each accepted assignment from `docs/materials/material-reference.json`, then wire it into the spec with `forge/stage2_spec/apply_material_analysis.py`.\n - Emit the controlled material camera/crop contract with `forge/stage4_review/material_views.py`, compare saved visible-footprint crops with `forge/stage4_review/material_comparator.py`, apply only bounded material-scoped corrections with `forge/stage4_review/material_feedback.py`, and record the blocking result with `forge/stage4_review/material_gate.py`.\n5. Validate, then strict-validate before generating code:\n `forge/stage2_spec/validate_sculpt_spec.py object-sculpt-spec.json` then `--strict-quality`.\n Strict blocks shallow specs (a complex object with one root, no repetition systems, no\n local overrides, no micro groups is NOT implementation-ready even if JSON validates).\n6. **Locked build passes** — only touch the currently unlocked pass:\n `forge/stage3_build/orchestrate_passes.py status object-sculpt-spec.json`\n `forge/stage3_build/generate_threejs_factory.py object-sculpt-spec.json --out src/createObjectModel.ts`\n (generator is fail-closed: `strict-quality` must pass before it can write any factory; a future\n `--pass-id` also fails until prior passes are reviewed `continue`). If blocked, preserve the\n `BLOCKED` artifact and refine the subject-specific spec; do not substitute a generic template.\n6a. **Hitting a triangle budget.** `performanceBudget.targetTriangles` selects a tessellation\n tier for every primitive that has segment counts (low ≤6k, standard ≤60k, else hero), and\n caps implicit-surface sampling grids. Where that is not precise enough — an SDF's grid is\n quantised, so a tier can only get near a number — add\n `geometryDescriptor.decimate: {\"targetRatio\": 0.4}` to that component. It emits a\n Garland-Heckbert quadric collapse into the generated factory and runs **before** skin\n binding, so weights are computed on the surviving vertices and no skinning data is\n interpolated across a vertex merge. It keeps `position` only, recomputing normals, so it is\n refused on an authored/unwrapped `uvStrategy`. For offline LOD tiers from an exported mesh,\n `forge/stage3_build/decimate.py --ratio --json` is the same algorithm.\n7. Render the current pass in a browser/preview, capture a screenshot at a review viewpoint.\n7a. **Off-axis and placement gates — a single review viewpoint is not evidence about the model.**\n Capture a turntable, not one frame, and run all three. Each catches a defect class the older gates\n pass by construction; skipping them is how a hole through a skull, a hat at hip height and a charm\n floating below the ground plane survived eight front-only review rounds.\n `forge/stage4_review/turntable_gate.py --capture 0=front.png --capture 90=right.png --capture 180=rear.png --capture 270=left.png --json`\n `node runtime/scripts/export_mesh_geometry.mjs --url --out meshes.json` then\n `forge/stage4_review/self_intersection.py meshes.json --json`\n `forge/stage4_review/attachment_anchor.py object-sculpt-spec.json --measured measured.json --json`\n All three exit `0` clean / `1` gate failure / `2` error. A failure blocks `continue` for the pass\n even when the global fidelity score passes — the score is computed from one camera and a 64×64 luma\n grid, and neither can represent any of these defects. Read `sampledVertexCount` /\n `unmeasuredAttachments` / `missingAzimuths` before believing a clean verdict: each names the part of\n the model the gate did not actually look at.\n8. Package one side-by-side sheet, then inspect it with agent vision:\n `forge/stage4_review/make_comparison_sheet.py --reference --render --out cmp.png --json`.\n9. Record the review (overall + per-layer + per-feature scores + decision):\n `forge/stage4_review/append_review.py object-sculpt-spec.json --pass-id --fidelity <0-1> --action --summary \"...\" --render-screenshot --comparison-image cmp.png --ai-vision-score <0-1> --layer-scores-json '{...}' --feature-reviews-json --in-place`.\n For the CS2 family path, also attach the versioned report with\n `--cs2-review-json cs2-review.json --review-scene-json forge/tests/fixtures/knife_review_scene.json`.\n A failed family, painted-region, projection-coverage, critical-detail, or orbit gate blocks\n `continue` even when the global score passes. See `docs/cs2/review-gates.md`.\n10. Sync pipeline state after manual review edits:\n `forge/stage3_build/orchestrate_passes.py sync object-sculpt-spec.json --in-place`.\n\n## Forge Runtime Contracts\n\nSubdivision runtime tests compile generated TypeScript against the showcase checkout. Set\n`IMG2THREEJS_SHOWCASE_ROOT` to that checkout; without it, local runtime-only tests skip with an\nactionable message while static contracts still run. CI should set `IMG2THREEJS_REQUIRE_SHOWCASE=1`\nto turn a missing showcase checkout into a test failure.\n\n```bash\nIMG2THREEJS_SHOWCASE_ROOT=/path/to/img2threejs-showcase python3 forge/tests/test_subdivision.py\nIMG2THREEJS_SHOWCASE_ROOT=/path/to/img2threejs-showcase python3 -m unittest discover -s forge/tests\nIMG2THREEJS_SHOWCASE_ROOT=/path/to/img2threejs-showcase python3 forge/tests/test_showcase_tsc_smoke.py\n```\n (generator is pass-gated: a future `--pass-id` fails until prior passes are reviewed `continue`).\n The local state adds `--force` only for a new pass or `refine-spec`; `refine-code` edits the\n current artifact without regenerating it. Before overwriting, carry valid hand refinement back\n into the spec; generated code must not be the only copy of reconstruction decisions.\n7. Render the current pass in a browser/preview, capture a screenshot at a review viewpoint.\n8. **Run deterministic gates before AI vision.** MUST read\n `grimoire/review/gates_reference.md` and `grimoire/review/self_correction.md` completely. Run\n `forge/stage4_review/diagnose_render.py` and record the passing Tier 1 result with\n `--spec object-sculpt-spec.json --pass-id --in-place`; for non-planar forms also run\n `forge/stage4_review/diagnose_render_multi_angle.py` with the fixed view and at least two\n meaningful orbit views. Then run\n `forge/stage3_build/orchestrate_passes.py check object-sculpt-spec.json --pass-id `.\n9. Package one side-by-side sheet, then inspect it with agent vision:\n `forge/stage4_review/make_comparison_sheet.py --reference --render --out cmp.png --json`.\n10. Record the review (overall + per-layer + per-feature scores + decision):\n `forge/stage4_review/append_review.py object-sculpt-spec.json --pass-id --fidelity <0-1> --action --summary \"...\" --render-screenshot --comparison-image cmp.png --ai-vision-score <0-1> --layer-scores-json '{...}' --feature-reviews-json --in-place`.\n For the CS2 knife path, also attach the versioned report with\n `--cs2-review-json cs2-review.json --review-scene-json forge/tests/fixtures/knife_review_scene.json`.\n Produce that report first with\n `forge/stage4_review/cs2_review.py --manifest cs2-intake.json --metrics cs2-review-inputs.json --scene forge/tests/fixtures/knife_review_scene.json --out cs2-review.json`.\n A failed family, painted-region, projection-coverage, critical-detail, or orbit gate blocks\n `continue` even when the global score passes. See `docs/cs2/review-gates.md`.\n11. Sync pipeline state after manual review edits, record checklist evidence, then re-run the local\n state gate before another correction or pass:\n `forge/stage3_build/orchestrate_passes.py sync object-sculpt-spec.json --in-place`\n `python3 forge/next.py --state .img2threejs/state.json object-sculpt-spec.json`.\n12. Before declaring completion, run\n `forge/stage4_review/check_part_coverage.py --spec object-sculpt-spec.json --manifest parts.json`\n and verify the action-ready hierarchy. Mark `part-coverage` and `action-ready` only with evidence.\n\n## CS2 image-matched rule\n\nFor a CS2 item, the target is observable agreement between the supplied image and the rendered\nitem: silhouette, proportions, edge profile, hardware layout, coating colour, pattern placement,\nwear, roughness response, and camera framing. Every decision must be traceable to evidence or be\nlabelled as an approximation.\n\nThe initial CS2 family boundary covers supported **knife** subtypes and the **Glock-18** pistol\nadapter. Rifle, SMG, sniper, heavy, glove, unsupported pistol, and unknown knife subtypes must stop\nwith `unsupported-family` or `unsupported-subtype`; they must not receive another family's component\ntree as a generic fallback.\n\n### Layer contract\n\nPass these records between layers. Do not copy an informal vision description into the next stage:\n\n| Layer | Owns | Must emit | Must not decide alone |\n| --- | --- | --- | --- |\n| Intake | view validity and technical evidence | role, path/hash, resolution, coverage, duplicate status, admission verdict | item identity from aspect ratio or filename |\n| Classification | semantic identity | family, subtype, confidence, evidence refs, provider/version, timeout state | geometry or finish parameters |\n| Identity | skin/name/paint metadata | precedence, resolved values, ambiguity candidates, provenance | guessed paint index, float, or seed |\n| Surface evidence | pixels and texture sources | de-lit reference, PBR channels, map provenance, colour space, UV orientation, confidence | albedo reused as roughness/normal/AO |\n| Geometry adapter | family-specific form | component tree, topology, dimensions, edge/spine, hardware relationships, painted regions | hidden geometry without confidence notes |\n| Spec/route | evidence-backed implementation choice | route, exactness tier, assumptions, feature targets, camera contract | exact-texture claim without exact evidence |\n| Build/review | rendered observables | fixed view, two non-degenerate orbit views, per-region results, failed gates, next action | overriding a failed critical feature with a global score |\n\nThe canonical hand-off is `cs2-intake.json` (`schemaVersion: 1`). Its state is one of\n`proceed`, `request-input`, `fallback`, `rejected`, `unsupported-family`, or\n`unsupported-subtype`. Write it atomically and preserve unknown provider fields under\n`extensions`; a fallback must never erase prior evidence.\n\n### CS2 intake order\n\n1. Admit and technically probe every view. Reject undecodable, empty, tiny, fragmented, or\n duplicate references before classification.\n2. Record the heuristic CS2 signal only as a routing hint. `detect_cs2.py` is never authoritative\n identity evidence.\n3. Require a classification record before selecting a family adapter. If classification is absent,\n timed out, or contradicts a high-confidence objectness result, return `request-input`.\n4. Resolve identity in this order: explicit user metadata, uniquely resolved metadata, then the\n authoritative classification record. Preserve ambiguity rather than guessing.\n5. Select route and exactness independently:\n - `reference-projection`: default for matching a specific patterned image;\n - `authored-texture`: only when independent texture maps are supplied or legally acquired;\n - `procedural-finish`: fallback when projection evidence is unavailable or live response is the\n stated priority.\n Exactness is `image-only`, `metadata-assisted`, or `exact-texture`; changing route must not\n silently upgrade or downgrade the evidence tier.\n6. Select the family adapter only after family/subtype validation. Record painted regions, unpainted\n substrate, visible hardware, hidden-region confidence, and every approximation in the spec.\n7. For projection, solve the camera and de-light the source first. Projected pixels provide colour\n evidence, not automatic geometry truth; geometry still comes from the adapter and silhouette\n review.\n\n### Surface and review rule\n\nFor a specific CS2 reference, preserve the reference's own colour/pattern pixels whenever legal and\ntechnically possible. Procedural Doppler/Fade/Gamma/Marble patterns are not equivalent to the input\nimage and may only be used with an explicit `procedural-finish` route and approximation warning.\nKeep albedo, roughness, metalness, normal/height, AO, mask, and wear as independent channels. Record\nchannel source, colour space, UV orientation, dimensions, packed-channel decoding, and missing-channel\nderivation. A low-confidence PBR inference is a refine-input signal, not proof of exact material.\n\nSingle-view reconstruction may proceed only when visible identity features are sufficiently covered;\nhidden blade sides, underside, and back hardware must carry inference confidence and may trigger\n`request-input`. Review the fixed camera plus two meaningful orbit views. Report what changed, which\nevidence caused it, what still differs, and choose exactly one next action:\n`continue`, `refine-spec`, `refine-code`, `request-input`, or `stop`.\n\n## Gates (do not skip)\n\n- **Suitability + reference integrity**: pass / conditional / reject before any planning\n (`grimoire/intake/validation_rubric.md`), AND every reference admitted via\n `forge/stage1_intake/check_reference_admission.py` (rejects empty/fragmented/tiny/duplicate/\n undecodable refs with a reason). Intake understanding cross-checked by\n `forge/stage1_intake/check_intake_correctness.py` (halts on a confident class contradiction).\n- **Divine Eye (the harness heart) — deterministic-first, model-last**: the render evaluator is\n `forge/stage4_review/divine_eye.py` — a zero-token multi-signal ensemble (IoU/scale HARD gates;\n proportion/symmetry-parity/pHash/SSIM/edge/blowout/flat/tonal-parity soft) with self-uncertainty\n (`probe` on signal disagreement) and deterministic routing (`continue`/`refine-spec`/`refine-code`/\n `probe`). The VLM (`forge/stage4_review/vlm_gate.py`) is a gated, calibrated, cross-checked\n last layer: **never consulted on a hard-gate failure**, multi-sample-voted, and can rescue a\n soft near-threshold reject but never grant past a hard geometric failure.\n- **Multi-angle or it didn't happen**: a non-planar form must hold from ≥2 camera angles.\n `forge/stage4_review/diagnose_render_multi_angle.py` flags `degenerate-view` when an orbited\n silhouette collapses (a flat plane faking a volume). Orbit angles use reference-free\n self-consistency — never scored against a reference angle the photo doesn't cover.\n- **CS2 review contract**: `forge/stage4_review/cs2_review.py` consumes the manifest and\n versioned scene fixture, then blocks wrong family identity, missing projection coverage,\n painted-region mismatch, critical identity-detail failure, finish/material response failure,\n and degenerate orbit form. It records exactness tier, hidden-region confidence, per-region\n confidence, approximation notes, camera, environment hash, exposure, tone mapping, resolution,\n background, and renderer version.\n- **Bounded correction loop (token-burn safety)**: `forge/stage4_review/correction_loop.py`\n guarantees termination: hard gates route to `refine-code`; repeated defects and oscillation route\n to `refine-spec`; plateau and the hard ceiling route to `request-input` — never a silent infinite\n burn. Deterministic analysis-by-synthesis parameter fitting and Divine Eye provenance are\n documented in `grimoire/build/analysis_by_synthesis_fitting.md`.\n- **Executable Divine Eye fitting**: `fit_against_divine_eye()` in\n `forge/stage4_review/fit_params.py` connects deterministic parameter-to-render callbacks to\n bounded gate-aware Divine Eye optimization. Clean candidates use raw fidelity; hard-gated\n candidates score below all clean results while retaining original fidelity and provenance. The\n returned objective and optional selected raw fidelity are explicit, and each copied record has\n candidate/reference/render provenance. It lazily loads the default evaluator and returns\n normalized raw-fidelity correction-loop provenance without mutating sources.\n- **Tier 1 (legacy, still valid)**: \"Tier 2 (AI-vision) never runs against a render that has not passed Tier 1.\" Run `forge/stage4_review/diagnose_render.py` (silhouette IoU/proportion/symmetry/per-part color) and record it (`--spec ... --in-place`) before requesting a comparison sheet; `orchestrate_passes.py check` refuses otherwise.\n- **Pre-spec / strict-quality**: blocks code gen until the spec is deep enough for its contract.\n- **Screenshot feedback**: `continue` is allowed only with a render + comparison sheet + global\n AI-vision score ≥ threshold (default 0.7) AND every critical feature ≥ its own threshold.\n Details + per-layer scorecard: `grimoire/feedback/render_capture.md`.\n- **Action-ready**: build a runtime hierarchy (pivots, sockets, colliders, destruction groups),\n never an inert lump; expose `root.userData.sculptRuntime`. `grimoire/readiness/action_rigging.md`.\n- **Procedural rig contract (1.5-alpha)**: for humanoid/character builds, validate the authored\n `joints`/`parents`/`names`/`matrix_local`/packed skin payload with\n `forge/stage5_rig/validate_rig_payload.py` before binding `THREE.Skeleton`. The gate proves\n structural payload integrity only; pose stress, dynamic bounds, readable screenshots, and\n visual likeness remain separate gates. Payload ownership and non-goals:\n `grimoire/readiness/procedural_rigging_contract.md`.\n- **Assembly gate (structure, not pixels) — every model ships explodable AND clickable**: this is\n a build requirement, not a per-project extra. Name every mesh; flag surface relief\n `userData.explodeWithParent` so it rides its shell; let a named group of *anonymous* meshes be one\n part while a named group of *named* parts stays a container. Explode and part-picking must share\n one definition of \"a part\" — if they disagree, both are wrong. Separate parts by SCALING the\n layout about the model centre, never by pushing every part the same distance (that translates the\n arrangement without opening any gap). Then run\n `forge/stage4_review/check_part_coverage.py --spec --manifest `: it FAILS on a\n specified component that was never built and on two components fused onto one mesh; it warns on\n inventoried details that never reached the spec and on meshes belonging to no named part. This is\n the only gate that scores STRUCTURE — every other one scores pixels, and a single fused mesh\n wearing a projected photo passes all of those. Its limit is honest and must be stated when\n reporting: it proves you built what you specified, never that you specified enough.\n Full contract + the two rules it took a wrong pass to learn: `grimoire/build/geometry_patterns.md`.\n- **Attachment**: child appendages (branches/limbs/handles/tubes) need `attachment.parentSocket`,\n `localStart`, `localEnd`, `contactType`, `embedDepth`/`overlap`, `gapTolerance` — no mid-air parts.\n `grimoire/readiness/joint_attachment.md`.\n- **Material/lighting**: `grimoire/feedback/shading_realism.md` — independent PBR channels\n (never alias albedo into roughness/normal/AO), macro/meso/micro frequency bands, real lights.\n- **Detail inventory**: for `moderate`+ subjects strict-quality blocks code gen until the\n `detailInventory` reaches `targetMinDetails` and every detail maps to a real component/material\n entry (gloss needs low-roughness/clearcoat; fasteners need instancing/micro parts).\n- **Character track**: when `primaryDomain` is `character`/`hybrid` (or `--character`), the spec\n author auto-builds a stylized humanoid template (head/neck/torso/arms + hair, glasses,\n headphones, face features), flattened to world space under a hidden root, with per-part\n character materials and character build passes (`proportion-lock`, `feature-placement`).\n strict-quality requires a filled `anatomy` block (head-units, proportions, face landmarks) and\n character feature targets. Suitability routing for humans: `grimoire/intake/validation_rubric.md`\n (stylized vs maximum-likeness). Stylized bust, not a face-copy; refine positions per reference.\nThe initial CS2 family boundary is **knife only**. Pistol, rifle, SMG, sniper, heavy, glove, and\nunknown knife subtypes must stop with `unsupported-family` or `unsupported-subtype`; they must not\nreceive the knife component tree as a generic fallback.\n\nFor every CS2 reconstruction, MUST read the full layer contract, intake order, and surface/review\nrule in `grimoire/intake/cs2_intake_contract.md` before intake state can advance.\n\n## Gates (do not skip)\n\nBefore any visual review or `continue` decision, MUST read the full gate-by-gate contract in\n`grimoire/review/gates_reference.md` (Divine Eye, VLM rescue, multi-angle, CS2 review, bounded\ncorrection, screenshot feedback, assembly, attachment, material, detail inventory, character\ntrack). In short:\n\n- Validate references first (`grimoire/intake/validation_rubric.md`, `check_reference_admission.py`).\n- `divine_eye.py` is deterministic-first; the VLM (`vlm_gate.py`) is a gated last layer, never\n consulted on a hard-gate failure.\n- A non-planar form must hold from ≥2 angles (`diagnose_render_multi_angle.py`).\n- CS2 knife builds also run `cs2_review.py` against the versioned scene fixture.\n- Local state enforces 3 corrections per pass and 6 total by default; reaching either limit is a\n hard stop. `correction_loop.py` may stop earlier on repeated defects, oscillation, or plateau.\n- `continue` requires a render + comparison sheet + AI-vision score ≥ threshold, every critical\n feature ≥ its own threshold (`grimoire/feedback/render_capture.md`).\n- Every model ships explodable AND clickable — a structure gate, not pixels\n (`check_part_coverage.py`, `grimoire/build/geometry_patterns.md`).\n- Action-ready, attachment, material/lighting, detail inventory, and character-track requirements:\n `grimoire/readiness/action_rigging.md`, `grimoire/readiness/joint_attachment.md`,\n `grimoire/feedback/shading_realism.md`, `grimoire/intake/quality_contract.md`,\n `grimoire/intake/validation_rubric.md`.\n\n## Self-Correction\n\nAfter every pass, decide exactly one: `continue | refine-spec | refine-code | request-input | stop`.\n`refine-spec` fixes a wrong/missing/shallow spec (re-validate, don't patch code around it);\n`refine-code` fixes geometry/material/lighting that doesn't match a sound spec. Before making the\ndecision, MUST read the root-cause guide + fidelity scale in `grimoire/review/self_correction.md`,\nrecord the decision, and re-run the local state gate.\n\n**Small features need a different instrument.** Divine Eye's SSIM/tonal/edge signals run on a 64×64\nluma grid and a 96×96 edge grid, so a detail a few pixels wide in the reference is not scored badly —\nit is absent before any comparison happens, and `per_feature.py` cannot compensate because it consumes\na scores dict and never opens an image. When fidelity depends on individual tears, spars, fangs or\neyes, use the four-tier microscope: `grimoire/review/divine_eye_microscope.md`. Two rules there are\nempirically established rather than proposed, and both produced confident false findings before being\nunderstood: measure fidelity on a component's **visible footprint** (the full frame minus a\ncomponent-hidden frame), never on an isolation render, which reveals geometry the reference cannot\nsee; and never colour-gate a **concave** feature, where a dark ratio captures cavity shading rather\nthan material.\n\n## Implementation Rules (brief)\n\nTypeScript + plain Three.js unless the project uses a wrapper. `Group` factory\n`createObjectNameModel(spec, options)`, reconstruction data kept separate from renderer objects,\ndeterministic seeds for all procedural noise. Prefer primitives / `Shape` extrude / curve+tube /\ninstancing / displacement / generated canvas textures before any external art. Full geometry &\nmaterial recipes + hard-won failure patterns: `grimoire/build/geometry_patterns.md`.\n\n### Optional Python ↔ Three.js render bridge\n\nWhen Python is requested for character rendering, use it as a deterministic job/evidence layer\naround the browser Three.js runtime: camera-batch manifests, source/output hashes, readiness and\nsettle checks, screenshot persistence, masks, diagnostics, and comparison packaging. The target\nThree.js browser route remains the rendering authority. Do not silently replace the procedural\nTypeScript factory with Blender/VRM/GLB output. Full routing, manifest fields, and failure rules:\n`grimoire/build/python_threejs_render_bridge.md`.\n\n### Standard character pipeline (merged 1.5 beta + alpha)\n\nUse `grimoire/readiness/standard_character_pipeline.md` for character work. Beta owns the\nstrict sculpt/build/review gates; alpha owns deterministic camera manifests, browser screenshot\nevidence and UniRig-shaped rig validation. CharacterGen, Tripo, VRM and other neural/asset\nsystems are opt-in adapters with source, checkpoint, license, coordinate conversion and output\nhashes. They never silently replace the procedural TypeScript factory. Image-to-mesh systems emit a\nstatic mesh with no skeleton, so their output is never animation-ready however good it looks; neural\nriggers are offline inference whose value here is the serialized payload, not a browser dependency.\n\nExecutable entry points are `forge/stage4_review/render_bridge.py` and\n`scripts/capture_threejs_playwright.py`. Run `init → browser capture → validate → diagnose`;\ncapture must operate on the real showcase/browser route and leave readable PNGs in the workspace.\n\n## Output\n\n- **Analysis-only**: suitability verdict + scores, object extraction, macro→micro hierarchy,\n geometry strategy, material/lighting recipe, animation/destruction feasibility, plan + risks.\n- **Implementation**: the above briefly, then edit code; verify with typecheck/build + a screenshot.\n- **Not feasible**: name the blocker, ask for more views / cleaner image / accepted stylization /\n a narrower target. \"This cannot reach the requested fidelity from this image\" is a valid result.","skillMdTruncated","frontmatter",{"_153":157,"_38":26,"_43":44,"_268":269},"version","1.4.4","totalSizeBytes",121868,"runtime",{"_274":7,"_275":7,"_276":-5,"_277":7,"_278":31,"_279":7,"_280":281,"_282":283},"requiresBash","requiresMcp","model","requiresNode","requiresNetwork","requiresPython","allowedTools",[],"dependencies",[],"install",{"_286":287,"_288":166,"_289":138,"_290":291,"_292":293},"cli","npx skills add img2threejs/img2threejs","coordinate","browseUrl","downloadUrl","https://github.com/img2threejs/img2threejs/archive/refs/heads/main.zip","gitUrl","https://github.com/img2threejs/img2threejs.git","createdAt","2026-08-11T01:21:01.087Z","updatedAt","2026-08-12T10:18:32.125Z","hasNext","page","actionData","errors"]