Content
88%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.
A tight, high-signal body: lean rules that focus on non-obvious failure modes, and a validate-heavy deploy workflow with an explicit revert loop. The gaps are that schema/GROQ detail is delegated to a file outside the skill bundle that cannot be verified, and that delegation is stated as a bare path rather than a clearly labeled reference.
Suggestions
Ship the schema/GROQ documentation as a bundle file (e.g. references/sanity-config.md) inside the skill and reference it as a clearly signaled link, e.g. '**Schemas & GROQ examples**: See [references/sanity-config.md](references/sanity-config.md)', instead of a bare .opencastle/ path in the intro paragraph.
Include one short inline GROQ example (e.g. a correct array dereference `authors[]->{name,slug}` next to rule 2) so the most error-prone pattern is executable without leaving SKILL.md.
State the dataset import/export command pairing explicitly (e.g. `sanity dataset export production backup.tar` / `sanity dataset import backup.tar temp-dataset`) so step 3 of the workflow is copy-paste ready.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~25-line body is lean and assumes Claude's competence — no explanation of what a CMS is or how GROQ works; every line is either a pointer, a gotcha Claude wouldn't guess (the silent null from author-> on an array, the drafts. prefix), or a command. Matches the 5 anchor 'every token earns its place'; there is no padded section to trim for the 4 anchor. | 5 / 5 |
Actionability | Concrete guidance is present: exact commands (`sanity dataset export` / `sanity dataset import`, `sanity start`), specific API patterns (`defineType`/`defineField`, `drafts.<id>`), and a precise failure mode (author-> vs author[]->). It falls short of the 5 anchor because the actual GROQ examples and schema layouts are delegated to `.opencastle/stack/sanity-config.md`, which is a project path outside the skill bundle and unverifiable from the skill itself, and no inline example query is given — the 4 anchor's 'concrete code or commands with minor gaps' fits better than 3, since nothing here is vague. | 4 / 5 |
Workflow Clarity | "Change → validate → deploy" is a clear 5-step sequence with explicit validation checkpoints at every stage (schema errors surfaced by `sanity start`, query validation in Vision against real data, risky changes tested via export/import into a temporary dataset, full site build after deploy) and an explicit error-recovery feedback loop ("Any failure: revert locally, fix, restart from step 1"). This matches the 5 anchor's validation-plus-feedback-loop pattern exactly. | 5 / 5 |
Progressive Disclosure | The body is well structured (overview pointer + 'Rules that prevent silent failures' + numbered workflow) and the only external pointer (`.opencastle/stack/sanity-config.md`) is one level deep, keeping the overview appropriately thin — good structure per the 4 anchor. It does not reach 5 because that single reference is a bare path in the intro paragraph rather than a clearly signaled link, and it points into the project (`.opencastle/`) rather than the skill bundle (no references/ directory ships with the skill), so the detailed material's existence and organization can't be confirmed. | 4 / 5 |
Total | 18 / 20 Passed |