Content
63%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 operational guide with real, copy-pasteable commands and a well-handled connection state machine, but it overruns its token budget for a SKILL.md by inlining reference-grade detail and carries small consistency defects (dangling Step 2, duplicated discovery command, filler lines). Splitting the proxy flags and clientAction details into reference files and tightening the duplicated sections would lift both conciseness and structure.
Suggestions
Fix the broken step numbering: "skip to Step 2" has no Step 1 or Step 2 headings — either add them or rewrite as prose references to the named sections.
Move the proxy flag table and the clientAction schema breakdown into a reference file (e.g., references/proxy.md and references/connection-states.md) and keep a one-line pointer in SKILL.md.
Drop filler lines ("Use action names and parameters as needed", the bare entity tree) and unify command invocation to a single form instead of alternating between "membrane ..." and "npx @membranehq/cli@latest ...".
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly operational and avoids explaining concepts Claude already knows, but it contains filler ("Use action names and parameters as needed"), an entity list with no purpose attached, and duplicates the action-discovery command twice with inconsistent invocation ("membrane" vs "npx @membranehq/cli@latest"). This fits "Mostly efficient but includes some unnecessary explanation or could be tightened"; it is above 2 because padding is limited rather than pervasive. | 3 / 5 |
Actionability | Concrete executable commands cover install, login (including headless completion), connection ensure, long-poll waiting, action search/run with JSON input, and proxy requests with a complete flags table. It falls short of 5 because "skip to Step 2" references a step that is never labeled, and the membrane vs npx invocation inconsistency leaves the reader guessing which form to use. | 4 / 5 |
Workflow Clarity | The install → login → connect → poll → search → run sequence is clear, with genuine validation checkpoints in the connection state machine (CLIENT_ACTION_REQUIRED re-poll loop, CONFIGURATION_ERROR error-field inspection). It is not 5 because the "Step 1b / Step 2" numbering is broken and there is no verification step after running mutating actions on records or content. | 4 / 5 |
Progressive Disclosure | Sections are well-organized with no nested references (there are no bundle files at all), but at ~145 lines everything is inline: the proxy flag table, the clientAction schema breakdown, and the agent-type notes are reference-grade detail living in the main file. This matches "Some structure but could be better organized; content that should be separate is inline"; it is above 2 because the structure that exists is genuinely usable. | 3 / 5 |
Total | 14 / 20 Passed |