Site DNA Component Builder
Use this skill to build components that feel native to an existing site instead of generic. The goal is to inspect the site DNA first, then implement a component that matches the product's visual language, interaction rules, accessibility standards, and code patterns.
Core Rule
Do not start from a blank aesthetic. Extract the DNA from the current project or target reference, then build inside that system.
Site DNA means:
- Layout rhythm: grids, max widths, section spacing, density, alignment.
- Typography: font family, scale, weight, line height, heading/body relationship.
- Color system: semantic tokens, backgrounds, borders, accents, dark/light behavior.
- Component language: buttons, cards, nav, forms, badges, tabs, tables, modals.
- Motion behavior: duration, easing, hover/focus rules, transform/opacity only.
- Content voice: concise vs editorial, technical vs friendly, premium vs utilitarian.
- UX conventions: navigation, CTA hierarchy, empty states, loading/error states.
- Accessibility: semantic HTML, labels, keyboard support, focus visibility, contrast.
- Code style: file organization, component APIs, TypeScript patterns, design tokens.
Triggered Inputs
Treat $ARGUMENTS or the user request as one of these:
| Input |
How To Use It |
| Existing component/file |
Read nearby components, props, styles, tokens, tests, and usage sites. |
| URL or rendered route |
Inspect page visually, screenshot if possible, then map reusable patterns. |
| Screenshot/image |
Identify layout, typography, spacing, visual hierarchy, and responsive implications. |
| Brief only |
Infer target component, then inspect current workspace for the design system before building. |
| "Make this match the site" |
Compare new work against current site DNA and remove mismatched styling. |
Workflow
- Identify target component, job-to-be-done, and user action.
- Inspect current codebase before editing:
package.json- app routes/pages
- design tokens/theme files
- existing components
- global CSS/Tailwind config
- relevant tests/stories
- If a URL or local route is provided, render it when possible and inspect desktop/mobile behavior.
- Write a short DNA map before implementation:
- layout
- typography
- colors
- component rules
- motion
- accessibility conventions
- code conventions
- Implement small and native:
- reuse existing primitives and tokens
- keep props typed
- avoid one-off hardcoded styles unless project already does that
- preserve dark/light mode behavior
- add states users expect: hover, focus, active, loading, empty, error when relevant
- Verify with available checks:
- typecheck
- lint
- build
- unit/component tests
- browser smoke test for visible UI
- Report changed files, verification, and any assumptions.
Frontend Standards
Follow current project conventions first. If missing, use these defaults:
- TypeScript strict style:
interface for object shapes, type for unions, explicit exported types.
- No
any; use unknown at boundaries and validate when needed.
- Use semantic HTML before ARIA.
- Buttons and inputs need visible focus states and accessible labels.
- Avoid
transition-all; animate transform and opacity only.
- Keep transitions at or below 200ms unless existing system says otherwise.
- Use existing icon library, usually Lucide, for icon buttons.
- Do not introduce purple gradients, blur-heavy decoration, heavy shadows, or one-note palettes.
- Keep cards at 8px radius or less unless current system differs.
- No nested UI cards.
- Text must fit at mobile and desktop widths.
- Website/app first screen should be usable product surface, not generic marketing filler, unless user asks for a landing page.
Component Build Checklist
Before final answer, confirm:
| Area |
Check |
| Native fit |
Component matches existing spacing, radius, borders, typography, icons, and CTA hierarchy. |
| Responsive |
Mobile, tablet, and desktop layouts preserve hierarchy and avoid overflow. |
| Accessibility |
Semantic structure, labels, focus states, contrast, keyboard path, alt text where needed. |
| States |
Loading, empty, error, disabled, hover, focus, active, selected, and success states exist when relevant. |
| Code |
Component is local, typed, reusable enough, and follows existing imports/path aliases. |
| Performance |
No layout-thrashing animation, huge asset, unnecessary client JS, or avoidable re-render. |
| Content |
Copy matches brand voice and does not use vague filler. |
Output Format
When building or editing code, final response should include:
- What changed.
- Files changed.
- Verification run and result.
- Assumptions or remaining gaps.
When auditing/planning only, use:
**Site DNA**
| Layer | Finding | Implementation Rule |
|---|---|---|
**Component Plan**
| Component | Job | Structure | States | Notes |
|---|---|---|---|---|
**Build Steps**
1. ...
Examples
Example 1
Input: /site build a pricing comparison card for this app
Action: Inspect existing pricing/cards/buttons/tokens, then build a pricing comparison component using same grid, borders, typography, CTA style, and responsive rules.
Example 2
Input: /sdcb make this hero match the homepage
Action: Compare target hero against homepage DNA, remove mismatched spacing/color/type/motion, then adjust code and verify rendered result.
Example 3
Input: /site-dna-component-builder clone the testimonial style from this URL
Action: Inspect the URL visually, extract testimonial pattern, rebuild as original code using current project stack and accessible markup. Do not copy protected code.
Guardrails
- Do not copy proprietary source code from external sites.
- Do not invent screenshots or claim visual verification without rendering.
- Do not replace the app's design system with a new one unless explicitly requested.
- Do not ship a component that only looks good at one viewport.
- Do not add new UI libraries unless the project already uses them or the user approves.
1---2name: site-dna-component-builder3description: Build or refine production frontend components from existing site DNA. Use when the user invokes /site, /sdcb, /site-dna-component-builder, says "site DNA", asks to clone a component style, create a section that matches an existing website/app, extract design patterns from a URL/screenshot/codebase, or build UI that must preserve brand, layout rhythm, tokens, accessibility, responsiveness, and component conventions.4---56# Site DNA Component Builder78Use this skill to build components that feel native to an existing site instead of generic. The goal is to inspect the site DNA first, then implement a component that matches the product's visual language, interaction rules, accessibility standards, and code patterns.910## Core Rule1112Do not start from a blank aesthetic. Extract the DNA from the current project or target reference, then build inside that system.1314Site DNA means:1516- Layout rhythm: grids, max widths, section spacing, density, alignment.17- Typography: font family, scale, weight, line height, heading/body relationship.18- Color system: semantic tokens, backgrounds, borders, accents, dark/light behavior.19- Component language: buttons, cards, nav, forms, badges, tabs, tables, modals.20- Motion behavior: duration, easing, hover/focus rules, transform/opacity only.21- Content voice: concise vs editorial, technical vs friendly, premium vs utilitarian.22- UX conventions: navigation, CTA hierarchy, empty states, loading/error states.23- Accessibility: semantic HTML, labels, keyboard support, focus visibility, contrast.24- Code style: file organization, component APIs, TypeScript patterns, design tokens.2526## Triggered Inputs2728Treat `$ARGUMENTS` or the user request as one of these:2930| Input | How To Use It |31|---|---|32| Existing component/file | Read nearby components, props, styles, tokens, tests, and usage sites. |33| URL or rendered route | Inspect page visually, screenshot if possible, then map reusable patterns. |34| Screenshot/image | Identify layout, typography, spacing, visual hierarchy, and responsive implications. |35| Brief only | Infer target component, then inspect current workspace for the design system before building. |36| "Make this match the site" | Compare new work against current site DNA and remove mismatched styling. |3738## Workflow39401. Identify target component, job-to-be-done, and user action.412. Inspect current codebase before editing:42 - `package.json`43 - app routes/pages44 - design tokens/theme files45 - existing components46 - global CSS/Tailwind config47 - relevant tests/stories483. If a URL or local route is provided, render it when possible and inspect desktop/mobile behavior.494. Write a short DNA map before implementation:50 - layout51 - typography52 - colors53 - component rules54 - motion55 - accessibility conventions56 - code conventions575. Implement small and native:58 - reuse existing primitives and tokens59 - keep props typed60 - avoid one-off hardcoded styles unless project already does that61 - preserve dark/light mode behavior62 - add states users expect: hover, focus, active, loading, empty, error when relevant636. Verify with available checks:64 - typecheck65 - lint66 - build67 - unit/component tests68 - browser smoke test for visible UI697. Report changed files, verification, and any assumptions.7071## Frontend Standards7273Follow current project conventions first. If missing, use these defaults:7475- TypeScript strict style: `interface` for object shapes, `type` for unions, explicit exported types.76- No `any`; use `unknown` at boundaries and validate when needed.77- Use semantic HTML before ARIA.78- Buttons and inputs need visible focus states and accessible labels.79- Avoid `transition-all`; animate `transform` and `opacity` only.80- Keep transitions at or below 200ms unless existing system says otherwise.81- Use existing icon library, usually Lucide, for icon buttons.82- Do not introduce purple gradients, blur-heavy decoration, heavy shadows, or one-note palettes.83- Keep cards at 8px radius or less unless current system differs.84- No nested UI cards.85- Text must fit at mobile and desktop widths.86- Website/app first screen should be usable product surface, not generic marketing filler, unless user asks for a landing page.8788## Component Build Checklist8990Before final answer, confirm:9192| Area | Check |93|---|---|94| Native fit | Component matches existing spacing, radius, borders, typography, icons, and CTA hierarchy. |95| Responsive | Mobile, tablet, and desktop layouts preserve hierarchy and avoid overflow. |96| Accessibility | Semantic structure, labels, focus states, contrast, keyboard path, alt text where needed. |97| States | Loading, empty, error, disabled, hover, focus, active, selected, and success states exist when relevant. |98| Code | Component is local, typed, reusable enough, and follows existing imports/path aliases. |99| Performance | No layout-thrashing animation, huge asset, unnecessary client JS, or avoidable re-render. |100| Content | Copy matches brand voice and does not use vague filler. |101102## Output Format103104When building or editing code, final response should include:1051061. What changed.1072. Files changed.1083. Verification run and result.1094. Assumptions or remaining gaps.110111When auditing/planning only, use:112113```markdown114**Site DNA**115| Layer | Finding | Implementation Rule |116|---|---|---|117118**Component Plan**119| Component | Job | Structure | States | Notes |120|---|---|---|---|---|121122**Build Steps**1231. ...124```125126## Examples127128**Example 1**129Input: `/site build a pricing comparison card for this app`130Action: Inspect existing pricing/cards/buttons/tokens, then build a pricing comparison component using same grid, borders, typography, CTA style, and responsive rules.131132**Example 2**133Input: `/sdcb make this hero match the homepage`134Action: Compare target hero against homepage DNA, remove mismatched spacing/color/type/motion, then adjust code and verify rendered result.135136**Example 3**137Input: `/site-dna-component-builder clone the testimonial style from this URL`138Action: Inspect the URL visually, extract testimonial pattern, rebuild as original code using current project stack and accessible markup. Do not copy protected code.139140## Guardrails141142- Do not copy proprietary source code from external sites.143- Do not invent screenshots or claim visual verification without rendering.144- Do not replace the app's design system with a new one unless explicitly requested.145- Do not ship a component that only looks good at one viewport.146- Do not add new UI libraries unless the project already uses them or the user approves.
MaybackCompany