Content
90%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, information-dense body: every section teaches non-obvious n8n execution-tool behavior with exact commands, argument shapes, and safety gates, and it consistently enforces verification before success claims. The main improvements are structural — surfacing an explicit entry-point decision flow and moving the long tool/sub-node edge-case rules into a reference file.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dense with non-obvious, product-specific behavior (draft vs. active versionIds, 'unreconstructable-context' tags, run-step refusal rules, mocked-input semantics) and contains essentially no explanation of concepts Claude would already know. Not 4: there is no padded or over-explained passage to trim — each section adds information the model cannot infer; the rhetorical restatements ("sends the message, charges the card, or deletes the row") are doing safety work, not filling space. | 5 / 5 |
Actionability | Concrete, executable tool invocations with full argument shapes throughout: `executions(action="run-step", workflowId, nodeName, reuseExecutionId=...)`, a complete `toolArguments={"query": "login fails", "status": "open"}` example, named actions (`debug`, `get-resolved-node-parameters`, `get-node-output`, `get-as-code`), and specific field names to check (`emptyResolutions`, `failedExpressions`, `workflowVersionId`, `ranThroughNodeNames`). Not 4: the specific examples cover the common cases (failed node, fix confirmation, wrong output on a successful run) with exact commands and semantics, not high-level hints. | 5 / 5 |
Workflow Clarity | Each scenario is sequenced with explicit decision points and verification gates: re-run the failing path before claiming a fix, classify the node (read/transform = safe, write = do not run, unsure = treat as write) before run-step, and confirm a fix only via a new live run after publish — feedback loops are present for the risky operations. Not 5: the overall entry-point flow is implicit — the reader must synthesize the order across sections (when to use `debug` vs `run-step` vs `get-resolved-node-parameters`) rather than following one explicit ordered procedure; not 3: validation and safety checkpoints are explicit, not missing. | 4 / 5 |
Progressive Disclosure | The single file is cleanly sectioned by scenario and the one detail-heavy lookup (trigger inputData shapes) is pushed to a clearly-signaled one-level-deep path: "read ${N8N_WORKSPACE_DIR}/knowledge-base/reference/trigger-input-data-shapes.md". Not 5: no bundle structure exists, and at ~195 lines some specialized material (tool/sub-node/MCP-registry run-step rules) would fit better in a reference file so SKILL.md stays a lean overview; not 3: what is inline is scenario-critical and navigation is easy. | 4 / 5 |
Total | 18 / 20 Passed |