Content
56%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 operational core (install, auth, connection lifecycle, action search/run, proxy) is strong — concrete, executable, and sequenced with a state-based feedback loop. The skill is dragged down by the massive auto-generated entity-name list, which adds no guidance, contains duplicate and nonsensical entries, and should be removed or moved to a reference file.
Suggestions
Delete or drastically trim the 'CommCare Overview' entity bullet list — it is ~160 lines of padding including duplicated nonsense entries ('Case Search Search', 'Data Export Schedule Schedule'); if entity coverage matters, move a curated list to a references/ file and link it.
Fix the dangling workflow references: label the step the text calls 'Step 2' (searching/running actions) and reconcile the '1b' subsection numbering so the sequence reads coherently.
Add one end-to-end worked example (e.g., list cases in a domain) showing actionId resolution from 'membrane action list' output through 'membrane action run' with a real --input payload.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The ~160-line 'CommCare Overview' bullet list of entity names — including auto-generated nonsense entries like 'Data Export Schedule Schedule', 'Case Search Search', and 'User Search Search' — is pure padding occupying half the body, capped by the vague 'Use action names and parameters as needed.' The operational sections are efficient, keeping this above 1, but the padding is far too large to call 'some unnecessary explanation' (3). | 2 / 5 |
Actionability | Copy-paste-ready commands throughout: 'npm install -g @membranehq/cli@latest', 'membrane connection ensure "https://www.dimagi.com/commcare/" --json', 'membrane action run <actionId> --input \'{"key": "value"}\'', plus a concrete proxy flags table. Falls short of 5 because resolving an actionId to a runnable command and common-case input payloads are only described, not demonstrated. | 4 / 5 |
Workflow Clarity | Clear sequence (install → login incl. headless variant → connection ensure → poll with --wait → state-based decision tree for READY/CLIENT_ACTION_REQUIRED/CONFIGURATION_ERROR → search actions → run → proxy fallback) with an explicit feedback loop (poll, user completes action, poll again). Minor gaps: the text says 'skip to Step 2' but no Step 2 is labeled, and numbering is inconsistent ('1b' without a matching '1a' heading). | 4 / 5 |
Progressive Disclosure | No bundle files exist (no references/, scripts/, or assets/), so everything is inline. The document has real section structure for the operational content, but the 160-line entity list is bulk material that should live in a separate reference file — matching the 'content that should be separate is inline' anchor. Not 4 because there is no file split or reference signaling at all; not 2 because the working sections are well-organized and navigable. | 3 / 5 |
Total | 13 / 20 Passed |