Content
65%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 an actionable, command-first guide with a genuinely strong connection state-handling workflow, but coherence is undermined by a dangling 'Step 2' reference and inconsistent CLI invocation. Splitting the action catalog and detailed state/proxy material into reference files would improve both conciseness and progressive disclosure.
Suggestions
Fix the dangling reference: 'If the returned connection has state: "READY", skip to **Step 2**' points to a step that is never labeled — number the workflow sections or replace it with the section name ('Searching for actions').
Use one consistent CLI invocation — 'membrane connection get <id> --wait --json' vs 'npx @membranehq/cli connection get <id> --wait --json' mix two forms for the same command in adjacent steps.
Add validation guidance for destructive actions (delete-opportunity, delete-tag) such as reading the record first and confirming with the user before deletion, and move the 20-row action catalog into a references/ file to slim the overview.
Include one worked end-to-end example with real parameter names (e.g. create-contact with an actual --input payload drawn from an action's inputSchema).
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly lean, command-driven prose ('Install the Membrane CLI so you can run membrane from the terminal', direct command blocks), with only minor trimmable content such as the opening paragraph about marketers and customer support teams and the flat overview term list. It is efficient with minor over-explanation (anchor 4), not anchor 3, since the padding is incidental rather than a systematic problem. | 4 / 5 |
Actionability | Concrete, copy-paste-ready commands appear throughout (npm install, membrane login, connection ensure with a real URL, action list/run with flags, a proxy options table) plus a 20-row action catalog. It falls short of anchor 5 because the --input example is generic placeholder JSON ('{"key": "value"}'), there is no worked end-to-end example with real parameter names, and 'skip to **Step 2**' points to a step label that does not exist. | 4 / 5 |
Workflow Clarity | The install → login → connection → state handling → search → run sequence is present with a good feedback loop for connections (poll BUILDING, handle CLIENT_ACTION_REQUIRED, re-poll, inspect error states). However, the dangling 'Step 2' reference, the inconsistent CLI invocation ('membrane connection get' vs 'npx @membranehq/cli connection get'), and the absence of any validation/confirmation guidance for destructive actions (delete-opportunity, delete-tag) leave real gaps, and the rubric caps workflow clarity at 3 for destructive operations without validation. | 3 / 5 |
Progressive Disclosure | No bundle files exist (no references/, scripts/, or assets/), so everything is inlined in a single ~175-line file. Sections are clearly headered, but the 20-row action catalog, the detailed clientAction state handling, and the proxy options table are content that could live in separate reference files. This matches 'some structure but could be better organized', not anchor 4, since a sizable action catalog is inlined in the overview file. | 3 / 5 |
Total | 14 / 20 Passed |