Content
93%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 an exceptionally lean, actionable Stripe reference: concrete commands and API calls, explicit API-selection routing, and well-organized sections with no padding. The only soft spot is workflow_clarity, where validation is implied rather than presented as an explicit feedback loop.
Suggestions
Add an explicit validate→fix→retry sequence for webhook signature verification (e.g., numbered steps: capture raw body → verify → on failure, log signature header and retry) to lift workflow_clarity to 5.
Consider a short 'Verify before promoting' checklist for new API versions (probe with Stripe-Version header, run test triggers, confirm no removed-field errors) to make the version-upgrade workflow an explicit checkpoint loop.
| Dimension | Reasoning | Score |
|---|---|---|
Conciseness | The body is a dense, lean reference with no concept explanations — every bullet ('Restricted keys (rk_) over secret keys (sk_)', 'Store Stripe object IDs in columns accommodating 255 chars') earns its place; time-sensitive breaking-change notes are framed as old-patterns guidance and the version pin is essential one-line operational data. | 5 / 5 |
Actionability | Provides copy-paste-ready commands ('stripe listen --forward-to localhost:3000/api/webhooks', 'stripe trigger <event> --api-version 2026-03-25.dahlia', 'stripe plugin install projects') and exact API calls ('POST /v2/core/accounts', 'stripe.charges.retrieve(pi.latest_charge)'), covering common cases concretely. | 5 / 5 |
Workflow Clarity | The API-selection section gives an explicit preference order (Payment Links → Checkout → Payment Element) and routing rules, and validation checkpoints appear (verify webhook signatures against the raw body; probe a new version via the Stripe-Version header before promoting), but no explicit validate→fix→retry loop is spelled out. Not 5 because checkpoints are implied rather than presented as a sequenced feedback loop; not 3 because concrete sequencing and validation cues are present. | 4 / 5 |
Progressive Disclosure | Under 50 lines with no bundle files (references/scripts/assets absent), organized into clear sections (Never use, API selection, Gotchas) with external doc links grouped at the bottom — the simple-skill exception applies and the structure is easy to navigate. | 5 / 5 |
Total | 19 / 20 Passed |