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 content is actionable and well-structured with a genuine validation loop on connection setup, but it carries some padded prose, an inconsistency between `membrane` and `npx` invocation, and no verification step for action results.
Suggestions
Pick one invocation style (`membrane` vs `npx @membranehq/cli@latest`) and use it consistently, or explicitly state when each applies.
Add a result-verification step after `membrane action run` (e.g. inspect the `output` field and confirm expected fields) to close the workflow's validation gap.
Trim padded framing such as the sales/support-team sentence and the auth-plumbing aside to tighten token efficiency.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly efficient with executable commands, but includes several padded sentences (auth-plumbing aside, who-uses-WhosOn framing, lengthy clientAction prose) that could be tightened. | 3 / 5 |
Actionability | It provides concrete, copy-paste-ready CLI commands covering the full path from install to running actions and proxying, but inconsistently switches between `membrane` and `npx @membranehq/cli@latest` and omits sample output. | 4 / 5 |
Workflow Clarity | The connect flow has an explicit state feedback loop (BUILDING -> poll, CLIENT_ACTION_REQUIRED -> user acts -> re-poll, CONFIGURATION_ERROR -> check error), but action running lacks any result-verification checkpoint. | 4 / 5 |
Progressive Disclosure | A single well-sectioned SKILL.md with no nested references; structure is good, though the clientAction state-machine detail and proxy flag table are candidates for a separate reference file. | 4 / 5 |
Total | 15 / 20 Passed |