Content
57%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 solid, executable CLI reference with real commands, flag tables, and good connection-state error handling. Its main weaknesses are a dangling step reference that breaks the workflow numbering, some concept-explaining padding, and no progressive disclosure — everything lives inline in one file.
Suggestions
Fix the step numbering: define Step 1 (connect), Step 2 (search actions), Step 3 (run) explicitly, or remove the 'skip to Step 2' and '1b' references so the sequence is self-consistent.
Move the popular-actions catalog and proxy flag table into a references/ file (e.g., references/actions.md) and link to it, keeping SKILL.md as a lean overview with the core workflow.
Trim background prose — the 'Blocknative is a platform...' intro and reassurance sentences about auth plumbing add tokens without adding actionable guidance; one line on the proxy fallback purpose is enough.
Resolve the small ambiguities: show the value format for `--tenant` and clarify whether `membrane action run` takes the action `id` or the `Key` from the table.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly lean command documentation, but includes unnecessary padding: the opening paragraph explaining what Blocknative is ("Blocknative is a platform that provides real-time data and infrastructure for web3 developers..."), "This is the fastest way to get a connection. The URL is normalized to a domain...", and reassurance sentences like "so you can focus on the integration logic rather than auth plumbing". Fits 'Mostly efficient but includes some unnecessary explanation or could be tightened'; not 4 because several sentences could be trimmed outright. | 3 / 5 |
Actionability | Commands are concrete and copy-paste ready — `npm install -g @membranehq/cli@latest`, `membrane connection ensure "https://www.blocknative.com/" --json`, `membrane action run <actionId> --input '{"key": "value"}' --json` — with flag tables and a popular-actions catalog. Minor gaps keep it below 5: `membrane login --tenant --clientName=<agentType>` shows `--tenant` with no value, and the actions table exposes a `Key` while the run command expects an `<actionId>`, leaving the mapping ambiguous. | 4 / 5 |
Workflow Clarity | A rough sequence exists (install → login → connect → poll state → search actions → run → proxy fallback) with good state-machine handling for `READY`/`CLIENT_ACTION_REQUIRED`/`CONFIGURATION_ERROR`, but the numbering is incoherent: the text says "skip to **Step 2**" yet no Step 2 is defined, and "#### 1b. Wait for the connection" appears with no 1a/Step 1 framing. This fits 'sequence present but checkpoints missing or implicit' with gaps; not 4 because the dangling step references genuinely confuse the flow. | 3 / 5 |
Progressive Disclosure | There are no bundle files at all — the entire API surface (popular actions table, proxy flag reference, agent-type list, clientAction state reference) is inlined in a ~145-line SKILL.md. Section headers give it reasonable structure, but content that would serve better as a one-level-deep reference (e.g., the action catalog, proxy options) is inline. Fits 'Some structure but could be better organized... content that should be separate is inline'; the good sectioning keeps it above 2. | 3 / 5 |
Total | 13 / 20 Passed |