From hatch3r
Scans a project's package.json and token sources to inventory design tokens, component libraries, and theming conventions before authoring UI primitives.
How this skill is triggered — by the user, by Claude, or both
Slash command
/hatch3r:hatch3r-design-system-detectThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
When an agent is about to author or modify UI, run this skill first to produce a Design System Inventory. Skip = the implementer may duplicate primitives or invent tokens that already exist. Embed the inventory in the implementation plan, PR description, or `.audit-workspace/design-system-inventory.md` for the current task before any UI code is written.
When an agent is about to author or modify UI, run this skill first to produce a Design System Inventory. Skip = the implementer may duplicate primitives or invent tokens that already exist. Embed the inventory in the implementation plan, PR description, or .audit-workspace/design-system-inventory.md for the current task before any UI code is written.
Task Progress:
- [ ] Step 0: Detect ambiguity (P8 B1)
- [ ] Step 1: Scan package.json for design-system signals
- [ ] Step 2: Locate token source
- [ ] Step 3: Map component library
- [ ] Step 4: Identify breakpoint and responsive strategy
- [ ] Step 5: Record findings (Design System Inventory)
Before any work, scan the invocation for unresolved questions in scope, intent, acceptance criteria, target environment, or irreversibility. If any are found, ask the user via the platform-native question tool per agents/shared/user-question-protocol.md. Do not proceed under silent assumption. Default path, not an exception. Triggers for THIS skill: project root path (monorepo subpackage vs root), canonical token source when multiple exist, primitive directory convention, responsive strategy expected (container-first vs media-first), and verdict authority (reuse vs extend vs create).
Fan-out scales with task size; token cost never justifies serializing independent work (rules/hatch3r-fan-out-discipline.md P8 B2; agents/shared/efficiency-patterns.md). Emit sub_agents_spawned: { count, rationale } in your output.
Look for the following packages and record both presence and version:
@radix-ui/* or radix-ui (headless primitives, WAI-ARIA compliant)shadcn reference in components.json (source-in-repo registry)tailwindcss — note major version (v3 has tailwind.config.js; v4 uses @theme in CSS)@chakra-ui/*, @mui/material, @mui/joybootstrap, @headlessui/react, @base-ui-components/reactDetection command:
cat package.json | jq '.dependencies, .devDependencies | keys[]' | grep -iE 'radix|tailwind|chakra|mui|shadcn|headless|base-ui'
Output: a list of design-system packages with semver. If zero matches, record "no UI library detected — confirm with maintainer before scaffolding a new one."
Detection order (first match wins):
tokens.json at repo root or in src/, design/, tokens/ — check for $value/$type keys; DTCG 2025.10 conformance.@theme block in any *.css file (Tailwind v4) — rg -l '@theme\s*\{' --type css.src/styles/tokens.css or similar — CSS custom properties at :root.tailwind.config.{js,ts} theme.extend (Tailwind v3 fallback).figma.tokens.json, tokens-studio.json).For each source found, record:
@theme / CSS custom properties / Tailwind v3 config)If multiple sources exist, flag the duplication — DTCG mandates a single source of truth. The Design System Inventory must call out which source the implementer should treat as canonical.
Check components.json (shadcn registry config). Record: style, tailwind.config, aliases.components, aliases.ui.
Find component directories:
src/components/ui/* (shadcn convention)src/components/primitives/*app/components/* (Nuxt / Next.js app router)packages/ui/* (monorepo)Detection command:
fd -t d -E node_modules 'ui|primitives|components' src app packages 2>/dev/null | head -10
List the existing primitives by filename (Button, Input, Dialog, Card, Tooltip, ...). The implementer uses this list in Step 5 to decide reuse vs extend vs create.
Container queries (preferred for component-scoped responsiveness in 2026):
rg -l '@container' --type css
Media queries (viewport-scoped):
rg -o '@media\s*\([^)]+\)' --type css | sort -u | head -10
Breakpoint tokens: check --breakpoint-* custom properties or Tailwind screens config.
Record one of: container-query-first / media-query-first / mixed. A component-library project that ships @container-based primitives must not be extended with @media-only additions.
Produce a Design System Inventory block. Embed it in the implementation plan, PR description, or .audit-workspace/design-system-inventory.md:
Design System Inventory
-----------------------
Component library: <shadcn|Radix|MUI|Chakra|custom|none> (version X)
Token source: <file path> (<DTCG|@theme|CSS vars|Tailwind config>)
Color space: <OKLCH|Display-P3|hex>
Responsive strategy: <container-first|media-first|mixed>
Existing primitives: Button, Input, Dialog, ...
Verdict: <reuse|extend|create-with-justification>
| Situation | Action |
|---|---|
| Primitive exists, matches use case | Import + use directly |
| Primitive exists, doesn't quite fit | Extend via composition; do not fork |
| No primitive | Author new, add to ui/ directory, document in PR |
components.json present but src/components/ui/ empty: Project is shadcn-initialized but no primitives copied yet. Run npx shadcn@latest add <component> --dry-run to preview before authoring..audit-workspace/add, init, --dry-run, --diff, --view@theme block configuration:has(), anchor positioning, View Transitions baseline statusRules consumed by this skill:
rules/hatch3r-design-system-detection.md — rule version of this guidance (mandate + scope)rules/hatch3r-component-conventions.md — primitive composition + state patternsrules/hatch3r-theming.md — token layering (primitive → semantic → component)npx claudepluginhub hatch3r/hatch3r --plugin hatch3rUse when operating in a codebase that employs an existing design system (shadcn/ui, Material UI, Ant Design, Chakra, etc.), when you need to identify which system a project uses, or when setting up a design system for a project that lacks one
Detects design system tokens and components in code, identifying drift with paired evidence blocks. Use when auditing design system consistency across a codebase.
Manages design systems by detecting reusable UI patterns, extracting design tokens, organizing components with Atomic Design, and warning on hard-coded values or duplicates. Activates on component libraries, style guides, or patterns.