Content
78%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 well-structured, actionable Stripe routing guide that uses progressive disclosure effectively, offloading domain detail to real reference files while keeping concrete commands and guardrails inline. Its main weakness is mild verbosity and inline time-sensitive version tables that could be trimmed or relocated.
Suggestions
Tighten the payment_method_types rule by dropping the Dashboard/conversion rationale and keeping only the directive plus the payment_method_configurations/excluded_payment_method_types alternatives.
Move the API-version date and per-language SDK version table into a clearly labeled 'versioning' or 'deprecated/old patterns' section, or into a reference file, so time-sensitive data does not penalize conciseness.
Add one minimal copy-paste code snippet (e.g. instantiating StripeClient and creating a Checkout Session with integration_identifier) to lift actionability from mostly-executable to fully copy-paste ready.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is largely lean — a routing table, a critical-rules list, and terse CLI commands — but contains over-explanation (e.g. the payment_method_types rule's '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') and inline time-sensitive version/date tables that the guidelines flag as a conciseness cost when not in a deprecated section. This fits 'efficient; minor instances of over-explanation that could be trimmed' (4) rather than the fully lean anchor (5) or mostly-efficient-with-notable-padding (3). | 4 / 5 |
Actionability | Provides concrete, executable guidance: specific CLI commands ('npm i -g @stripe/cli', 'stripe sandbox create', 'stripe whoami --format json'), exact parameter names ('automatic_tax: { enabled: true }', 'payment_method_types: ["card_present"]', 'integration_identifier'), and a task→API routing table. It is mostly executable with minor gaps — full copy-paste code is sparse and implementation detail is deferred to reference files — fitting the 4 anchor better than the fully copy-paste-ready 5 anchor or the pseudocode/incomplete 3 anchor. | 4 / 5 |
Workflow Clarity | The integration-routing table gives a clear decision sequence (what you're building → recommended API → reference file) with 'Read the relevant reference file before answering' as the next step, and the critical-rules section supplies guardrails including a validation checkpoint for the risky automatic_tax case ('confirm the user has an active registration'). This matches 'clear sequence with most checkpoints present; minor validation gaps' (4); it is not a fully checkpointed feedback-loop workflow (5), and the validation present keeps it above the no-validation 3 anchor. | 4 / 5 |
Progressive Disclosure | SKILL.md is a concise overview with well-signaled one-level-deep references — the routing table maps each task to a real reference file (<references/payments.md>, connect.md, billing.md, tax.md, treasury.md, security.md), all of which exist in ./references/, and details are appropriately split out rather than inlined. This matches the anchor for a clear overview with well-signaled one-level-deep references and easy navigation; it is not merely 'mostly clear with minor gaps' (4). | 5 / 5 |
Total | 17 / 20 Passed |