creating-sbx-kits

Write a Docker Sandbox kit — a spec.yaml declaring setup steps, network permissions and credentials. Use when authoring or fixing a kit, choosing between kind mixin and kind sandbox, migrating a spec from schemaVersion 1 to 2, or a kit fails sbx kit validate.

Quality

89%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

Securityby

Passed

No findings from the security scan

Quality

Content

88%Weight 40%Scale 1-5

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

An excellent, dense body: it teaches validator-enforced rules, real failure modes, and executable patterns Claude could not derive on its own, with an explicit validate-after-every-edit feedback loop and verified one-level-deep bundle files. The residual improvements are trimming a few narrative flourishes and moving duplicated field-semantics detail into references/spec-fields.md.

Dimension	Reasoning	Score
Conciseness	Nearly every paragraph carries non-generic, corpus-derived knowledge (the install/startup uid asymmetry, the caps: v1 leak, the mixins: no-op) with no explanation of concepts Claude already knows; only minor literary flourishes ("Two independent authors discovered that asymmetry the hard way") could be trimmed, and time-bound claims are properly quarantined in a "Last verified" section.	4 / 5
Actionability	Guidance is copy-paste ready throughout: sbx kit validate/run/policy log/rm/pack/push commands, the six-host GitHub allowlist and apt host list as complete YAML, a fully executable launcher script with mode "0755" and a pinned version, and a concrete detached-install recipe down to setsid and the flag file.	5 / 5
Workflow Clarity	The sequence is explicit with validation checkpoints and feedback loops: start from a skeleton, "Spend it after every edit: sbx kit validate", then iterate against a real sandbox with "sbx policy log" showing what got blocked and by which rule, and "sbx rm" for a clean slate; failure signatures (403 body naming the rule, exit 137, exit 100) support error recovery.	5 / 5
Progressive Disclosure	References are well signaled and exactly one level deep — commented skeletons in assets/, a finished example at assets/sandbox-aware/, and "Every field, with its type and its traps, is in references/spec-fields.md" (all files verified present). The body nonetheless inlines substantial field-semantics prose (extends/requires.agent rules, full host allowlists) that partially duplicates the reference file's remit, keeping it short of the ideal split.	4 / 5
	Total	18 / 20 Passed

Description

87%Weight 40%Scale 1-5

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

A strong description: it names the artifact, the concrete field groups it manages, and four explicit trigger scenarios in third-person voice. The only weakness is that the "what" understates the skill's actual scope, leaving agentInstructions, executable shipping, and kit distribution unmentioned.

Dimension	Reasoning	Score
Specificity	The description names the concrete artifact and actions — "a spec.yaml declaring setup steps, network permissions and credentials" — but omits capabilities the skill body covers (agentInstructions, setup.files, distribution via sbx kit push), so it lists several specific actions with minor gaps rather than comprehensive coverage.	4 / 5
Completeness	Both what ("Write a Docker Sandbox kit — a spec.yaml declaring setup steps, network permissions and credentials") and when are explicitly and concretely stated, matching the anchor for clearly answering both with concrete trigger phrases; voice is third person with no padding.	5 / 5
Trigger Term Quality	The "Use when" clause supplies four natural trigger phrases ("authoring or fixing a kit", "choosing between kind mixin and kind sandbox", "migrating a spec from schemaVersion 1 to 2", "a kit fails sbx kit validate") plus the spec.yaml filename, giving good keyword coverage; a few natural terms around publishing/pushing a kit are missing.	4 / 5
Distinctiveness Conflict Risk	It occupies a clear niche (sbx kit spec.yaml authoring) with distinct triggers (kind mixin/sandbox, schemaVersion migration, sbx kit validate), and the skill family routes Dockerfile work elsewhere, so conflict risk is minimal.	5 / 5
	Total	18 / 20 Passed

Validation

87%

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 — 14 / 16 Passed

Validation for skill structure

Criteria	Description	Result
relative_links	Relative link issues: 2 deeper-than-1-level	Warning
referenced_paths_exist	Referenced path issues: 2 deeper-than-1-level	Warning

	Total	14 / 16 Passed

Repository: slurpyb/sbx-agent
Path: skills/creating-sbx-kits/SKILL.md
Commit: cd8f798

Reviewed: 1 hour 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.