Content
67%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 delivers a strong, executable workflow for connecting to ApplicantStack via the Membrane CLI, with a genuine polling/validation loop for connection states. Its weaknesses are padded introductory content, an uninformative entity bullet list, and a broken "Step 2" cross-reference.
Suggestions
Trim the product-description intro and the bare entity bullet list, or convert it into a one-line sentence naming the key objects (applicants, jobs, offers, tasks) — it currently spends ~20 lines on almost no actionable signal.
Fix the dangling "skip to **Step 2**" reference by actually labeling the workflow steps (e.g. "Step 1: Connect", "Step 2: Find and run actions"), and standardize on one CLI invocation form (`membrane` vs `npx @membranehq/cli`).
Add brief guidance on interpreting action run output and handling API errors from proxy requests, since those are the steps where failures will surface.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The command documentation is efficient, but the marketing-style intro ("ApplicantStack is an applicant tracking system that helps businesses manage their hiring process. Recruiters and HR departments use it to..."), the 16-line bullet list of bare entity names with no guidance, and the "Agent Types" aside add padding that could be cut. Mostly efficient with some unnecessary explanation — anchor 3, not 4. | 3 / 5 |
Actionability | Concrete copy-paste commands cover the main flows: `npm install -g @membranehq/cli@latest`, `membrane login --tenant --clientName=<agentType>`, `membrane connection ensure "https://www.applicantstack.com/" --json`, `membrane action run <actionId> --connectionId=... --input '{"key": "value"}'`, plus the proxy flags table. Minor gaps keep it from 5: a dangling reference to "**Step 2**" that is never labeled, and inconsistent invocation (`membrane` vs `npx @membranehq/cli`). | 4 / 5 |
Workflow Clarity | The sequence install → login → ensure connection → poll state → handle clientAction → search actions → run → proxy fallback is clear, and connection-state handling (READY / CLIENT_ACTION_REQUIRED / CONFIGURATION_ERROR with "poll again after the user completes the action") forms a real feedback loop. Anchor 4 rather than 5 because the "Step 2"/"1b" numbering is inconsistent and running actions/proxy requests themselves have no output-validation guidance. | 4 / 5 |
Progressive Disclosure | Well-organized single-file skill with clear section headers and no buried or nested references (no bundle files exist to verify). The inlined connection-state table and proxy flag reference are reasonably sized for a single-file skill, though the connection lifecycle detail could live in a separate reference file. Anchor 4, not 5 — it exceeds the under-50-line simple-skill case and is not split into reference files. | 4 / 5 |
Total | 15 / 20 Passed |