agentleFS
ThanhNguyxnOrgThanhNguyxnOrg/blendops/skills/asset-style-check/SKILL.md

asset-style-check

Skill3 starsChanged 6 months agoMITView on GitHub

Verify chosen assets share visual style (realism, detail, color treatment) before scene build; flag style drift between assets early.

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 8 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈8

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    after asset-license-checker clears the assets

    line 18
  2. Distinctive:

    when a scene preview shows visible style mismatch

    line 20
  3. Distinctive:

    when assets come from multiple sources

    line 21
  4. Very specific:

    all candidate assets cleared by asset-license-checker

    line 40
  5. Very specific:

    Read the locked brief style baseline (if missing or ambiguous, hand off to intent-to-3d-brief-writer).

    line 99
  6. Distinctive:

    All assets realistic; same detail density.

    line 123
  7. Distinctive:

    Always evaluate against the brief, not against vibe.

    line 181
  8. Distinctive:

    Prefer 1 source for related assets to reduce drift risk.

    line 182
  9. Distinctive:

    Keep this skill narrow — do not check license / budget / topology here.

    line 183
  10. Distinctive:

    Never modify or re-style assets.

    line 229
  11. Very specific:

    Never check asset licenses (belongs to asset-license-checker).

    line 230
  12. Very specific:

    Never check polycount budgets or mesh topology (belongs to polycount-budget-checker).

    line 231
  13. Distinctive:

    Never execute Blender or Python code.

    line 232

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

asset-style-check

Purpose

Catch style mismatches between assets before they end up in the same scene where the inconsistency reads as compositing error.

Quick start

  • list every asset planned for the scene
  • evaluate each on style axes (realism / detail / color / surface)
  • flag drift between assets
  • recommend remediation (drop / restyle / replace)

When to use

  • after asset-license-checker clears the assets
  • before scene build
  • when a scene preview shows visible style mismatch
  • when assets come from multiple sources

When not to use

<!-- blendops:generated:start exclusions -->
  • single isolated asset where no multi-asset or scene-brief consistency check is requested → use ../asset-discovery/SKILL.md (Delegates out-of-scope requests to asset-discovery)
  • pure planning before candidate assets are picked → use ../asset-discovery/SKILL.md (use asset-discovery)
  • intentionally mixed-style art direction, ONLY when the locked brief explicitly specifies mixed styles → use ../asset-license-checker/SKILL.md (Delegates out-of-scope requests to asset-license-checker)
  • checking asset licenses (asset-license-checker), polygon/performance budgets (polycount-budget-checker), topology, or planning materials/lighting (blender-light → use ../asset-license-checker/SKILL.md (lighting-material-plan)
<!-- blendops:generated:end exclusions -->

Trigger phrases

<!-- blendops:generated:start triggers -->
  • "do these assets fit together"
  • "style check the assets"
  • "scene feels like a collage"
<!-- blendops:generated:end triggers -->

Prerequisites / readiness

  • candidate asset list with previews sourced via asset-discovery
  • all candidate assets cleared by asset-license-checker
  • scene brief visual style locked (via intent-to-3d-brief-writer if needed)
  • target scene quality bar set

Input schema

Required inputs

InputWhy it is required
Asset list with previewsSubject of the check
Brief style lockedReference for consistency

Optional inputs

InputUse
Reference image / mood boardStyle baseline
Existing scene previewReal-world consistency check

Assumptions to confirm

  • Brief style is unambiguous.
  • Asset previews are representative of final use.

Output schema

Primary output

A per-asset row table containing: asset name, realism axis, detail axis, color axis, surface axis, drift verdict (None | Minor | Major), validation verdict (Pass | Warn | Fail), and remediation hint (none | drop | restyle | replace).

Secondary output

  • top-line scene consistency verdict (Pass | Warn | Fail)
  • summary list of assets to drop, restyle, or replace
  • downstream handoff routing
  • evidence and truth-state block (kept strictly separate from Pass | Warn | Fail validation verdicts)

Evidence / caveat output

Runtime status: Not Run | Attempted | Produced | Verified | Failed
Artifact status: Not Produced | Produced | Verified | Failed (default: Not Produced)
Evidence used: <links, paths, logs, or "none">
Limitations: <known gaps>

Note: Truth states are downgrade-only (never upgrade without verified evidence) and remain strictly separate from per-asset Pass | Warn | Fail validation verdicts.

Required laws

  • ../../laws/evidence-before-done.md
  • ../../laws/non-blender-user-language.md
  • ../../laws/no-arbitrary-python-interface.md
  • ../../laws/official-runtime-only.md

Official runtime boundary

Validation-only skill — never modifies or re-styles assets, and never executes Blender or Python. Per-asset verdicts (Pass | Warn | Fail) and drift classifications (None | Minor | Major) are derived solely from documented asset previews and the locked style brief, and are tracked separately from runtime/artifact truth states (which default to Not Produced for artifacts and are downgrade-only).

Operating procedure

  1. Confirm the asset list is sourced from asset-discovery and cleared by asset-license-checker.
  2. Read the locked brief style baseline (if missing or ambiguous, hand off to intent-to-3d-brief-writer).
  3. For each asset, evaluate all 4 style axes (realism, detail, color, surface) against the locked brief (see references/style-axes.md).
  4. Assign a drift verdict (None | Minor | Major) and a validation verdict (Pass | Warn | Fail) per asset row.
  5. Provide remediation hints only (drop | restyle | replace) for any asset with Minor or Major drift — never modify or re-style the asset here.
  6. Route approved rows (Pass) to asset-library-plan for organization and scene-readiness for broad scene review; route rejected rows (Fail) to asset-fallback-strategy or back to asset-discovery.

Decision tree

Brief explicitly locks mixed-style art direction?
  → Evaluate each asset against its assigned role in the brief; allowed contrast = None drift (Pass row)
Asset matches brief baseline across all 4 axes (realism / detail / color / surface)?
  → Drift: None | Verdict: Pass | Remediation: none
Asset off on 1 axis?
  → Drift: Minor | Verdict: Warn | Remediation: restyle or drop (verify intent)
Asset off on 2+ axes, or clashes severely with hero asset?
  → Drift: Major | Verdict: Fail | Remediation: replace or drop (hand off to asset-fallback-strategy)
Two or more assets in the same scene have Major drift between them without explicit mixed-style brief?
  → Top-line Verdict: Fail; cannot combine without breaking visual hierarchy

Playbooks

Playbook A: All-realistic product hero

All assets realistic; same detail density; PBR materials. One stylized prop → drop or restyle.

Playbook B: Stylized character + flat background

Character is stylized; background must be equally simplified. Detailed background asset → drop.

Playbook C: Mixed-style intentional (collage / editorial)

Brief explicitly mixed-style; verify with brief; drift becomes feature, not bug.

Mode handling

Text-only mode

Evaluate rows from documented previews and metadata. Set Runtime status: Not Run and Artifact status: Not Produced.

Runtime-ready mode

Evaluate rows using rendered scene preview snapshots alongside asset previews. Downgrade truth states if any preview is incomplete; never upgrade truth states beyond verified evidence.

Blocked runtime mode

Skip rows that depend on a live rendered preview and mark limitations clearly. Keep Runtime status: Not Run (or Failed if attempted and blocked) and Artifact status: Not Produced.

Validation checklist

  • Every asset has a 4-axis row (realism, detail, color, surface) evaluated against the locked brief
  • Every asset row includes both a drift verdict (None / Minor / Major) and a validation verdict (Pass / Warn / Fail)
  • Top-line consistency verdict (Pass / Warn / Fail) is stated
  • Remediation hints (drop / restyle / replace) are provided for any drift without modifying assets
  • No license, polycount budget, or topology checks are mixed into the evaluation
  • Runtime and artifact truth states (default Not Produced, downgrade-only) are reported separately from Pass / Warn / Fail verdicts

Pass / Warn / Fail rubric

ScopeVerdictCriteria
Per-asset rowPassMatches locked brief across all 4 axes (realism, detail, color, surface), or matches explicit mixed-style brief rule; drift is None.
Per-asset rowWarnMinor drift on 1 axis against the locked brief; usable with a restyle or drop remediation hint.
Per-asset rowFailMajor drift on 2+ axes against the locked brief; requires replace or drop via asset-fallback-strategy.
Top-line scenePassAll asset rows are Pass (or Warn with accepted remediation); locked brief style is respected.
Top-line sceneWarnOne or more assets show Minor drift (Warn), but no unresolved Major drift exists.
Top-line sceneFailAny asset has unresolved Major drift (Fail) or two+ assets clash, creating a visible collage error against the brief.

Note: Pass / Warn / Fail validation verdicts measure style consistency only and must never be conflated with Runtime or Artifact truth states.

Failure handling

  • Major drift (Fail row) → recommend replace or drop; hand off rejected assets to asset-fallback-strategy or asset-discovery.
  • Brief unclear or unlocked regarding visual style → stop evaluation and hand off to intent-to-3d-brief-writer.
  • Claim that "mixed style is intentional" → accept ONLY if the locked brief explicitly specifies mixed styles; otherwise mark drift and hand off to intent-to-3d-brief-writer or scope-guard.

Troubleshooting

ProblemResponse
Hard to tell style from previewRequest higher-quality preview; mark asset row Warn with limitation noted until clarified.
Style is on the boundaryLock the style axis early against the brief; do not invite repeat boundary calls.
User changes style mid-sceneTreat as scope creep; hand off to scope-guard.

Best practices

  • Lock style early; revisions are cheap pre-build.
  • Always evaluate against the brief, not against vibe.
  • Prefer 1 source for related assets to reduce drift risk.
  • Keep this skill narrow — do not check license / budget / topology here.

Good examples

  • "shoe-base.glb: realism=realistic, detail=high, color=neutral, surface=PBR | Drift: None | Verdict: Pass | Remediation: none. shoe-laces.glb: realism=realistic, detail=high, color=neutral, surface=PBR | Drift: None | Verdict: Pass | Remediation: none. shoe-environment-stylized.glb: realism=stylized, detail=low, color=saturated, surface=flat | Drift: Major | Verdict: Fail | Remediation: replace via asset-fallback-strategy."

Bad examples

  • "Assets look like they go together." — no axis-by-axis verdict.

User-facing response template

Brief style: <one line locked baseline>

| Asset | Realism | Detail | Color | Surface | Drift (None/Minor/Major) | Verdict (Pass/Warn/Fail) | Remediation (none/drop/restyle/replace) |
|---|---|---|---|---|---|---|---|

Top-line consistency: Pass / Warn / Fail
Assets to drop / restyle / replace: <list or "none">
Runtime status: Not Run | Attempted | Produced | Verified | Failed
Artifact status: Not Produced | Produced | Verified | Failed (default: Not Produced)
Evidence used: <links, paths, logs, or "none">
Limitations: <known gaps>
Next: asset-library-plan & scene-readiness (Pass) / asset-fallback-strategy (Fail)

Anti-patterns

  • "Vibe match" verdicts.
  • Skipping the brief reference.
  • Mixing license / budget / topology checks here.
  • Inventing axis values.

Cross-skill handoff

<!-- blendops:generated:start handoffs -->
  • [upstream_reference] Upstream discovery → ../asset-discovery/SKILL.md
  • [upstream_reference] Upstream license gate → ../asset-license-checker/SKILL.md
  • [upstream_reference] Upstream brief lock → ../intent-to-3d-brief-writer/SKILL.md
  • [boundary_delegation] Scope enforcement → ../scope-guard/SKILL.md
  • [fallback] Rejected asset fallback → ../asset-fallback-strategy/SKILL.md
  • [progression] Approved asset organization → ../asset-library-plan/SKILL.md
  • [progression] Broad scene review → ../scene-readiness/SKILL.md
  • [progression] Material & lookdev boundary (lighting-material-plan) → ../lighting-material-plan/SKILL.md
  • [progression] Material & lookdev boundary (material-quality-checker) → ../material-quality-checker/SKILL.md
  • [progression] Budget & topology boundary → ../polycount-budget-checker/SKILL.md
<!-- blendops:generated:end handoffs -->

Non-goals

  • Never modify or re-style assets.
  • Never check asset licenses (belongs to asset-license-checker).
  • Never check polycount budgets or mesh topology (belongs to polycount-budget-checker).
  • Never execute Blender or Python code.

References

  • references/style-axes.md
  • references/drift-classification.md
  • references/intentional-mixed-style.md
  • ../../docs/skill-system.md

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.