Content
50%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 CLI operational guidance is concrete, executable, and sequenced with a polling checkpoint, which is the skill's real strength. It is undermined by a ~240-line inlined entity/policy/procedure list that bloats the token budget without actionable guidance and by the absence of verification steps for destructive record/workflow operations.
Suggestions
Move the entity/policy/procedure enumeration into a separate reference file (e.g. references/entities.md) and link to it, or remove it in favor of the action-discovery workflow that already surfaces available entities.
Add an explicit verify-after-run checkpoint for write/automation actions, e.g. re-query the affected record or check the action output's success/status before reporting completion.
Tighten the overview to the handful of top-level resources users actually manipulate and let `membrane action list --intent` cover the long tail.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body inlines roughly 240 bullet points enumerating every OysterHR entity, policy clause, and procedure (lines 23-259), which is heavy padding that adds little actionable value, while the CLI sections themselves are reasonably tight. Not a 1 because the operational sections are efficient and not concept-explaining; not a 3 because the inlined entity list is a large, clearly unnecessary padded section. | 2 / 5 |
Actionability | Concrete copy-paste commands are provided throughout ("membrane login --tenant --clientName=<agentType>", "membrane connection ensure", "membrane action run <actionId>", "membrane request CONNECTION_ID /path"), plus a flags table for proxy requests. Not a 5 because the giant entity list and "Use action names and parameters as needed" are non-executable filler and a few flows lack worked parameter examples. | 4 / 5 |
Workflow Clarity | A clear sequence exists (install, login, connection ensure, poll until READY, search actions, run/proxy) with a polling checkpoint and state-based branching for CLIENT_ACTION_REQUIRED, but the actual action execution — which manages records and automates workflows (destructive/batch-capable) — has no verify-after-run checkpoint. The destructive/batch cap holds this at 3 rather than 4. | 3 / 5 |
Progressive Disclosure | The body has section headers and a logical flow for the CLI usage, but no bundle files exist and the ~240-line entity enumeration is inlined bulk content that belongs in a separate reference file. Not a 4 because that inlined bulk is not split out or referenced; above 2 because the operational sections are genuinely well-structured with headers. | 3 / 5 |
Total | 12 / 20 Passed |