Conciseness

The body is dominated by executable commands, tables, and state-machine details that earn their tokens, with only minor over-explanation that could be trimmed: the intro paragraph explaining what BTCPay Server is ("a self-hosted, open-source cryptocurrency payment processor"), the filler line "Use action names and parameters as needed", and a garbled agent-types note. This matches anchor 4 ('Efficient; minor instances of over-explanation'); it is not a 3 because the padding is a handful of lines out of ~165, and not a 5 because those unnecessary passages exist.

Actionability

Every workflow stage has copy-paste-ready commands (npm install, membrane login, connection ensure with --wait polling, action list/run, proxy with a full flag table). Minor gap: the run example uses a generic --input '{"key": "value"}' placeholder with no real BTCPay example (e.g., create-invoice with an amount and storeId), and one command inconsistently switches from membrane to npx. This matches anchor 4 ('Mostly executable guidance... with minor gaps'); not a 5 because the common-case invocation is shown only schematically.

Workflow Clarity

The sequence (install → login → connect → poll for READY/CLIENT_ACTION_ERROR states → search → run) is present and the connection polling includes error handling, but the text tells the reader to 'skip to **Step 2**' when no Step 2 heading exists (numbering is incoherent: only '1b' appears), and destructive operations such as delete-store are listed with no verification guidance. Per the rubric cap for destructive/batch operations lacking validation, workflow clarity cannot exceed 3.

Progressive Disclosure

The file is cleanly sectioned and easy to navigate, but it is a ~165-line monolith with no bundle files at all: a 19-row action catalog and a proxy flag reference that duplicate what 'membrane action list' and CLI help provide are inlined rather than split into a references file. This matches anchor 3 ('content that should be separate is inline'); it is not a 4 because reference-type material is not placed in separate files, and not a 2 because the structure and section headers are clear.

Specificity

The description names the domain ("BTCPay Server integration") but the stated actions are generic — "Manage data, records, and automate workflows" — with no concrete operations like creating invoices, managing stores, or handling payment requests. This matches the anchor 'Names the domain but actions are minimal or generic'; it is not a 3 because no concrete action is enumerated.

Completeness

Both parts are explicitly present: what ("BTCPay Server integration. Manage data, records, and automate workflows") and when ("Use when the user wants to interact with BTCPay Server data"). The when is explicit but circular and could be more specific, matching anchor 4; it is not a 3 because the 'Use when...' clause is explicit rather than weakly implied, and not a 5 because neither part offers concrete trigger phrases.

Trigger Term Quality

"BTCPay Server" is a natural keyword and appears in the trigger clause, but coverage stops there — missing common variations users would actually say such as "invoice", "payment request", "store", "payout", or "bitcoin payments". This is 'Some relevant keywords but missing common variations or synonyms'; not a 4 because keyword coverage is one term deep.

Distinctiveness Conflict Risk

BTCPay Server is a single named application, giving the description a clear niche with a distinct trigger term and minimal risk of firing for unrelated skills. This matches anchor 5 ('Clear niche with distinct triggers; minimal conflict risk'); anchor 4 would require actual overlap with a closely related skill, which the specific app name avoids.