Best practices for OpenID Connect (OIDC) and OAuth 2.0 — flow selection, token validation, endpoints, discovery, and security hardening. Use when building, integrating, or reviewing authentication code: OIDC/OAuth clients (RP), authorization servers (OP), an OIDC library, ID token / JWT validation, PKCE, refresh tokens, DPoP, or logout. Triggers on OpenID Connect, OAuth, SSO, ID token, access token, auth flow, JWKS, client_secret, PKCE, or "log in with".
Pipe the response's prose to the macOS clipboard via `pbcopy` so the user can paste it directly. Use when the user says "copy to clipboard", "/copy", "pbcopy this", "put it on my clipboard", or otherwise asks for paste-ready output. macOS only.
Code-review skill with mode routing. Default lens is `standard` (alias `quick`) — correctness, security, quality in one pass with a verdict. Other modes: `security` (OWASP, high-confidence only), `architecture` (module depth, coupling, boundaries), `merge-risk` (shippability + reversibility), `intent` (alias `adversarial`) — does the diff deliver what was promised, `multi` (alias `full`) — six parallel reviewers plus a verifier. Invoke as /review-code [<mode>] [<scope>]. Use for any code-review or PR-audit task.
OAuth2.0
Guides Stripe integration decisions — API selection (Checkout Sessions vs PaymentIntents), Connect platform setup (Accounts v2, controller properties), billing/subscriptions, Treasury financial accounts, integration surfaces (Checkout, Payment Element), and migrating from deprecated Stripe APIs. Use when building, modifying, or reviewing any Stripe integration — including accepting payments, building marketplaces, integrating Stripe, processing payments, setting up subscriptions, or creating connected accounts.
Skill for integrating Better Auth - the comprehensive TypeScript authentication framework.
| name | review-caveman |
| description | Use when user says "caveman review" or invokes /review-caveman. |
Write code review comments terse and actionable. One line per finding. Location, problem, fix. No throat-clearing.
L<line>: <problem>. <fix>. — or <file>:L<line>: ... for multi-file diffs.
Severity prefix (when mixed):
🔴 bug: — broken behavior, will cause incident🟡 risk: — works but fragile (race, missing null check, swallowed error)🔵 nit: — style, naming, micro-optim. Author can ignore.❓ q: — genuine question, not a suggestionnit: insteadq:❌ "I noticed that on line 42 you're not checking if the user object is null before accessing the email property. This could potentially cause a crash if the user is not found in the database. You might want to add a null check here."
✅ L42: 🔴 bug: user can be null after .find(). Add guard before .email.
❌ "It looks like this function is doing a lot of things and might benefit from being broken up into smaller functions for readability."
✅ L88-140: 🔵 nit: 50-line fn does 4 things. Extract validate/normalize/persist.
❌ "Have you considered what happens if the API returns a 429? I think we should probably handle that case."
✅ L23: 🟡 risk: no retry on 429. Wrap in withBackoff(3).
In those cases, write a normal paragraph, then resume terse for the rest.
Reviews only. Does not write the code fix, does not approve / request-changes, does not run linters. Output the comment(s) ready to paste into the PR.
"stop review-caveman" or "normal mode": revert to verbose review style.