How do I install the Template skill?

Run npx skillmds@latest add thanhnguyxnorg/template in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

What does the Template skill do?

<!-- It is listed under Coding & Dev Tools on SkillMD.

Is Template safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Template?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Template free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Template?

ThanhNguyxnOrg (@thanhnguyxnorg) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Template by thanhnguyxnorg — Agent Skill

Name: Template
Author: ThanhNguyxnOrg

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

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

When to use

Use this skill when:

<trigger condition 1>
<trigger condition 2>
<trigger condition 3>

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: <links, paths, logs, or "none">
Limitations: <known gaps>

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):

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.
Path 2 — Community ahujasid/blender-mcp (different addon.py + server via uvx blender-mcp, mature 21K+ stars third-party, Blender 3.0+).
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

Identify user goal and current phase.
Check whether this skill is the narrowest applicable skill.
Confirm required inputs and assumptions.
Apply relevant laws.
Execute the workflow steps for this skill.
Produce the output contract.
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 <path>, 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: <Pass/Warn/Fail or scoped status>
Runtime: <state>
Artifacts: <state>
Evidence: <paths/links/logs or none>
Next safe action: <skill/doc/action>
Limitations: <gaps>

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

Template

File contents