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 strong, highly actionable body: n8n-specific rules Claude cannot derive on its own, executable code, exact parameter names, and real verification loops. The two weaknesses are repetition (the core rules appear four times in three formats) and reference files that are cited but missing from the bundle.
Suggestions
Consolidate redundancy: pick one of the opening "three rules", the Anti-patterns table, or the Quick Reference Checklist as the single summary surface and trim the others — the "Remember" closing line can go entirely.
Ship the four referenced files (BINARY_BASICS.md, AGENT_TOOL_BINARY.md, MERGE_FOR_CONTEXT.md, CDN_REQUIREMENT.md) in a references/ directory, or inline their essential content — as written, every "See X.md" pointer dead-ends.
The nine-entry "Integration with Other Skills" section can be trimmed to the 3-4 skills with real handoff seams (code-node, code-tool, workflow-patterns); the rest are one-line courtesies that cost tokens.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with n8n-specific, non-obvious knowledge ($binary/$json split, combineByPosition re-attachment, passthroughBinaryImages limits) and never explains generic concepts Claude already knows — matching the score-4 anchor (efficient, minor instances that could be trimmed). It falls short of 5 because the same rules are restated three times: the opening "three rules", the Anti-patterns table, and the Quick Reference Checklist, plus a closing "Remember" line that repeats them a fourth time. | 4 / 5 |
Actionability | Guidance is copy-paste concrete: executable Code-node snippets (getBinaryDataBuffer, Buffer.from(...).toString('base64') with the full binary slot shape), exact field names (responseFormat: "file", combineByPosition, executeOnce: true, includeOtherFields, binaryPropertyOutput), an ASCII wiring diagram for the Merge pattern, and named MCP tools (n8n_executions) for verification. This matches the score-5 anchor — fully executable guidance covering the common cases. | 5 / 5 |
Workflow Clarity | Multi-step processes are explicitly numbered with checkpoints: the inbound staging sequence includes the synchronization-barrier warning and executeOnce: true to prevent N-runs-per-N-files, and the "Verifying binary survived" section provides a genuine feedback loop (produce execution → inspect per-node output → locate the strip point → apply the fix there). Since validation/verification steps are present, the destructive/batch cap at 3 does not apply; this fits the score-5 anchor. | 5 / 5 |
Progressive Disclosure | Structure is good: a Reference files table with "Read when" conditions, inline "See X.md" signals at point of need, one-level-deep references, and appropriate inline-vs-reference splitting — matching the score-4 anchor. It is not 5 because the four referenced files (BINARY_BASICS.md, AGENT_TOOL_BINARY.md, MERGE_FOR_CONTEXT.md, CDN_REQUIREMENT.md) do not exist anywhere in the bundle (no references/ directory), so the well-signaled navigation dead-ends for a reader; it is above 3 because the signaling and split are genuinely well done as written. | 4 / 5 |
Total | 18 / 20 Passed |