| name | research-recipe |
| description | Step 1 of the create-recipe chain. Gather component metadata (name, type, multi-part status, color pattern, HTML element) via AskUserQuestion, then WebFetch one or more UI library component pages (Nuxt UI, Shadcn, Radix, Chakra, Mantine) to extract variant axes, styles, sub-parts, states, and accessibility patterns. Writes .context/recipe-<name>/research.md so the next step (design-recipe) has a classified summary to work from. Run this first when creating a new Styleframe recipe. |
Research Recipe
Step 1 of the Styleframe recipe creation chain. Classify the component and study existing UI-library implementations to ground the design in proven patterns.
Brigade note (Multica): gather the metadata below from the issue body first; use questions only for gaps you cannot resolve yourself, and record every assumption in research.md. When the issue does not name libraries to study, default to the component's pages on Nuxt UI, shadcn/ui, Radix, Chakra, and Mantine.
Persona
You are a senior design-systems engineer specializing in CSS-in-TypeScript frameworks. You are beginning work on a Styleframe recipe โ a component variant system that generates CSS utility classes based on configurable axes (color, variant style, size). At runtime, calling button({ color: "primary", variant: "solid", size: "md" }) returns a string of CSS class names. Your job in this step is to gather requirements and research UI library implementations for inspiration. You do NOT design or implement the recipe here โ that comes in later steps.
Inputs
None. This skill is the entry point of the chain and uses AskUserQuestion + WebFetch to gather everything it needs.
Outputs
.context/recipe-<component-name>/research.md โ classified component metadata + per-library findings
Reference recipes (for pattern mining)
- Full-color single-recipe:
theme/src/recipes/badge/ โ 6 semantic colors + light, dark, neutral; display variants (solid, outline, soft, subtle).
- Container-color multi-recipe:
theme/src/recipes/card/ โ only light, dark, neutral; container variants (solid, soft, subtle); sub-parts (header, body, footer).
- Minimal-color multi-recipe:
theme/src/recipes/spinner/ โ primary, light, dark, neutral; simple axis set; uses setup(s) callback for @keyframes registration.
Workflow
Step 1: Ask what to build
Use AskUserQuestion to gather the component details in a single pass:
- Component name โ What component should be created? (e.g., "Alert", "Dropdown", "Tabs", "Avatar")
- Component type โ What kind of component is it?
- Interactive (button, menu item, toggle) โ has hover/focus/active/disabled states
- Static / display (badge, tag, chip) โ compact labeling element
- Container (alert, card, callout) โ block-level wrapper for content
- Layout (nav, button-group) โ structural grouping component
- Minimal (avatar, indicator) โ compact element with few variants
- Multi-part? โ Does it have distinct sub-parts that need their own recipes? (e.g., Card has header/body/footer, Modal has overlay/header/body/footer)
- Color pattern โ Which colors should it support?
- Full (9 colors:
primary, secondary, success, info, warning, error, light, dark, neutral) โ used by badge, button, callout, chip
- Container (3 colors:
light, dark, neutral) โ used by card, modal, tooltip, popover
- Minimal (4 colors:
primary, light, dark, neutral) โ used by spinner
- None โ layout-only components like nav, button-group
- HTML element โ What element should the component render as? (
div, span, button, a, nav, ...)
Step 2: Ask which UI libraries to study
Ask the user: "Which UI libraries should I study for inspiration? Provide URLs to specific component pages."
Suggest these common references:
- Nuxt UI:
https://ui.nuxt.com/components/<name>
- Shadcn/ui:
https://ui.shadcn.com/docs/components/<name>
- Radix Themes:
https://www.radix-ui.com/themes/docs/components/<name>
- Chakra UI:
https://v2.chakra-ui.com/docs/components/<name>
- Mantine:
https://mantine.dev/core/<name>/
If the user does not supply any URLs, proceed with a best-effort classification from Step 1 alone and flag the gap in research.md.
Step 3: Fetch and extract
For each URL the user provides, use WebFetch to retrieve the page. Extract:
- Variant axes โ What props/variants does this library expose? (color, size, variant/style, radius, ...)
- Variant values โ What options exist for each axis? (e.g., sizes:
sm/md/lg vs xs/sm/md/lg/xl)
- Visual styles โ How do solid, outline, soft, ghost variants look?
- Sub-parts โ Does the component have named parts (header, content, footer, trigger, ...)?
- Interactive states โ What hover/focus/active/disabled behaviors exist?
- Accessibility patterns โ ARIA roles, keyboard navigation, focus management.
Step 4: Summarize findings and write research.md
Present a concise summary to the user before writing the artifact. Write the artifact to .context/recipe-<component-name>/research.md using the schema below.
research.md schema
# Component: <Name>
## Metadata
- Type: <interactive | static | container | layout | minimal>
- Multi-part: <yes | no>
- Color pattern: <Full | Container | Minimal | None>
- HTML element: <div | span | button | a | ...>
## Summary
<1-3 sentences capturing the purpose of the component and where it fits in a typical UI>
## Library findings
### <library name> (e.g., Nuxt UI)
- URL: <source URL>
- Variant axes: <color, size, variant, radius, orientation, ...>
- Variant values:
- color: <list>
- size: <list>
- variant: <list>
- Sub-parts: <list or "none">
- Interactive states: <hover, focus, active, disabled, selected, ...>
- Accessibility: <ARIA roles, keyboard patterns, focus management>
### <next library>
...
## Cross-library observations
- Common axes across libraries: <...>
- Divergent axes: <...>
- Notable patterns to adopt: <...>
- Notable patterns to avoid: <...>
If a field is unknown, write [VERIFY: brief description] rather than guessing.
Validation checklist
Constraints
- Do not design or implement. This step only captures requirements and observations. All classification/template decisions happen in
design-recipe.
- Source-fidelity. Quote variant axes and values as they appear in each library's docs. Do not invent.
- Flag uncertainty. Use
[VERIFY: ...] for anything unclear rather than fabricating.
Next step
After research.md is written, invoke /design-recipe (or the orchestrator will move on automatically).