Content
57%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 body is strong on executable commands: install, auth (with headless path), connection lifecycle with state handling, action search/run, and a proxy fallback are all concrete and copy-paste ready. Its weaknesses are a dangling 'Step 2' reference, missing validation for mutating actions, inlined reference-style tables, and a few padded passages (the 'what is Bitbucket' intro and overview tree) that assume less competence than Claude has.
Suggestions
Remove the 'Step 2' references or actually number the workflow steps (1. Connect, 2. Search actions, 3. Run) so the skip instructions resolve.
Add a verification step after running mutating actions (e.g. re-fetch via get-repository / get-issue to confirm the change landed) and guidance on handling action errors.
Cut the 'what is Bitbucket' intro paragraph and the empty overview bullet tree, and move the 20-row action catalog (and proxy flags table) into a references/ file linked from SKILL.md.
Clarify how an action key in the table maps to the actionId required by `membrane action run`, and make the polling example consistently use the `membrane` command.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | Most of the body is tight, executable CLI content, but there are several unnecessary pieces: an intro explaining what Bitbucket is ('Bitbucket is a web-based version control repository management service...'), a content-free 'Bitbucket Overview' bullet tree, filler like 'Use action names and parameters as needed.', and a padded agent-types aside. This matches anchor 3 ('mostly efficient but includes some unnecessary explanation or could be tightened') — not 4, since there are multiple distinct spots of padding rather than minor trimmable instances. | 3 / 5 |
Actionability | Nearly all guidance is copy-paste ready: install, login (including headless completion), connection ensure/get with polling, action list/run with JSON input, and a proxy command with a flags table. Minor gaps keep it below anchor 5: the popular-actions table lists keys (e.g. 'list-repositories') while `membrane action run` requires an `<actionId>` without explaining the mapping, and the polling example inconsistently uses `npx @membranehq/cli` instead of `membrane`. This fits anchor 4 ('mostly executable guidance; concrete code or commands with minor gaps'). | 4 / 5 |
Workflow Clarity | The connection flow has a genuine sequence with state-based checkpoints (READY/BUILDING/CLIENT_ACTION_REQUIRED/CONFIGURATION_ERROR and re-poll after user action), but the flow references 'skip to **Step 2**' when no numbered steps exist — a coherence gap — and running/updating actions has no validation or error-recovery steps, and mutating operations (Update Repository, Update Issue) proceed without verification. Per the guideline capping workflow clarity at 3 for unvalidated destructive/batch operations, this sits at anchor 3 ('steps listed but validation gaps; checkpoints missing or implicit'), not 4. | 3 / 5 |
Progressive Disclosure | There are no bundle files (no references/, scripts/, or assets/), so everything lives in a single ~160-line SKILL.md. Section headers and tables are well organized, but content that would naturally be separate — the 20-row popular actions catalog and the proxy flags table — is inlined, and the skill exceeds the under-50-lines threshold that would justify a 5 with sections alone. This matches anchor 3 ('some structure but could be better organized; content that should be separate is inline') rather than 4, where most reference-style content would be appropriately split out. | 3 / 5 |
Total | 13 / 20 Passed |