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 a genuinely actionable CLI playbook — the connection lifecycle, action discovery, and proxy escape hatch are all concretely demonstrated. Its weaknesses are the padding around what Airtable is, a broken "Step 2" cross-reference, missing safety verification for destructive batch record operations, and reference-grade detail (clientAction states, proxy flags) that belongs in bundle files.
Suggestions
Fix the dangling "skip to Step 2" reference by labeling the Searching for actions section as Step 2 (and the connection section as Step 1), and add a validation step before destructive batch actions (e.g., "Run get-record or list-records first to confirm the record IDs, and confirm with the user before delete-records").
Trim the conceptual intro paragraph and the "When to use which actions" filler line; Claude already knows what Airtable is, so start with the Membrane workflow.
Move the clientAction state-enum detail and the proxy flag table into a references/ file (e.g. references/connection-states.md and references/proxy.md) linked from the body to reduce SKILL.md to a lean overview.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The bulk of the body is efficient copy-paste CLI commands, but it opens with an explanation of what Airtable is ("low-code platform... spreadsheet on steroids") that Claude already knows, and includes filler like "When to use which actions: Use action names and parameters as needed" and "This is the fastest way to get a connection". | 3 / 5 |
Actionability | Concrete executable commands throughout (npm install, membrane login, connection ensure with a real URL, action list/run with --input and --json, proxy flag table) with only minor gaps — e.g., no worked action example showing a real Airtable --input payload like a table ID and field values. | 4 / 5 |
Workflow Clarity | A reasonable install → login → connect → poll → search → run sequence exists with state-based branching (READY/CLIENT_ACTION_REQUIRED/CONFIGURATION_ERROR), but "skip to Step 2" references a step that is never labeled, and the destructive/batch operations (delete-records, update-records, up to 10 at a time) have no verification guidance, invoking the rubric's cap of 3 for batch operations without validation. | 3 / 5 |
Progressive Disclosure | Headers are well organized, but this is a ~150-line single-file skill with reference-grade material inlined (the clientAction state enum details and the proxy options table), so it does not qualify for the under-50-line exception and sits at "some structure, content that should be separate is inline". | 3 / 5 |
Total | 13 / 20 Passed |