Content
75%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 strong, highly actionable reference: executable examples for every provider, a realistic end-to-end app, and honest constraint documentation. Its main weakness is redundancy — the merged 'Netlify house rules' section duplicates the Footguns content and reads as internal maintainer instructions rather than skill guidance — plus version-sensitive details embedded in the main path.
Suggestions
Remove or collapse the trailing 'Netlify house rules' section: it duplicates the Footguns section almost line-for-line and contains maintainer meta-instructions ('The body must not present raw REST...') that add ~35 lines of tokens with no new guidance for the skill's runtime use.
Move version-sensitive details such as the 'OpenRouter SDK needs 1.2.43+' requirement into a clearly labeled compatibility note or 'old patterns' section so the main path stays stable over time.
Consider extracting the per-provider SDK snippets or the billing/limits details into a referenced file (e.g. references/providers.md) so SKILL.md remains a leaner overview with one-level-deep navigation, and add a short numbered quickstart sequence (create function → deploy --prod once → verify injected env var) to make the implicit workflow explicit.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly lean, code-first, and free of beginner explanations, but the trailing 'Netlify house rules' section (~35 lines) is maintainer meta-commentary that restates the Footguns section nearly verbatim (browser-callability, runtime-only credentials, 60s timeout, live providers endpoint), and version-pinned details like 'OpenRouter SDK needs 1.2.43+' sit in the main path rather than a deprecated/compat section. This matches the 3 anchor ('mostly efficient but includes some unnecessary explanation or could be tightened') — too much genuine duplication for the 4 anchor. | 3 / 5 |
Actionability | Fully executable, copy-paste-ready code for all five provider SDKs, a complete runnable Function + React client example with error handling, a concrete setup flow ('npm install -g netlify-cli@latest... netlify deploy --prod'), and explicit env-var pairings per provider. Specific examples cover the common cases exactly as the 5 anchor requires. | 5 / 5 |
Workflow Clarity | There is a clear implicit sequence (where code goes → SDK setup → env vars → deploy once → local dev) and the main example includes a validation checkpoint ('if (!process.env.OPENAI_BASE_URL)') plus try/catch error recovery. It falls short of the 5 anchor because the steps are distributed across sections rather than presented as one explicit ordered flow with feedback loops for the deploy-activation and streaming workarounds. | 4 / 5 |
Progressive Disclosure | A single-file skill (no references/, scripts/, or assets/ bundle exists) with well-labeled sections (Footguns, Provider SDKs, Env vars, Local development, Billing) and a clear References section of external URLs, all one level deep. It fits the 4 anchor ('good structure; most content appropriately placed; minor organization gaps') — the inlined per-provider SDK examples and billing detail arguably could be split out, and the appended house-rules block is a structural oddity, keeping it below 5. | 4 / 5 |
Total | 16 / 20 Passed |