Blender scene quality checker
Skill ThanhNguyxnOrg/blendops/skills/blender-scene-quality-checker
AI-native Blender workflow and skill pack for non-Blender users, built around official Blender MCP, Claude Blender Connector, and Blender CLI.
npx -y skills add ThanhNguyxnOrg/blendops --skill blender-scene-quality-checkerAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Apply multi-category readiness gates with pass/warn/fail and evidence-bound verdicts.
SKILL.md
5.1 KB, as published. Nobody here has run it
blender-scene-quality-checker
Purpose
Evaluate scene/workflow readiness honestly and consistently before any success claim.
Quick start
- confirm this skill fits your goal
- provide required inputs first
- keep runtime claims evidence-bound
- follow suggested next-skill handoff
When to use
- before readiness/export/handoff claims
- after planning pass
- during text-only/runtime eval reporting
When not to use
- as a replacement for evidence collection
- to fabricate confidence in missing artifacts
Trigger phrases
- "quality-check this scene"
- "is this ready"
- "evaluate pass warn fail"
Prerequisites / readiness
- plan output available
- criteria set available
- evidence state known (Produced/Not Produced/Not Run)
Input schema
Required inputs
- scene plan summary
- intended output criteria
- available evidence artifacts
Optional inputs
- target quality threshold
- destination-specific constraints
Assumptions to confirm
- whether runtime was executed
- whether artifacts are from this run vs pre-existing
Output schema
Primary output
- category-level pass/warn/fail matrix
Secondary output
- readiness verdict and blockers
Evidence / caveat output
- artifact status ledger
- explicit caveats and unknowns
Required laws
- ../../laws/evidence-before-done.md
- ../../laws/non-blender-user-language.md
- ../../laws/official-runtime-only.md
- ../../laws/no-arbitrary-python-interface.md
Official runtime boundary
No execution claims without evidence. Text-only and blocked modes must remain explicit.
Operating procedure
- Confirm evidence state and run mode.
- Validate subject clarity criteria.
- Validate composition/camera criteria.
- Validate lighting/material criteria.
- Validate scale/transform assumptions.
- Validate render/export readiness criteria.
- Validate GLB/web handoff clarity criteria.
- Assign pass/warn/fail by category.
- Determine blockers and conditional gaps.
- Produce final verdict (Ready/Conditionally Ready/Not Ready/Not Run).
Decision tree
- If runtime not executed → Not Run or Conditionally Ready (never Ready without evidence).
- If critical category fails → Not Ready.
- If all critical pass and only minor warnings remain → Conditionally Ready.
Playbooks
- Playbook A: text-only planning path
- Playbook B: runtime-ready path with evidence gating
- Playbook C: blocked runtime path with caveat-first reporting
Mode handling
Text-only mode
- evaluate planning quality only
- mark artifact statuses Not Run
Runtime-ready mode
- include real artifact checks when present
Blocked runtime mode
- keep verdict conservative
- list exact blockers and next actions
Validation checklist
- mode explicitly labeled
- artifact status ledger present
- category rubric complete
- blocker list complete
- caveats include user impact
- final verdict justified
- no unsupported success claims
- no non-official runtime guidance
- plain-language summary included
- next actions provided
Pass / Warn / Fail rubric
| Category | Pass | Warn | Fail |
|---|---|---|---|
| Subject clarity | Clear and aligned | Minor ambiguity | Unclear focal subject |
| Composition/camera | Coherent and purposeful | Some weak framing | Framing fails user goal |
| Lighting/material | Plan supports intent | Gaps need tuning | Major quality mismatch |
| Evidence integrity | Claims align with evidence | Partial evidence | Claims contradict evidence |
Failure handling
- Missing evidence: downgrade verdict and mark Not Run/Not Produced.
- Critical fail: mark Not Ready with remediation steps.
- Unknowns: keep Warn + explicit caveat.
Troubleshooting
- If all categories pass but no artifacts exist: ensure verdict is not Ready.
- If pre-existing files found: do not attribute to current run without linkage.
- If plan quality high but runtime blocked: use Conditionally Ready or Not Run.
Best practices
- score categories independently before final verdict
- keep caveats visible in final summary
- preserve traceability from category score to verdict
Good examples
“Status: Conditionally Ready. Planning categories pass, but runtime artifacts are Not Run in this pass.”
Bad examples
“Looks good overall, ship it.” (no rubric, no evidence mapping)
User-facing response template
- Current status
- What passed
- What needs follow-up
- Next best action
Anti-patterns
- skipping required laws or runtime boundary statements
- claiming runtime/artifact success without evidence
- using non-official runtime setup paths
- producing jargon-heavy final output without explanation
Cross-skill handoff
- Next:
glb-web-handoff - Then:
non-blender-user-response-writer
Non-goals
- runtime execution
- evidence-free readiness claims