Blender scene quality checker

Skill ThanhNguyxnOrg/blendops/skills/blender-scene-quality-checker

Apply multi-category readiness gates with pass/warn/fail and evidence-bound verdicts.From its SKILL.md

Install

npx -y skills add ThanhNguyxnOrg/blendops --skill blender-scene-quality-checker

Assembled 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.

SKILL.md

5.1 KB, ~1.1k tokens by cl100k_base, 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

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

References

What ships with it: 5 files

2.4 KB alongside SKILL.md

references/

EVAL.md902 B

Keep looking

Skills are one crate of 325,949. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.