Conciseness

The body opens by explaining what Adobe Acrobat Sign is — 'a cloud-based service for electronic signatures... commonly used by businesses of all sizes to streamline document workflows and obtain legally binding signatures' — a concept Claude already knows, and includes marketing padding like 'so you can focus on the integration logic rather than auth plumbing' and 'This will burn less tokens'. The bulk of the body (commands, tables, state handling) is lean, so this lands at anchor 3 (mostly efficient, some unnecessary explanation) rather than 2.

Actionability

Concrete copy-paste commands throughout: 'npm install -g @membranehq/cli@latest', 'membrane connection ensure "https://acrobat.adobe.com/" --json', 'membrane action run <actionId> --connectionId=CONNECTION_ID --input ...', plus a full proxy flag table. Minor gaps keep it below anchor 5: 'membrane action run <actionId>' is never reconciled with the 'Key' column in the Popular actions table (is the key the id?), and the parameter example is the generic placeholder '{"key": "value"}' rather than one real worked call such as running list-agreements.

Workflow Clarity

The setup sequence (install → login → connection ensure → poll state → handle clientAction → re-poll → search actions → run → proxy fallback) has genuine validation checkpoints and a feedback loop: poll until state leaves BUILDING, act on CLIENT_ACTION_REQUIRED, check the error field on CONFIGURATION_ERROR/SETUP_FAILED. Held below anchor 5 by incoherent step numbering — 'skip to Step 2' references a step that is never labeled, and section '1b' exists with no '1a' or 'Step 2' heading, leaving the sequence ambiguous at exactly one transition.

Progressive Disclosure

Sections are well-headed and commands are scannable, but the ~157-line body keeps everything inline: the 18-row Popular actions table, the clientAction schema taxonomy, and the proxy flag table are all candidates for a one-level-deep reference file, and no bundle files (references/, scripts/, assets/) exist at all. This matches anchor 3 — some structure, but content that should be separate is inline — rather than 4, since there is no reference layer for content that clearly does not need to sit in the main context.

Specificity

The description names the domain and three resource types ("Manage Users, Agreements, Widgets"), but "Manage" is a single generic verb — no concrete operations like sending agreements for signature, downloading audit trails, or creating widgets. It matches anchor 3 (names domain and 1-2 concrete actions, not comprehensive); it is above anchor 2 because the three named resources go beyond minimal/generic, but below anchor 4 because the actions themselves are never specified.

Completeness

It has a clear 'what' ("Manage Users, Agreements, Widgets") and an explicit 'when' ("Use when the user wants to interact with Adobe Acrobat Sign data"), satisfying the 'Use when...' requirement. It falls short of anchor 5 because the 'when' clause is circular — it restates the product name rather than giving concrete trigger phrases like 'when the user wants to send a document for electronic signature'.

Trigger Term Quality

"Adobe Acrobat Sign", "Users", "Agreements", and "Widgets" are relevant keywords, but common natural phrases users would say are missing — "electronic signature", "e-sign", "send a document for signing", "EchoSign". This fits anchor 3 (some relevant keywords but missing common variations or synonyms); not 4 because the trigger vocabulary is limited to the product name and object labels with no synonyms or natural user phrasing.

Distinctiveness Conflict Risk

The explicit product naming ("Adobe Acrobat Sign") gives a clear niche with distinct triggers and minimal conflict risk — no generic language that would collide with other skills. Voice is third person throughout, so no person-perspective penalty applies.