AGENT SKILL

build-proof-to-model-assets

Produce reviewed 3D assets through original-source classification, a human-approved six-angle proof set, native Pixal3D multi-view reconstruction and audited Blender finishing. Use for PROOF_TO_MODEL asset production, revisions, recovery and review evidence.

License 许可
MIT
最近更新
2026-11-13
Stars
★ 4
Forks
3

01 前言 Front Matter

name
build-proof-to-model-assets
engines
[ "AGNOSTIC" ]
description
Produce reviewed 3D assets through original-source classification, a human-approved six-angle proof set, native Pixal3D multi-view reconstruction and audited Blender finishing. Use for PROOF_TO_MODEL asset production, revisions, recovery and review evidence.

02 资源文件 14

03 SKILL.md 正文

Build Proof to Model Assets

When to use

Use when PROOF_TO_MODEL is resolved for 2D-to-3D asset production or when resuming its staged native workflow. Do not invoke reconstruction for ordinary CSS/SVG interfaces or silently change a selected pipeline.

Workflow

  1. Read architecture, STYLE.md, .styles/.pipelines/proof-to-model/PIPELINE.md and its recipe/toolchain/schema. Resolve selection with select-art-pipeline, recording prompt evidence when applicable.
  2. Inspect configured libraries with use-external-asset-library; preserve repository-local copy receipts and ancestry. Record scale, interfaces, rights, geometry/texture/collision budgets and rigging/animation applicability.
  3. Consult command/subcommand help. Use init to preserve authorized originals; use doctor and dry-run setup to inspect prerequisites. Execute setup only with explicit authorization and license evidence. Never accept licenses or install drivers.
  4. First inspect and research only the registered original images. Read source-subject-classification.md for entities, observed/inferred anatomy or structure, materials, occlusion and unresolved interpretations. Register the actual report with classify; native registration does not perform vision or research.
  5. Read multiview-proof-contract.md to plan front, subject-right, back, subject-left, top and bottom with one pose, identity and camera convention. If the sole source genuinely covers one angle, generate five missing views; an oblique/cropped source remains an anchor and may require six. New images/revisions require explicit CLOUD/LOCAL selection, MEDIA.md, rights and bounded spending authorization. Use the available session media capability, then register actual artifacts with prepare-proofs; the native command is not an image generator.
  6. Show originals and all six current proofs, resolve consequential inferred features, and obtain human approval bound to the complete set. Preserve rejected candidates and revise only selected views. Record proof-set approval before preprocess using the current status fingerprint named proofSet; preserve real alpha or explicit BiRefNet, every mask, common square padding and adjusted camera FOV. Inspect and approve preprocessing before reconstruct, which must consume all six separate images and the pinned MV model set.
  7. Run finish for UV/bake, LOD/collision and editable blend/GLB outputs. Default finishing requires measured successful QuadriFlow; optional schemaVersion1 settings may select bounded working-low preparation. For explicitly selected rigid/articulated finishing, read rigid-part-finishing.md: schemaVersion2 consumes reviewed authored HIGH/LOW pairs, exact part/repair ancestry and a supported native memory policy. Preserve the detailed high sources, actual material/atlas correspondence and all budgets. Settings never rewrite conditioning contracts, relax failed bounds or select a fallback automatically. Use only the fixed audited/hash-bound Blender 4.5 LTS bundle; this exception does not authorize arbitrary batch scripts or relax standalone BLENDER rules.
  8. Run review and validate; inspect independent re-import findings, original-source comparisons and six matching-camera proof/render pairs. Nominal camera alignment does not establish likeness or anatomical correctness. Route required rig/animation work through subject-specific skills with evidence before declaring readiness.
  9. Use record for current independent reviewer and separate human acceptance/rejection receipts. Check status; changed inputs invalidate affected proofs, approvals and dependent results. Use promote only after explicit current human acceptance and task authorization.

For model-to-animation production, hand the reviewed model to build-model-animations. Preserve original-only classification as source evidence; record new topology/articulation findings separately. Animation readiness may require neutral-pose or geometry repair work, especially fused limbs/equipment. Its motion package and complete-clip/runtime review do not inherit proof-set or static-asset acceptance.

Guardrails

  • Use the exact initialized and explicitly built runtime/bubo dependency through Hephaera's verified launcher. No sibling checkout or source-run fallback is allowed. Native process guards are not an OS sandbox.
  • No threshold matte fallback, placeholder stages, automatic human approval, hidden downloads, silent pipeline changes or unreviewed promotion.
  • Keep stage state under .hephaera/.cache/tasks/<task>/, candidates under .art-staging/proof-to-model/, tools under ignored .local/tools/proof-to-model/, and reviewed runtime packages under assets/models/.
  • Preserve failed attempts and immutable originals, hashes, model/tool/script/recipe identity and logs. An exhausted finishing budget requires an actual human decision and a current hash-bound --finish-budget receipt for exactly one more attempt; never reset counters or manufacture approval. Distinguish simulated-process tests from live engine and Blender acceptance.
  • Large solver inputs may use explicitly selected, measured quadriFlow.simplification with world-box vertices held by exact identity/coordinate checks, per-part input caps and full vertex/surface error checks. Preserve source preparation and all topology/component guards; never increase tolerances or caps automatically. Smaller input does not bound QuadriFlow's internal growth or certify visual quality.
  • Generated/revised proofs and reconstruction renders never become classification evidence. Hidden anatomy and unseen surfaces remain inferred design completions after approval.
  • Single-view diagnostics require explicit --mode single-view-diagnostic and use the separate proof approval kind; that receipt cannot approve a v2 proof set. No SV fallback, four-image subset or contact sheet may stand in for the six inference frames.

04 同仓库更多 Skills

TimothyMeadows
TimothyMeadows/Hephaera

verify-web3-game-lifecycle

Verify a game's selected Web3 asset, wallet, ownership and trading lifecycle with contract properties, canonical recovery, actual target evidence and separate release readiness.

★ 4
TimothyMeadows
TimothyMeadows/Hephaera

verify-onchain-game-assets

Verify exact on-chain game collection ownership and quantities at canonical blocks, reconcile inventory events, and design honest match admission. Use for ERC721/ERC1155 inventory, reorg recovery, reservations, or transfer-during-match rules.

★ 4
TimothyMeadows
TimothyMeadows/Hephaera

plan-web3-game-assets

Define an opt-in Ethereum, Base or Immutable game-asset lifecycle, including token identity, supply, rights, custody, game eligibility and chain-specific dependencies.

★ 4
TimothyMeadows
TimothyMeadows/Hephaera

integrate-game-wallets

Integrate explicit player-wallet connection, scoped SIWE authentication, authority invalidation and reviewed target-specific handoff without application-held player keys.

★ 4
TimothyMeadows
TimothyMeadows/Hephaera

integrate-game-asset-trading

Integrate explicitly selected game asset settlement with exact unsigned intents, scoped approvals, idempotent operations and canonical receipt reconciliation. Use for NFT listing, buying, cancellation, retries or marketplace integration.

★ 4
TimothyMeadows
TimothyMeadows/Hephaera

build-evm-game-contracts

Author and verify host-owned EVM game collections and explicit mint, burn, craft or admin rules with pinned Solidity tooling. Use for contract source and deployment candidates; deployment and player signing require separate authorization.

★ 4