Content
71%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 lays out a clear, well-sequenced catalog-first workflow with concrete fetch targets, explicit fallback logic, and sensible operational rules. Its main weaknesses are an intro paragraph that fully restates the Workflow section and missing execution details — no fetch or install commands, undefined ADD_TERM/CANDIDATES semantics, and no post-install verification. One notable design risk is that it instructs the agent to follow remotely served "Procedure+Rules" text, though the Rules section does add a judgment caveat for that.
Suggestions
Delete or compress the intro paragraph, which restates the entire Workflow section (catalog-first match, hosting fallback, component-search fallback) — keeping one authoritative description saves ~5 lines and removes the stale-feeling phrase 'fall back exactly to today's behavior'.
Add the concrete commands for the fetch and install steps: the curl invocation for https://basic-anteater-667.convex.site/capabilities.json, an example of setting ADD_TERM for /add-component, and the actual npm/npx install command for the chosen @convex-dev component, so step 4 is executable without guessing.
Add a post-install verification checkpoint before confirming to the user (e.g., check the deployment or component status) and specify how /capability/<id>.md resolves to a full URL relative to the catalog host.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The intro paragraph ("Step 1: fetch the served capability catalog — … 'hosting' wires @convex-dev/static-hosting; anything else runs the /add-component search script") duplicates the entire Workflow section, and phrases like "always-current, no plugin re-release needed" and "fall back exactly to today's behavior" are plugin-maintenance context irrelevant at runtime. Mostly efficient, but a whole redundant paragraph could be cut — more than a minor trim. | 3 / 5 |
Actionability | Gives mostly executable guidance: an exact catalog URL with a "4s timeout", match fields ("title/summary/trigger"), and parameterized fallbacks ("run /add-hosting; … run /add-component with ADD_TERM set. Read CANDIDATES output"). Not fully executable: no curl/install command is shown, ADD_TERM semantics and the CANDIDATES format are undefined in this file, and "install best match, wire per README" delegates the key execution detail. | 4 / 5 |
Workflow Clarity | Five clearly sequenced steps with explicit fallback branching ("FALLBACK (no match or catalog unreachable)") and a sandbox-blockage escape hatch. Minor validation gap: step 5 says "Confirm the addition to the user" without any check that the install actually succeeded, so it lacks the explicit verification a 5 requires. | 4 / 5 |
Progressive Disclosure | No bundle files exist (references/, scripts/, assets/ are absent), so there are no broken or nested references to verify; the body is under 50 lines with well-organized ## Workflow and ## Rules sections. Per the simple-skill guideline, a short, single-purpose skill with no need for external files and clean section organization scores 5. | 5 / 5 |
Total | 16 / 20 Passed |