<skill Name>

Purpose

State the skill's narrow job in one or two sentences. Keep it composable; do not make this skill own unrelated planning, runtime, evidence, and handoff work at the same time.

Quick start

1. Confirm the user's goal and current evidence state.
2. Select the correct runtime stack posture, if runtime is relevant.
3. Follow the workflow below.
4. Return the output contract with explicit evidence/caveat status.

When to use

Use this skill when:

When not to use

Do not use this skill when:

• The request belongs to a narrower existing skill.
• The user asks for runtime execution but readiness has not been checked.
• The task would require claiming preview/render/GLB artifacts without evidence.
• The task would promote unofficial bridge setup as an official path.

Trigger phrases

• “”
• “”
• “”

Prerequisites / readiness

• Current BlendOps status is known: Draft v0 unless a newer release-readiness doc says otherwise.
• Runtime state is one of: Not Run, Attempted, Produced, Verified, Failed, or Blocked / Not Run.
• If runtime is needed, identify the intended stack before execution.
• If artifacts are discussed, evidence source and output paths must be available or marked missing.

Input schema

Required inputs

| Input | Why it is required | |---|---| | User goal | Defines scope and prevents overwork. | | Current runtime/artifact state | Prevents unsupported success claims. | | Relevant target surface or workflow | Determines handoff and constraints. |

Optional inputs

| Input | Use | |---|---| | Runtime stack | Needed only when runtime work is in scope. | | Output target | Helps shape render/export/evidence requirements. | | Existing evidence links | Lets the skill verify rather than speculate. |

Assumptions to confirm

• Runtime install is separate from skill install.
• No Blender mutation/render/export occurs unless explicitly requested and readiness passes.
• Missing evidence means the output remains conservative.

Output schema

Primary output

Secondary output

• next recommended skill/doc
• blockers or caveats
• user-facing status line

Evidence / caveat output

Always include:

Runtime status: Not Run | Attempted | Produced | Verified | Failed | Blocked / Not Run
Artifact status: Not Run | Not Produced | Produced | Verified | Failed
Evidence used: 
Limitations: 

Required laws

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

Official runtime boundary

BlendOps runtime guidance uses 2 MCP execution paths plus a CLI fallback appendix (replaces older 3-stack and 4-route drafts — see ../../docs/runtime-stack-strategy.md for the corrected attribution history):

1. Path 1 — Official Blender Lab MCP (Lab add-on + Lab server installed in Blender 5.1+, hosted from either (a) Anthropic Blender Connector in Claude Desktop, or (b) any other MCP client configured manually). Anthropic Connector is not standalone — Anthropic's tutorial step 2 tells you to install the Lab add-on inside Blender.
2. Path 2 — Community ahujasid/blender-mcp (different addon.py + server via uvx blender-mcp, mature 21K+ stars third-party, Blender 3.0+).
3. CLI fallback (appendix) — direct blender --background --python, no MCP. Documented upstream as a first-class Blender CLI surface (stable across LTS releases); no in-repo evidence file yet.

Blender 5.1+ floor applies to all of Path 1 (whichever host). Single-bridge constraint: Blender accepts one MCP bridge session per Blender instance.

This skill must not install Blender, run Blender, configure a runtime bridge, mutate a scene, render, export GLB, or claim artifacts unless the user explicitly requested that work and evidence exists.

Runtime route requirements

| Path | Requirement before use | |---|---| | Path 1 (Blender-side, always required) | Blender 5.1+ + Lab MCP add-on installed in Blender + Lab MCP server (.mcpb bundle or source) reachable. | | Path 1, host (a) Anthropic Connector | Connector enabled in Claude Desktop → Customize → Connectors; read-only request first. | | Path 1, host (b) manual MCP client | Lab MCP server registered in client's mcpServers JSON or equivalent UI; read-only request first. | | Path 2 (community ahujasid/blender-mcp) | uvx blender-mcp registered in client config + addon.py installed/enabled in Blender 3.0+; read ../../docs/unofficial-runtime-bridges.md first; explicit user opt-in for execute_blender_code (no sandbox). | | CLI fallback (appendix) | Exact Blender executable/CLI command, input/script, output paths, logs, validation evidence; note that BlendOps has no in-repo evidence file yet (the CLI itself is upstream-stable). |

Operating procedure

1. Identify user goal and current phase.
2. Check whether this skill is the narrowest applicable skill.
3. Confirm required inputs and assumptions.
4. Apply relevant laws.
5. Execute the workflow steps for this skill.
6. Produce the output contract.
7. Hand off to the next skill or doc when needed.

Decision tree

Need help choosing next step?
  → blendops-help
Need runtime readiness?
  → official-runtime-readiness-checker
Need scene plan?
  → product-hero-scene-planner and domain planners
Need render/export proof?
  → render-export-evidence
Need GLB/web handoff wording?
  → glb-web-handoff
Need final non-Blender-user summary?
  → non-blender-user-response-writer

Playbooks

Playbook A: Text-only mode

• Keep runtime status Not Run.
• Produce planning/checklist output only.
• State that preview/render/GLB artifacts are Not Produced unless evidence exists.

Playbook B: Runtime-ready mode

• Verify runtime stack and preflight evidence.
• Record exact actions, tools, inputs, output paths, and limitations.
• Do not upgrade status beyond the evidence.

Playbook C: Blocked mode

• Identify blocker.
• Keep runtime/artifact status conservative.
• Recommend the next safe readiness or planning step.

Mode handling

Text-only mode

Use when Blender is not available or not requested. Do not imply runtime execution.

Runtime-ready mode

Use only when the user explicitly requests runtime work and readiness is documented.

Blocked runtime mode

Use when requirements are missing. Report blockers and next safe action.

Validation checklist

• [ ] Skill scope fits the user request.
• [ ] Required laws were applied.
• [ ] Runtime stack status is explicit.
• [ ] Artifact evidence status is explicit.
• [ ] No unsupported runtime route is presented as supported.
• [ ] No preview/render/GLB claim appears without evidence.
• [ ] Handoff names the next skill/doc.

Pass / Warn / Fail rubric

| Verdict | Criteria | |---|---| | Pass | Output satisfies scope, evidence state is explicit, and no overclaim appears. | | Warn | Output is useful but has missing inputs, partial evidence, or scoped uncertainty. | | Fail | Output claims unsupported runtime/artifact success, ignores laws, or routes to an unsupported path. |

Failure handling

• If evidence is missing, downgrade status instead of guessing.
• If runtime readiness is unknown, hand off to readiness skill.
• If a user asks for unsupported direct official MCP usage, mark it future research/unverified.
• If an unofficial bridge appears, keep it optional/local and outside release evidence.

Troubleshooting

| Problem | Response | |---|---| | User wants “done” without evidence | Explain missing evidence and use Not Run / Not Produced. | | User conflates skill install with runtime install | Separate skill install, runtime setup, and eval evidence. | | User asks for marketplace/package claim | Keep as future until verified. |

Best practices

• Prefer operational checklists over essays.
• Keep examples short and evidence-bound.
• Link docs instead of copying large reference content.
• Use precise status words.
• Hand off instead of expanding scope.

Good examples

• “Runtime status: Not Run. Artifact status: Not Produced. Next safe action: run runtime readiness checklist for Path 1, host (a) Anthropic Blender Connector.”
• “Produced evidence exists at ``, but validation is incomplete; status remains Produced, not Verified.”

Bad examples

• “Everything is ready” without evidence.
• “GLB produced” without file path and validation notes.
• “Use official direct MCP from Claude Code” as a supported route.

User-facing response template

Status: 
Runtime: 
Artifacts: 
Evidence: 
Next safe action: 
Limitations: 

Anti-patterns

• Turning a planning skill into a runtime executor.
• Treating third-party bridge setup as official.
• Treating read-only connector access as full runtime eval.
• Treating install success as artifact success.

Cross-skill handoff

• Runtime readiness → ../official-runtime-readiness-checker/SKILL.md
• Scene planning → ../product-hero-scene-planner/SKILL.md
• Render/export evidence → ../render-export-evidence/SKILL.md
• GLB handoff → ../glb-web-handoff/SKILL.md
• Final response → ../non-blender-user-response-writer/SKILL.md

Non-goals

• Install Blender.
• Run Blender.
• Configure connector/MCP/CLI runtime.
• Create scene data.
• Render or export GLB.
• Claim marketplace/package availability.

References

• ../../docs/skill-system.md
• ../../docs/runtime-stack-strategy.md
• ../../docs/evals/runtime-availability-checklist.md
• ../../docs/evals/official-runtime-verification-criteria.md
• ../../docs/distribution-strategy.md

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ThanhNguyxnOrg
• Source: ThanhNguyxnOrg/blendops
• License: MIT
• Homepage: https://github.com/ThanhNguyxnOrg/blendops

Install and usage instructions live in the source repository linked above.