Conciseness

The body is lean and command-first with no explanations of concepts Claude already knows, and the connection-state and proxy-flag material is reference-dense rather than padded. Minor instances could be trimmed — the rambling "Agent Types" aside ("claude, openclaw, codex, warp, windsurf, etc. Those will be used to adjust tooling..."), the near-duplicate `action list` command in "Popular actions", and the "Best practices" prose — so it is anchor 4, not the every-token-earns-its-place level of 5.

Actionability

Concrete, executable CLI commands appear throughout (`npm install -g @membranehq/cli@latest`, `membrane connection ensure "https://banked.com/" --json`, `membrane action run <actionId> --input '{"key": "value"}'`, plus a complete proxy flag table), which is mostly copy-paste ready. It is not 5 because the "Popular actions" section contains no actual popular actions, `CONNECTION_ID` and `<actionId>` are never shown with a concrete worked example, and the Banked Overview's "Use action names and parameters as needed" is directionless.

Workflow Clarity

The install → login → connect → discover → run sequence is present and the connection phase has a good polling/state checkpoint loop (READY / BUILDING / CLIENT_ACTION_REQUIRED with instructions to re-poll), but the flow is incoherent in places — it says "skip to **Step 2**" though no Step 2 exists, and a "1b" subsection appears with no "1a" or Step 1 header. More importantly, running Banked payment actions moves money, and there are no verification or confirmation steps before `action run`, so the destructive/batch-operations cap of 3 applies.

Progressive Disclosure

This is a well-organized single-file skill: clear section headers, no nested or dead-end references, and at ~140 lines the workflow content appropriately lives inline (connection state handling, auth, and proxy usage are core, not auxiliary). It is not 5 because of minor organization gaps — the empty "Popular actions" section, the inconsistent step numbering, and the auth/proxy detail that could sit in one-level-deep reference files if the skill grows.

Specificity

The description names the domain ("Banked integration") but its actions are generic — "Manage data, records, and automate workflows" is buzz phrasing equivalent to the bad example "Processes data", with no concrete capability like processing payments or listing transactions. It falls at the 'names the domain but actions are minimal or generic' anchor, not the 3 anchor, which requires at least one concrete action.

Completeness

An explicit "Use when the user wants to interact with Banked data" clause is present, so the missing-'Use when' cap applies no further, but the 'what' is vague ("Manage data, records, and automate workflows") and the 'when' merely restates the domain rather than giving concrete triggers. It sits between anchor 3 (clear what, weak when — here reversed: present but circular when, vague what) and anchor 4, and the vagueness of the 'what' keeps it from 4.

Trigger Term Quality

"Banked" and "interact with Banked data" are genuine natural keywords a user would say, but common variations and synonyms — payments, bank payments, transactions, pay by bank — are absent. Coverage exceeds the 'one or two generic keywords' of anchor 2 but is thinner than the 'good keyword coverage, a few natural terms missing' of anchor 4.

Distinctiveness Conflict Risk

Every clause is anchored to the named app "Banked", making it mostly distinct with only minor overlap risk from the generic "data, records, workflows" phrasing. It is not anchor 5 because no concrete payment-specific actions or triggers lock the niche, and not anchor 3 because the brand name in the trigger clause substantially reduces overlap with generic data-management skills.