sandbox-bridge

Use when you need to exercise a real, running Sandbox deployment via HTTP — for example to validate SDK changes against a live container, reproduce a user-reported issue, or experiment with the API (including FUSE bucket mounts) without spinning up `wrangler dev`. Documents the Sandbox bridge worker reachable via `SANDBOX_WORKER_URL` + `SANDBOX_API_KEY` when the host injects them.

Quality

75%

Does it follow best practices?

Impact

—

No eval scenarios have been run

Securityby

Advisory

Suggest reviewing before use

Optimize this skill with Tessl

npx tessl skill review --optimize ./.agents/skills/sandbox-bridge/SKILL.md

Quality

Discovery

85%

Based on the skill's description, can an agent find and select it at the right time? Clear, specific descriptions lead to better discovery.

This is a well-crafted description that clearly communicates both what the skill does and when to use it, with strong specificity around the Sandbox deployment testing domain. The explicit 'Use when' clause with multiple concrete scenarios is effective. The main weakness is that trigger terms lean heavily on technical jargon, which could make matching harder for users who phrase requests more casually.

Dimension	Reasoning	Score
Specificity	Lists multiple specific concrete actions: 'validate SDK changes against a live container', 'reproduce a user-reported issue', 'experiment with the API (including FUSE bucket mounts)'. Also mentions specific technical details like 'SANDBOX_WORKER_URL', 'SANDBOX_API_KEY', and 'wrangler dev'.	3 / 3
Completeness	Clearly answers both 'what' (exercise a running Sandbox deployment via HTTP, documents the Sandbox bridge worker) and 'when' (explicitly starts with 'Use when you need to...' covering validation, reproduction of issues, and API experimentation scenarios).	3 / 3
Trigger Term Quality	Contains relevant technical terms like 'Sandbox', 'HTTP', 'SDK', 'FUSE bucket mounts', 'wrangler dev', 'bridge worker', 'SANDBOX_WORKER_URL', 'SANDBOX_API_KEY'. However, these are fairly specialized/jargon-heavy and may miss more natural user phrasings like 'test sandbox', 'call sandbox API', or 'sandbox HTTP request'.	2 / 3
Distinctiveness Conflict Risk	Highly distinctive with a clear niche: specifically about exercising a live Sandbox deployment via the bridge worker with specific environment variables. Unlikely to conflict with other skills due to the very specific domain (Sandbox HTTP testing with SANDBOX_WORKER_URL/SANDBOX_API_KEY).	3 / 3
	Total	11 / 12 Passed

Implementation

64%

Reviews the quality of instructions and guidance provided to agents. Good implementation is clear, handles edge cases, and produces reliable results.

This is a strong, highly actionable skill with excellent executable examples covering the full sandbox lifecycle. Its main weaknesses are moderate verbosity (some sections could be tightened) and missing validation checkpoints in the workflow — there's no guidance on verifying sandbox creation success or checking exit codes before proceeding. The content would benefit from being slightly more concise and adding explicit error-checking steps.

Suggestions

Add validation checkpoints to the workflow: check that SID is non-empty after creation, check exit_code from exec SSE streams before proceeding, and verify file writes with a subsequent read.

Tighten the introductory paragraph and 'When to Use This' section — remove explanations Claude can infer (e.g., 'No local Docker, no build step') and focus on the decision criteria only.

Dimension	Reasoning	Score
Conciseness	The content is mostly efficient with good use of tables and code examples, but includes some unnecessary explanation (e.g., the intro paragraph explaining what the bridge is, the 'When to Use This vs wrangler dev' section has some redundancy, and the session isolation explanation could be tighter). The SSE event table and error codes are valuable reference material that earns its place.	2 / 3
Actionability	Every endpoint is demonstrated with fully executable, copy-paste-ready curl commands. The examples include variable capture (SID, SESS), proper headers, and even a helper awk command for decoding SSE streams. The SSE event format table provides exact payload schemas.	3 / 3
Workflow Clarity	The typical flow (create → exec → read/write → destroy) is clearly sequenced with numbered steps and the 'Always clean up' instruction is good. However, there are no explicit validation checkpoints — no verification that sandbox creation succeeded before proceeding, no check on exec exit codes, and the destroy step (a cleanup of a created resource) lacks a verification pattern. For a workflow involving remote resource lifecycle management, this is a gap.	2 / 3
Progressive Disclosure	The content is well-structured with clear sections and tables, and appropriately defers to `/v1/openapi.json` and source paths for deeper details. However, for its length (~200+ lines), some content like the full Sessions section and the 'Other Endpoints' table could be split into separate reference files. The reference to 'the examples skill' for wrangler dev is a good cross-reference but no bundle files exist to support further disclosure.	2 / 3
	Total	9 / 12 Passed

Validation

100%

Warnings & errors only

Checks the skill against the spec for correct structure and formatting. All validation checks must pass before discovery and implementation can be scored.

Validation — 11 / 11 Passed

Validation for skill structure

No warnings or errors.

Repository: cloudflare/sandbox-sdk
Commit: 3b58a22

Reviewed: 5 days ago

Table of Contents

Discovery Implementation Validation

Is this your skill?

If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.