# Official Runtime Readiness Checker

> Evaluate whether official runtime appears ready using evidence-bound checks and explicit readiness states.

- Skill: `thanhnguyxnorg/official-runtime-readiness-checker` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add thanhnguyxnorg/official-runtime-readiness-checker`
- Raw SKILL.md: https://api.skillmd.com/api/skills/thanhnguyxnorg/official-runtime-readiness-checker/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: ThanhNguyxnOrg (https://skillmd.com/u/thanhnguyxnorg)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/thanhnguyxnorg/official-runtime-readiness-checker

---


# official-runtime-readiness-checker

## Purpose
Assess runtime readiness before any attempt to claim runtime execution outcomes.

Canonical role: `runtime-readiness` in the BlendOps skill system. Keep this as the active readiness implementation rather than creating duplicate readiness skills.

## 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 runtime manual eval
- before any preview/render/GLB readiness claim

## When not to use
- as proof that runtime execution succeeded
- as substitute for actual runtime artifacts

## Trigger phrases
- “check runtime readiness”
- “is runtime available”
- “can we run this now”
- “verify connector and MCP availability”

## Prerequisites / readiness
- non-destructive local environment access
- ability to read config/path signals
- clear distinction between readiness and execution

## Input schema

### Required inputs
- expected runtime path(s)
- target harness context

### Optional inputs
- known executable paths
- known config file locations
- prior blocker records

### Assumptions to confirm
- no Blender run required for readiness-only pass
- no non-official runtime path should be used

## Output schema

### Primary output
- readiness matrix + final status

### Secondary output
- blocker list + retry steps

### Evidence / caveat output
- per-check evidence lines
- confidence label per check: verified / linked-only / unknown / blocked

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

## Official runtime boundary
- This skill can check local readiness signals.
- This skill must not claim runtime artifact production.
- This skill must not claim execution success without execution evidence.

## Operating procedure
1. Confirm chosen runtime path (Path 1 or Path 2 from `../../docs/runtime-stack-strategy.md`); for Path 1 also confirm host option (a Anthropic Connector, b manual MCP). CLI fallback is appendix only — documented upstream as first-class Blender CLI surface but no in-repo evidence file yet; flag this if user picks it.
2. Check Blender executable availability (command/path evidence) AND record exact `blender --version` output for per-path minimum check:
   - **Path 1 (either host)** → 5.1+ required (Lab add-on `blender_version_min = 5.1.0`).
   - Path 2 → 3.0+ required (per upstream).
   - CLI fallback → 4.2+ recommended; documented upstream as first-class Blender CLI; no in-repo evidence file yet.
3. Per chosen path + host, check the path-specific configuration:
   - **Path 1 Blender-side (always required)**: Lab MCP add-on installed in Blender + MCP server (`.mcpb` bundle or source) reachable.
   - Path 1 host (a): Anthropic Connector enabled in Claude Desktop → Customize → Connectors.
   - Path 1 host (b): Lab MCP server registered in MCP client config (`mcpServers` JSON or equivalent).
   - Path 2: `ahujasid/blender-mcp` server registered (`uvx blender-mcp` or equivalent) + upstream `addon.py` installed + enabled in Blender.
   - CLI fallback: Blender executable resolvable from agent shell.
4. Check single-bridge constraint: at most one MCP bridge session active per Blender instance (Path 1 + Path 2 must not both target the same Blender; Path 1 host (a) + host (b) must not both target the same Blender).
5. Check artifact/output location readiness for future run.
6. Assign confidence label to each check (`verified-read` / `linked-only` / `unknown` / `blocked`).
7. Populate readiness matrix table per path + host.
8. Derive final status (Ready / Partially Ready / Blocked / Unknown).
9. Produce blocker summary and next actions.
10. Route to planner or setup skill based on status.

## Decision tree
- Blender missing + no connector/MCP evidence → Blocked.
- Blender found but connector/MCP uncertain → Partially Ready or Unknown.
- Blender found + connector/MCP signals sufficient → Ready candidate (still no artifact claim).

## 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
- readiness checks only
- no runtime execution claims

### Runtime-ready mode
- status Ready/Partially Ready with explicit caveats
- handoff to planning/execution workflows

### Blocked runtime mode
- status Blocked
- explicit blockers + setup next steps

## Validation checklist
- [ ] Blender check recorded
- [ ] connector check recorded
- [ ] MCP check recorded
- [ ] artifact path readiness recorded
- [ ] confidence labels assigned
- [ ] final status assigned
- [ ] blocker list included
- [ ] no execution success claim
- [ ] no non-official path reference
- [ ] next actions clear

## Pass / Warn / Fail rubric

| Category | Pass | Warn | Fail |
|---|---|---|---|
| Blender availability | Verified with local evidence | Partial path evidence | Missing/not found |
| Connector/MCP checks | Clear signal per path | Unknown signal with caveat | Claimed available without evidence |
| Confidence labeling | Every check labeled | Partial labels | No labels |
| Status logic | Matches matrix evidence | Minor ambiguity | Contradicts evidence |

## Failure handling
- Unknown state: mark Unknown, not Ready.
- Missing config path: mark Blocked and provide exact next check.
- Conflicting signals: choose safer status with caveat.

## Troubleshooting
- Blender not on PATH: check absolute path.
- Config file exists but missing runtime entries: mark unknown/blocked.
- Existing artifacts found: treat as pre-existing unless run-specific evidence ties them to current eval.

## Best practices
- keep checks reproducible and non-destructive
- include exact evidence lines in report
- separate readiness from artifact claims

## Good examples
“Status: Blocked. Blender binary exists, but official connector/MCP runtime path is not confirmed in this environment.”

## Bad examples
“Looks good; runtime should work.” (no matrix, no evidence)

## User-facing response template
- Current runtime status
- Evidence observed
- Missing readiness signals
- Next setup 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
- If Ready/Partially Ready: `product-hero-scene-planner`
- If Blocked/Unknown: `official-runtime-setup-guide`

## Non-goals
- runtime execution
- artifact generation claims
- unofficial runtime fallback

## References
- 2-path + CLI appendix runtime model: ../../docs/runtime-stack-strategy.md
- Per-path setup details: ../../docs/external-runtime-setup.md
- Path 1 host (a) source — Anthropic Connector: https://claude.com/resources/tutorials/using-the-blender-connector-in-claude
- Path 1 Blender-side source — Lab MCP (required for both hosts): https://www.blender.org/lab/mcp-server/
- Path 2 source: https://github.com/ahujasid/blender-mcp
- CLI fallback source (documented upstream as first-class Blender CLI; no in-repo evidence file yet): https://docs.blender.org/manual/en/latest/advanced/command_line/index.html