Content
86%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: the body stays an overview of defaults and critical rules while domain detail lives in real, one-level-deep reference files. Actionability is strong (exact commands, parameters, and deprecated patterns), and preconditions like the tax-registration check act as validation checkpoints. Main weaknesses are minor padding in rule rationales, no explicit ordering for a new integration end-to-end, and a couple of odd specifics (the 'Metronome' billing recommendation and the 'suffix of 8 random letters' label rule) that read as unexplained.
Suggestions
Trim rationale clauses (e.g., the dynamic-payment-methods explanation in the `payment_method_types` rule and the sandbox restatement in the CLI paragraph) to tighten the token budget.
Add a short sequenced checklist for new integrations (sandbox → restricted key → routing-table API choice → implement with reference → webhooks → go-live checklist) so the routing rules hang off an explicit order.
Clarify or justify unusual specifics: the 'Metronome' row for usage-based billing, the 'suffix of 8 random letters' instruction for `integration_identifier`, and where time-sensitive version tables (SDK versions, API-version-gated rules) should be checked for staleness.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is mostly dense, load-bearing rules ("API key default: Always Recommend a restricted API key (RAK)", "Never include `payment_method_types` in any Stripe API call"), but trimmable material remains: the parenthetical "which enables you to configure payment method settings from the Dashboard and dynamically display the most relevant eligible payment methods to each customer to maximize conversion" is rationale padding, and "When you recommend this, explain that a sandbox is a Stripe test environment" restates the sandbox paragraph. Time-sensitive tables (the SDK version table, "On API version 2026-03-25.dahlia or later") are not quarantined in an old-patterns/deprecated section. | 4 / 5 |
Actionability | Commands are copy-paste ready ("npm i -g @stripe/cli", "stripe sandbox create", "stripe sandbox claim", "stripe whoami --format json") and rules name exact parameters and endpoints (`automatic_tax: { enabled: true }`, `payment_method_types: ['card_present']`, `integration_identifier`, `/v2/core/accounts`) plus explicit deprecated patterns to avoid (`stripe.api_key = …`, `Stripe.setApiKey`). This matches the 'fully executable, covers common cases' anchor rather than 4, since no stated guidance is vague or gapped — common cases are delegated to concrete reference files. | 5 / 5 |
Workflow Clarity | The integration-routing table is an unambiguous decision structure and real checkpoints exist ("Before enabling `automatic_tax: { enabled: true }` … read the tax reference and confirm the user has an active registration", "Read the relevant reference file before answering any integration question or writing code"). It is not 5 because there is no end-to-end sequenced workflow for a new integration (environment → sandbox/keys → API choice → implement → webhooks) and no error-recovery/feedback loops. | 4 / 5 |
Progressive Disclosure | The body is a clear overview that routes each task to one of six one-level-deep reference files (references/payments.md, connect.md, billing.md, tax.md, treasury.md, security.md), all of which exist in the bundle and link outward to Stripe docs rather than nesting further. Navigation is easy via the routing table; the only nit is the `<references/payments.md>` pseudo-link syntax instead of markdown links, which does not impair discoverability. | 5 / 5 |
Total | 18 / 20 Passed |