Content
81%Weight 40%Scale 1-5Reviews 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, high-signal operations guide: it sequences inspect→retrieve→apply→validate with genuine validation checkpoints and safety guards, and it consistently points at authoritative live docs instead of duplicating them. Its weaknesses are modest — an inline version pin, few complete example command lines, and Previews detail that would sit better in a separate reference file.
Suggestions
Add one or two complete, copy-paste-ready example invocations (e.g., `wrangler deploy --dry-run --env <env>` and `CLOUDFLARE_ENV=preview wrangler dev`) alongside the existing flag-level guidance.
Move the Wrangler version requirements (e.g., "Wrangler 4.135.0 or later") into a short versioning/compatibility subsection so time-sensitive pins don't age the main guidance.
Consider splitting the two Previews sections into a previews.md reference file and keeping a brief decision summary plus a link in SKILL.md, matching the task→source table pattern already used for external docs.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense, imperative, and free of concept re-teaching — every line adds non-obvious guidance ("CLI flags and configuration fields change; do not rely on memorized examples"). It loses a point only because time-sensitive version pins ("Workers Previews requires project-local Wrangler 4.135.0 or later") sit inline rather than in a dedicated deprecations/versions section. | 4 / 5 |
Actionability | Concrete commands and flags appear throughout ("wrangler --help", "wrangler/config-schema.json", "wrangler types", "wrangler deploy --dry-run", "CLOUDFLARE_ENV", "wrangler versions secret"), giving mostly executable guidance. It stops short of copy-paste-ready full invocations (e.g., an example `wrangler deploy --dry-run --config … --env …` line), which keeps it below a 5. | 4 / 5 |
Workflow Clarity | The body is a clear sequenced workflow — Inspect the Project → Retrieve What the Task Needs → Apply the Change → Validate — with explicit validation checkpoints (regenerate types, run typecheck/tests, `--dry-run`, report unresolved gaps) and explicit guards on destructive operations ("Writes to production resources, destructive testing, and deletion of named Previews must match the user's explicit intent"). | 5 / 5 |
Progressive Disclosure | Sections are well organized with an effective task→source navigation table and clearly signaled, one-level-deep links to Cloudflare docs. However, no bundle files exist and the ~66-line body inlines all detail (notably two full Previews sections) that could be split into reference files, which is a minor organization gap rather than a clear 5. | 4 / 5 |
Total | 17 / 20 Passed |