Use when reviewing a web app for practical security risk before coding or shipping. Covers trust boundaries, attacker-controlled input, privileged actions, secret exposure, and routing the problem to narrower security skills without pretending to do a full security audit.
Use when untrusted input may reach SQL, HTML, filesystem, shell, redirects, or other dangerous sinks. Covers validation, normalization, parameterization, output encoding, and refusing vague “sanitize everything” advice.
Use when initializing shadcn, managing components.json, adding components or blocks through the CLI, or deciding how registries and updates should work without losing local ownership. Covers CLI defaults, registry boundaries, aliases, CSS entrypoints, and safe update posture.
Use when composing shadcn components into real product surfaces instead of treating them like isolated snippets. Covers asChild, trigger ownership, dialog and dropdown composition, local wrappers, and the rule that the value is in stable composition patterns, not in blindly stacking primitives.
Use when building forms with shadcn in a way that stays opinionated instead of devolving into copied snippets. Covers field primitives, choosing one form-state strategy, integrating validation, and keeping complex stateful form logic out of the visual component layer.
Choose whether shadcn/ui is the right fit and adopt it with the right ownership model. Use when tasks mention shadcn setup, copying components into the app, owning UI source code, deciding between shadcn and a packaged component library, or routing work to theming, registry, composition, or forms follow-up skills.
Use when defining shadcn theme defaults that the model should not improvise per component. Covers CSS variables, semantic tokens, OKLCH-based palettes, dark mode, and the rule that visual consistency should come from tokens and composition instead of one-off utility overrides.
Use when creating or refining an AI skill. Covers trigger wording, scope boundaries, progressive disclosure, references versus scripts, and keeping SKILL.md concise and installable.
Use when modeling products and prices or implementing Stripe Checkout with sane defaults. Covers products, prices, lookup keys, Checkout Sessions, hosted checkout as the default path, and the boundary between checkout UX and webhook-based fulfillment.
Use when implementing Stripe's customer portal as the default self-serve billing surface. Covers portal configuration, product-catalog boundaries for upgrades and downgrades, portal session creation, deep links, and webhook-driven sync after customers manage their own billing.