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.
A well-structured, mostly executable reference for Apollo Server v4 testing with strong anti-pattern coverage and honest limitations. The main gaps are a placeholder plugin in the APQ example, some redundancy between the result-type explanation and the code examples, and an implicit rather than explicit step sequence.
Suggestions
Replace the placeholder in the APQ test ("plugins: [/* strict-allowlist plugin from manifest */]") with a minimal working strict-allowlist plugin implementation, or link to a reference file containing it, so the example is copy-paste executable.
Trim the "Parsing results" section: drop the inline TypeScript union block and keep only the practical rule (check kind === 'single' first, assert extensions.code rather than message), since the four code examples already demonstrate the shape.
Move the CI workflow yaml and the production-config/APQ test suites into a references/ file (e.g. references/production-config-tests.md) and keep one-line pointers in SKILL.md, reducing the main file's token footprint while preserving discoverability.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense and high-value — tight code with instructive comments ("// OS picks port → parallel-test safe"), an anti-patterns table, and a limitations section — with only minor trimmable material: the TypeScript result-union block in "Parsing results" restates what four code examples already demonstrate, and the prose after the CI yaml ("run separately with NODE_ENV=production") repeats the workflow's own env block. Not 5 because of these few over-explanatory tokens; not 3 because there is no padding or explanation of concepts Claude already knows. | 4 / 5 |
Actionability | Nearly everything is copy-paste ready: install command, executeOperation test, context injection, supertest setup with beforeAll/afterAll, two production-config tests, and a CI workflow. Not 5 because the persisted-query example contains a non-executable placeholder — "plugins: [/* strict-allowlist plugin from manifest */]" — on which that entire test depends, and snippets reference undefined identifiers (GET_LAUNCH, userAPI) without noting they are illustrative. | 4 / 5 |
Workflow Clarity | The skill is organized as a coherent sequence (Install → Authoring → Running → CI integration), and the Overview/When-to-use sections explicitly guide the key decision (executeOperation vs supertest); validation checkpoints appear as embedded rules ("Always check kind === 'single' first", "Check errors === undefined first", "Always stop"). Not 5 because the sequence is implicit in section order rather than explicit, and error-recovery guidance (what to do when a prod-config assertion fails) is only implicit in the anti-patterns table; not 3 because checkpoints and failure-mode fixes are present, and no destructive/batch-operation cap applies. | 4 / 5 |
Progressive Disclosure | No bundle files exist, and the ~230-line body is well-sectioned (Authoring, Running, Parsing results, CI integration, Anti-patterns, Limitations, References) with clearly labeled external Apollo doc links — good structure with minor organization gaps. Not 5 because the under-50-line exception does not apply and some content (the CI yaml, the production-config and APQ test suites) could arguably live in reference files to slim the main file; not 3 because nothing is buried and no reference chain exists. | 4 / 5 |
Total | 16 / 20 Passed |