Content
75%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.
A well-structured routing skill: concrete, opinionated rules with real reference files behind each domain. Its main weaknesses are stale-prone inlined version data (API version date and SDK version table) and reference links that target web URLs rather than the bundled files.
Suggestions
Move the 'Latest Stripe API version' and 'Latest SDK versions' table into a reference file (or a clearly dated 'current versions' section) so the body stays evergreen and does not carry token cost that rots.
Change routing-table links to relative paths (e.g., [references/payments.md](references/payments.md)) so they resolve to the bundled files rather than docs.stripe.com.
Make the pre-launch validation explicit in sequence (e.g., a final step: 'Before go-live, walk the Go Live Checklist') so the webhook and registration checkpoints read as ordered gates rather than standalone rules.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly lean and Stripe-specific, but it inlines time-sensitive version data outside any 'old patterns'/'deprecated' section: 'Latest Stripe API version: 2026-08-26.dahlia', a full 7-language 'Latest SDK versions' table (Ruby 19.6.0 … .NET 52.4.0), and a dated reference to 'API version 2026-03-25.dahlia'. These stale-prone version numbers cost tokens now and will rot, which fits the 'mostly efficient but includes some unnecessary content' anchor rather than the 'minor trim' anchor above it. | 3 / 5 |
Actionability | Guidance is fully concrete and executable: exact commands ('npm i -g @stripe/cli', 'stripe sandbox create', 'stripe whoami --format json'), exact endpoints ('Accounts v2 (/v2/core/accounts)'), and exact parameter-level rules ('automatic_tax: { enabled: true }', "payment_method_types: ['card_present']", 'allowed_payment_method_types', 'integration_identifier'). The explicit deprecated-pattern list ('stripe.api_key = …', 'Stripe.setApiKey', 'stripe.Key = …') makes the rules copy-checkable; absence of full code samples is appropriate for an instruction/routing skill. | 5 / 5 |
Workflow Clarity | The integration routing table plus 'Read the relevant reference file before answering any integration question or writing code' gives a clear, unambiguous decision sequence, and the tax rule includes a real pre-flight checkpoint ('confirm the user has an active registration' before enabling automatic_tax). Not a 5 because other checkpoints are implicit rather than explicit — the webhook fulfillment gating and the go-live checklist are stated as rules or afterthoughts rather than sequenced validation steps. Not a 3 because the sequence that exists is coherent and the main failure mode (most common Stripe Tax mistake) is explicitly guarded. | 4 / 5 |
Progressive Disclosure | The body is a true overview routing to six one-level-deep reference files (payments.md, connect.md, billing.md, tax.md, treasury.md, security.md), all of which exist in ./references/ and are clearly signaled per task in the routing table. Not a 5 because the routing links point at absolute web URLs ('[references/payments.md](https://docs.stripe.com/references/payments.md)') instead of relative paths to the bundled files, so navigation can misdirect to the hosted page rather than the local reference. | 4 / 5 |
Total | 16 / 20 Passed |