DC browser-app-delivery
Deliver a runnable local browser app so the user can operate it on the first handoff. This delivery skill does not choose whether a requested local system should be a browser app. On a current turn that explicitly says to implement a brand-new browser project now, load bundled:greenfield-project-scaffolding before project work only after no-peek or permitted top-level placement facts prove that no named or suitable current-folder target resolves the root; never hand off from planning or answer-only turns, existing work, a named or suitable target, or standalone or single-file delivery. Resolve user-blocking product or interface choices with an available interaction surface; resolving those choices alone never authorizes implementation. Always call read_skill for bundled:browser-app-delivery before creating or materially changing a local browser app that owns its start path or a playable browser game. Also load it when the user requests a paste-ready, single-file, offline, or immediately playable browser artifact, even if no local start path should remain, unless the user says they will open or check it themselves or explicitly declines verification. On completed local-server delivery, include exact start commands, a concrete local URL, and explicit browser-open wording. On completed standalone delivery, hand off the exact artifact path or paste URL and smoke result without inventing a server. Do not load it for a self-contained static file that has no owned start path if the user either says they will open or check it themselves or explicitly declines verification. Do not load it for component/style-only edits, deployed sites, backend/API-only work, browser QA, review, explanation, plan-only, or explicit stop/no-tool turns.
Deliver a runnable local browser app so the user can operate it on the first handoff.
As a process C 59/100 · Has gaps — weak spots: result and completion, inputs and preconditions
How to improve
- Shorten the description to 1024 characters.
- Your own cases (evals/evals.json, 4–6 real requests with expected answers): the full check would then run those instead of a model-drafted suite.
- A spec.yaml with trigger phrases and assertions — a behaviour contract for CI; `skilltest init` writes a template.
Guard findings · 0
✓ No critical or high findings
Files scanned: 1. Evidence is masked. Grey chips explain why severity was lowered.
Against the Agent Skills spec
- error
description-longdescription is 1753 chars, limit 1024 - note
description-budgetdescription takes 1753 of the ~15000-char shared budget for all skills
Process rating: all ten parameters 59/100
- 0Result and completion. Does not say what the result is
- 0Inputs and preconditions. Does not say what the process needs to start
- 50Failures and branches. 0 branches, has a failure section
- 60Tools and files. Uses tools (bash, web, node) that frontmatter does not declare
- 70When it triggers. States when to use, but not when not to
- 100Steps. 7 steps
- 100Consistency. Name and required fields are in place
- 100Execution cost. Instruction body is 2114 tokens
- 100Running it twice. No mutating operations
- 100Progress reporting. Reports progress
- medium Safety rules and hard prohibitions inside a skill: they belong in the system prompt, here they protect nothing
Everything here is measured from the skill text rather than judged by a model, so the numbers are checkable. A parameter weighs more when it is a more common reason for the process to stall.
Quality signals
- +5Description has no quoted example phrases that should trigger the skill
- +4Description does not say when NOT to use the skill (false activations)
- +3Description length 1753: 120–800 characters recommended
- +4Structure: 1 headings, hard to scan
- +3Output format is not stated: the model decides each time
- +4No input/output examples
- -5Long text without headings
- +1No license
- +2Single-language instructions
- +3Step-by-step instructions: 7 items
Quality base 70; lint remarks subtract, signals add up to 100. Result: 40.