Content
75%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 lean, command-first guide with genuinely good handling of the trickiest part — connection state branching and re-authentication flows — and concrete executable commands throughout. Its main weaknesses are the dangling 'Step 2' references that break the numbered flow, an unnecessary ActBlue background paragraph, and the total absence of ActBlue-specific action examples, which leaves the guide reading like generic Membrane boilerplate rather than an ActBlue skill.
Suggestions
Define or remove the 'Step 2' references — either number the workflow steps (1. Install, 2. Authenticate, 3. Connect, ...) or rename the target sections so the 'skip to Step 2' pointers resolve.
Add one concrete ActBlue example, e.g. membrane action list --intent "list recent contributions" --connectionId=... --json plus a sample action run with realistic input and output, so action usage is not purely placeholder-driven.
Trim the opening paragraph about what ActBlue is and who uses it (Claude already knows this), and either explain the bare 'Overview' entity list (Contribution Form, Line Item, Recurring Contribution Series, User) or cut it.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly lean, command-first content with a dense flag table and little padding. Minor instances of over-explanation could be trimmed — the opening paragraph explaining what ActBlue is and who uses it ('ActBlue is an online fundraising platform for Democratic candidates... It's primarily used by Democratic campaigns, progressive non-profits...') is background Claude already knows, and the 'Agent Types' aside is awkwardly written. This matches anchor 4 rather than 3 because the padding is minor relative to the document's overall density. | 4 / 5 |
Actionability | Concrete, copy-paste-ready commands cover the full path: 'npm install -g @membranehq/cli@latest', 'membrane connection ensure "https://secure.actblue.com/" --json', and 'membrane action run <actionId> --connectionId=CONNECTION_ID --input {...} --json', plus a proxy flag table. It matches anchor 4 rather than 5 because no ActBlue-specific example appears — every action example uses placeholders or a generic '{"key": "value"}' input instead of a realistic contribution query, so the common cases are not covered. | 4 / 5 |
Workflow Clarity | The setup sequence (install → login → connection ensure → poll/branch by state → search actions → run) is clear, with an explicit state-branching feedback loop for connection readiness ('CLIENT_ACTION_REQUIRED — the user or agent needs to do something' followed by 'poll again with membrane connection get <id> --json to check if the state moved to READY'). It is anchor 4 rather than 5 because 'Step 2' is referenced twice ('skip to Step 2') but never defined, and the core action-run and proxy steps have no error-handling or output-validation guidance. | 4 / 5 |
Progressive Disclosure | A single ~150-line file with clear section headers ('## Working with Actblue', '### Proxy requests', '## Best practices') and appropriately scoped content; no bundle files exist and none are strictly required. This matches anchor 4's 'good structure; most content appropriately placed' — it is not 5 because the under-50-line simple-skill exception does not apply, and detail-heavy material such as the clientAction state reference and the proxy flag table would sit naturally in a separate reference file. | 4 / 5 |
Total | 16 / 20 Passed |