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 well-organized, largely copy-paste-ready operational guide: concrete CLI commands, a clear connection lifecycle with explicit state handling and polling, a useful actions table, and a proxy fallback with documented flags. The main weaknesses are minor: two dangling references to an undefined "Step 2", generic placeholder examples for running actions, and the action table being borderline content for a separate reference file. Overall a strong, executable skill body.
Suggestions
Fix the two dangling "skip to **Step 2**" references by either defining a numbered Step 2 (e.g. "### Step 2: Search for actions") or replacing them with a direct link to the "Searching for actions" section.
Add one worked end-to-end example, e.g. membrane action run list-tickets --connectionId=<id> --json, so the run path is fully concrete rather than placeholder-only.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dominated by executable commands and dense tables rather than prose, with only minor over-explanation (the opening paragraph on what Connectwise PSA is and "so you can focus on the integration logic rather than auth plumbing"). This matches anchor 4 ("Efficient; minor instances of over-explanation that could be trimmed") and is well above anchor 3's "several unnecessary explanations". | 4 / 5 |
Actionability | Nearly all guidance is copy-paste ready: "npm install -g @membranehq/cli@latest", "membrane connection ensure \"https://www.connectwise.com/...\" --json", the proxy flags table, and a popular-actions table with exact keys. It stops short of anchor 5 because the run examples remain generic ("<actionId>", "--input '{\"key\": \"value\"}'") with no worked end-to-end example such as running list-tickets against a real connection id. | 4 / 5 |
Workflow Clarity | The install → login → connection → search → run → proxy fallback sequence is clear, and the connection lifecycle has genuine checkpoints (poll with --wait, branch on READY / CLIENT_ACTION_REQUIRED with its clientAction fields / CONFIGURATION_ERROR, then re-poll). It is anchor 4 rather than 5 because "skip to **Step 2**" is referenced twice but no Step 2 is defined anywhere, and there is no guidance on verifying or handling errors after running an action. | 4 / 5 |
Progressive Disclosure | There are no bundle files, and for a ~165-line skill the single-file structure is appropriate: clean section headers, no buried or nested references, and nothing that clearly belongs in a separate file except arguably the 21-row action table. This matches anchor 4 ("Good structure; most content is appropriately placed; minor organization gaps") rather than anchor 3, whose example is 200 lines of inline API reference. | 4 / 5 |
Total | 16 / 20 Passed |