Content
72%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 content is highly actionable — complete executable curl examples for all six capabilities with clear auth setup — and mostly token-efficient. Its weaknesses are the implicit send-then-check workflow with no error-handling guidance, and the monolithic inlining of full parameter references that would fit better in a reference file.
Suggestions
Explicitly sequence the OTP flow (e.g. "Send Phone Code → user receives code → Check Phone Code within three attempts") and add guidance for handling failed or declined results.
Move the verbose AML and Database Validation parameter references into a references/ file (e.g. references/aml.md), keeping one compact example per endpoint in SKILL.md.
Remove the duplicated capability descriptions (the Capabilities list repeats the Usage section intros verbatim) to save tokens.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is dominated by terse parameter lists and compact curl commands, e.g. "phone_number* (string) - Phone number in E.164 format (e.g. +14155552671)" — efficient with only minor padding such as the duplicated AML intro sentence ("The AML Screening API allows you to screen individuals or companies against global watchlists...") in both Capabilities and Usage, and marketing prose like "mitigate risks associated with financial fraud and terrorism". Not a 5 because these few padded sentences could be trimmed. | 4 / 5 |
Actionability | Every endpoint has a fully executable, copy-paste-ready curl command with auth headers and a realistic request body (e.g. the /v3/phone/check example with +1234567890 and code 123456), plus concrete credential setup including a fallback instruction ("If ~/.gooseworks/credentials.json does not exist, tell the user to run: npx gooseworks login"). Common cases for all six capabilities are covered. | 5 / 5 |
Workflow Clarity | Endpoints are individually documented but the core OTP workflow (send code → user receives → check code) is only implied by section names, never explicitly sequenced, and there is no guidance on handling failed checks or declined actions (e.g. what to do when duplicated_phone_number_action returns DECLINE). Not a 4 because the pairing of send/check steps and error handling is left implicit rather than having only minor gaps. | 3 / 5 |
Progressive Disclosure | The body is well-sectioned (Setup, Capabilities, Usage, Use Cases, Discover More) but is ~165 lines with the full 15-parameter AML reference and the database-validation parameter list inlined, and no bundle/reference files exist to offload them. Not a 4 because API reference content that clearly belongs in a separate file is inline; not a 2 because the section structure itself is clear and navigable. | 3 / 5 |
Total | 15 / 20 Passed |