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 strong, executable Membrane CLI guidance with genuine state-based error handling, and is well organized for a single-file skill. Main weaknesses are marketing-fluff padding, an undefined "Step 2" reference, and a "Popular actions" section that names no actions.
Suggestions
Cut the marketing intro to one line (what Comeet is for) and delete the filler line "Use action names and parameters as needed."; standardize on one CLI invocation style (membrane vs npx @membranehq/cli@latest).
Fix the dangling "skip to **Step 2**" references by either defining Step 2 (searching/running actions) or rewording to "skip to Searching for actions", and add a note to verify the `output` field after running an action.
Populate the "Popular actions" section with the most common Comeet operations (e.g., list candidates, update a job, fetch reports) with ready-to-run command examples, or remove the heading.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The CLI guidance is mostly efficient, but the marketing-style intro ("Recruiters and HR professionals use Comeet to improve efficiency and collaboration in their hiring efforts"), the filler line "Use action names and parameters as needed.", and inconsistent invocation styles ("membrane ..." vs "npx @membranehq/cli@latest ...") add unnecessary tokens. This fits anchor 3 — could be tightened — rather than 4, where only minor trimming would be needed. | 3 / 5 |
Actionability | Commands are concrete and largely copy-paste ready (install, login, connection ensure, action list/run, proxy with a full flag table). It falls short of anchor 5 because the "Popular actions" section lists no actual actions — only the generic discovery command — so the most common use cases are not pre-specified. | 4 / 5 |
Workflow Clarity | A clear sequence is present (install → login → connection ensure → poll state → handle clientAction → search and run actions) with explicit state handling (READY / BUILDING / CLIENT_ACTION_REQUIRED / error states) forming a poll-check-act feedback loop. Not anchor 5: "skip to **Step 2**" is referenced twice but no Step 2 is defined, and no verification of action-run results (the `output` field) is prescribed. | 4 / 5 |
Progressive Disclosure | The single-file body is well-sectioned with clear headers and no buried or nested references, matching anchor 4's good structure. It does not reach 5 because content such as the clientAction state-machine detail and the proxy flag table could be split into a one-level-deep reference file for easier navigation. | 4 / 5 |
Total | 15 / 20 Passed |