CtrlK
BlogDocsLog inGet started
Tessl Logo

sprites

Use this skill for Sprites — isolated, persistent cloud Linux environments from Fly.io with their own filesystem, URL, services, checkpoints, and network policy. Trigger it to create, list, exec into, or destroy sprites; to run builds, tests, or agents in a remote sandbox; to start long-running services and expose a preview URL; to snapshot and roll back state; to change outbound network rules; to call third-party APIs (GitHub, Slack, etc.) through the credential-injecting gateway; or whenever the user names Sprites, sprite-env, or sprites.dev. Works both from inside a sprite and from a machine outside one.

77

Quality

96%

Does it follow best practices?

Run evals on this skill

Adds up to 20 points to the overall score

View guide

SecuritybySnyk

Passed

No findings from the security scan

SKILL.md
Quality
Evals
Security

Quality

Content

93%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.

The body is a lean, well-architected routing skill: a concrete context-detection step, a control-plane decision table, an explicit golden path with pre-flight validation and safety rules, and a clean one-level reference bundle that fully backs every link. The only notable gap is the absence of an explicit error-recovery feedback loop (what to do when verification fails) in the golden path, which keeps workflow clarity just short of the top anchor.

Suggestions

Add an explicit failure-recovery step to the golden path (e.g., 'If verification fails: check logs or exit status, fix, re-run, re-verify — and roll back to the pre-work checkpoint if state was mutated') to close the feedback-loop gap in workflow_clarity.

Replace the elided command fragments ('sprite api .../policy/network', 'sprite-env services create ...') with one complete example invocation each, or annotate them explicitly as syntax-delegated-to-reference so readers know they are intentional pointers rather than executable commands.

State where the pre-work checkpoint ID should be recorded during the golden path (e.g., 'save the checkpoint ID to reference it in rollback'), making the safety rule operationally traceable when a verify step fails.

DimensionReasoningScore

Conciseness

The body is lean with essentially no padding: every section is operational — a one-line context-detection command (`test -S /.sprite/api.sock && echo inside || echo outside`), a control-plane distinction table, a goal-to-command routing table, a 7-step golden path, and four terse safety rules. The only definitional sentence ("A sprite is a persistent, hardware-isolated Linux environment") introduces a product-specific concept Claude does not already know, so it earns its tokens; this matches the 5 anchor ("every token earns its place") rather than the 4 anchor, which requires identifiable instances of over-explanation, and none are present.

5 / 5

Actionability

The common cases are given as complete, copy-paste-ready commands: the detection one-liner, `sprite list`, `sprite exec -s <name> -- <cmd>`, `sprite-env services create ...` via the correct control plane, `sprite checkpoint create -s <name>`, `sprite file push` / `sprite file pull`, and `sprite create` / `sprite destroy`. The two literal elisions ("sprite api .../policy/network", the gateway URL row) are routing pointers whose full syntax is explicitly delegated to per-task references, so the body still covers the common cases concretely — matching the 5 anchor rather than the 4 anchor ("concrete code or commands with minor gaps" in the common cases themselves).

5 / 5

Workflow Clarity

The golden path is a well-sequenced 7-step checklist with explicit validation checkpoints: "Inspect before you mutate", "Checkpoint valuable state before risky work", and "Verify with real output — exit status, service state, logs, an HTTP probe", plus confirmation rules for the destructive operations (restore, destroy). It sits between anchors: it has more checkpoints than the 4 anchor's "most checkpoints present", but it lacks the explicit error-recovery feedback loop ("If errors: fix and re-validate") that the 5 anchor requires — there is no stated action for what to do when verification fails, only pre-flight safeguards.

4 / 5

Progressive Disclosure

This is a textbook overview-then-references structure: the body routes each goal to a named reference in the operation table, and all 10 linked files (environment-detection, remote, services, checkpoints, network-policy, api-gateway, cli, http-api, files, safety) exist in references/ and each carries a one-line description in the References section. The references are one level deep with only a handful of peer links between siblings (no nested chains), and the body states "Read the one that matches the task; each is self-contained" — matching the 5 anchor (clear overview with well-signaled one-level-deep references, easy navigation).

5 / 5

Total

19

/

20

Passed

Description

100%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.

The description is exemplary: it states a concrete what, an explicit and multi-faceted when clause with natural trigger phrases, and a comprehensive set of specific actions spanning the skill's full operation surface. It stays within a reasonable length, uses third-person/imperative voice consistent with the good examples, and carries virtually no risk of mis-triggering.

DimensionReasoningScore

Specificity

The description enumerates the skill's entire concrete action surface: "create, list, exec into, or destroy sprites", "run builds, tests, or agents in a remote sandbox", "start long-running services and expose a preview URL", "snapshot and roll back state", "change outbound network rules", and "call third-party APIs (GitHub, Slack, etc.) through the credential-injecting gateway". Coverage is comprehensive rather than having minor gaps — every operational domain in the skill's reference bundle (remote, services, checkpoints, files, network policy, gateway) maps to a listed action — so it matches the 5 anchor ("multiple specific concrete actions; comprehensive coverage") rather than the 4 anchor.

5 / 5

Completeness

Both questions are answered explicitly. What: "isolated, persistent cloud Linux environments from Fly.io with their own filesystem, URL, services, checkpoints, and network policy". When: "Trigger it to create, list, exec into, or destroy sprites; ... or whenever the user names Sprites, sprite-env, or sprites.dev. Works both from inside a sprite and from a machine outside one." This matches the 5 anchor (clearly and explicitly answers both what AND when with concrete trigger phrases); the 4 anchor applies when the 'when' clause is present but only loosely stated, which is not the case here.

5 / 5

Trigger Term Quality

Natural trigger terms are comprehensively covered: the product name and its variations ("Sprites", "sprite-env", "sprites.dev", "a sprite"), plus task phrasings a user would actually say such as "remote sandbox", "snapshot and roll back state", "preview URL", and "third-party APIs (GitHub, Slack)". It matches the 5 anchor ("comprehensive coverage of natural terms including synonyms") — the 4 anchor ("a few natural terms missing") would apply only if common user phrasings were absent, and the product-name, CLI-name, and domain triggers leave no meaningful gap for this domain (no file extensions are relevant to cloud environments).

5 / 5

Distinctiveness Conflict Risk

The description carves out a clear niche — a named Fly.io product with distinct triggers ("Sprites", "sprite-env", "sprites.dev") — so conflict risk with other skills is minimal, matching the 5 anchor. It is not at the 4 anchor ("minor overlap risk with closely related skills"): generic sandbox/VM skills could overlap only via the shared word "sandbox", but the explicit product-name triggers dominate and the description scopes itself to this specific environment type.

5 / 5

Total

20

/

20

Passed

Validation

100%

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

Validation — 16 / 16 Passed

Validation for skill structure

No warnings or errors.

Repository
stevenknowswhy/ProfessionalBuyer
Reviewed

Table of Contents

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.