Content
61%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 strongly command-driven with concrete, executable CLI examples and a sensible connection-to-action flow, but it contains marketing fluff, a broken 'Step 2' cross-reference that breaks the workflow's coherence, and no worked example of running an actual action with parameters.
Suggestions
Fix the dangling cross-references: number the sections as Step 1/2/3 (or remove 'skip to **Step 2**' and '#### 1b'), so the READY-state instruction points at a section that exists.
Trim marketing filler ('It's used by brands, retailers...', 'so you can focus on the integration logic rather than auth plumbing', 'Use action names and parameters as needed.') and add one concrete filled-in action example, e.g. `membrane action run search-products-by-keyword --input '{"keyword": "coffee grinder"}'`.
Add a short error-recovery note for action runs (checking the response for errors and re-polling/re-authenticating), matching the validation checkpoints already present in the connection flow.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Mostly command-driven and efficient, but it includes padding Claude doesn't need: 'It's used by brands, retailers, and researchers to monitor market trends and optimize their Amazon strategies', 'Membrane handles authentication... so you can focus on the integration logic rather than auth plumbing', and the filler line 'Use action names and parameters as needed.' Fits 'mostly efficient but includes some unnecessary explanation or could be tightened' — not score 4 because there are several such instances rather than minor ones. | 3 / 5 |
Actionability | Nearly all guidance is executable: concrete install/login/connection commands, a filled `membrane connection ensure` example, an action-search command, a popular-actions table with real keys, and a proxy-request flags table. Not score 5 because `membrane action run <actionId>` is only shown with placeholders — no concrete filled-in example (e.g. running search-products-by-keyword with an actual --input payload), leaving the most common case unshown. | 4 / 5 |
Workflow Clarity | The sequence (install → login → connection ensure → poll to READY → search actions → run) is present with state-based checkpoints (BUILDING/CLIENT_ACTION_REQUIRED/CONFIGURATION_ERROR handling). But it references 'skip to **Step 2**' and a '#### 1b' heading with no numbered Step 1 or Step 2 existing in the document, and there is no guidance on validating or reacting to a failed action run. This lands on 'steps listed but validation gaps; checkpoints missing or implicit' rather than 4. | 3 / 5 |
Progressive Disclosure | No bundle files exist, and the single-file body is well-sectioned (install, auth, connecting, searching, running, proxy, best practices) with no nested references — content is appropriately placed for a ~150-line skill. Minor gaps: the proxy flag table and connection-state reference could live in a reference file, and the action catalog is only hinted at via `action list`, so it doesn't reach the fully optimal 5. | 4 / 5 |
Total | 14 / 20 Passed |