القائمة
Don't write dark: Tailwind variants for colour in Shade or admin apps — semantic tokens flip in dark mode automatically. Trigger when editing TSX in Shade-consuming apps.
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Decide which Shade layer (Token, Primitive, Component, Recipe, Pattern) a new piece of UI belongs in — and whether it should be added to Shade at all. Trigger when creating new files in apps/shade/src/components, or proposing to add a new Shade component.
DropdownMenu, Select, and Popover share one visual recipe (bg-surface-elevated-2 + border-border/60 dark:border-border/30 + shadow-md). Change them together. Trigger when editing any of those three Shade files.
Import Shade from layer-specific subpaths (primitives, components, patterns, page-templates, utils), never the root barrel. Trigger when editing TSX/TS in Shade-consuming apps.
Use the inputSurface() recipe for form-control chrome (border, background, radius, focus ring, invalid state) — don't roll your own. Trigger when editing form-control-shaped files in Shade.
Acceptance checklist for adding or editing a Shade component or pattern file — naming, sibling story, className forwarding, cva variants, required states, recipe usage. Trigger when editing files in apps/shade/src/components.
Pick the right Shade page template (ListPage, PageHeader) for a new admin page instead of inventing chrome. Trigger when creating new admin pages or routes in apps/admin, apps/admin-x-settings, apps/posts, apps/stats, apps/activitypub.
| name | Shade no dark variants |
| description | Don't write dark: Tailwind variants for colour in Shade or admin apps — semantic tokens flip in dark mode automatically. Trigger when editing TSX in Shade-consuming apps. |
dark: for colourShade's semantic tokens (bg-background, text-foreground, border-border-default, bg-surface-elevated, …) already flip between light and dark mode. Writing dark:bg-... / dark:text-... / dark:border-... means the engineer reached for a raw, non-semantic token — fix the token, don't patch with a dark: variant.
<div className="bg-surface-elevated border border-border-default text-foreground">
<p className="text-muted-foreground">Hint text</p>
</div>
// BAD — using dark: to patch a raw palette utility
<div className="bg-white dark:bg-gray-900 text-gray-900 dark:text-gray-100">
// BAD — redundant: the semantic token already flips itself, so the dark: variant adds a duplicate rule that does nothing. Reading it suggests dark mode is special-cased here when it isn't.
<div className="bg-surface-elevated dark:bg-surface-elevated">
dark: smellshade-tokens-not-hex skill for the inventory).dark: halves; the token handles both modes.Assets that are genuinely different in dark mode and can't be expressed as a token:
For these, dark: is fine because there's nothing semantic to express.
Some existing Shade components also use dark: for ring opacity (e.g. dark:ring-destructive/40 inside inputSurface). When a token doesn't exist for the variant you need and the value is an opacity modifier on an existing token, a narrow dark: is acceptable — but first check whether a new token belongs in theme-variables.css.
If something looks wrong only in dark mode, the fix is almost always wrong token, not missing dark: variant. Re-pick from the semantic surface table; check apps/shade/theme-variables.css for what each token resolves to.