| name | figma-implement-ui |
| description | Implement or refine frontend UI from a Figma node in the chukchuk-haksa repository. Use when a request includes a Figma URL, screenshot comparison, typography or color-token matching, responsive card/layout behavior, interaction variants, or pixel-level visual corrections. Do not use when the task is only to edit the Figma file rather than implement code. |
Figma UI 구현
Translate the design into maintainable responsive code. Treat the Figma node as evidence, not as a screenshot to approximate from memory.
1. Collect evidence before coding
- Read
AGENTS.md and inspect the target component and surrounding layout.
- Extract the exact Figma
fileKey and nodeId.
- Retrieve design context, screenshot, variables, and component metadata when available.
- Inspect every relevant variant, not only the default state:
- selected and unselected;
- focus and input-active;
- grade/status/theme variants;
- long text and nullable data;
- compact and wider viewport behavior.
- If Figma access is rate-limited, state which values are verified and which remain provisional. Never present guessed values as confirmed tokens.
2. Build a design evidence table
Before implementation, map each important property to its source:
| Property | Required evidence |
|---|
| Typography | Figma style name, family, weight, size, line height |
| Color | variable/style or Selection color |
| Spacing | measured gap/padding and parent alignment |
| Sizing | fixed, min/max, fill, hug, or ratio behavior |
| Radius/border | token or measured value |
| Interaction | selected, focus, disabled, loading |
Prefer repository tokens and mixins. If the design uses a missing reusable token, add it centrally with a clear name. Keep unverified variant mappings in one map so they can be replaced without editing components.
3. Implement responsive intent
- Reproduce the fixed dimensions that carry visual intent.
- Use
width: 100%, grid fractions, min-height, and max-width constraints where the design should expand.
- Do not scale the whole card proportionally unless typography and controls are meant to scale too.
- Keep section edges aligned to the same content column.
- Let internal tag/input widths grow while preserving measured gaps.
- Check long course names, wrapped tags,
score=null, and narrow devices.
- Account for safe areas and mobile keyboards when controls are fixed or sticky.
4. Match typography and interaction
- Load the actual font weights rather than relying on browser synthesis.
- Apply the named Figma typography style through repository mixins.
- Center tag labels both horizontally and vertically.
- Map selected text, border, gradient, and focus colors by domain variant.
- Add keyboard-visible focus states; do not remove outlines without an accessible replacement.
- Preserve semantic fieldsets, legends, labels, button states, and live regions.
5. Compare repeatedly
Use this loop:
- implement one visual section;
- run the local page at the target viewport;
- capture or inspect a screenshot;
- compare outer geometry, section alignment, typography, colors, then micro-spacing;
- adjust tokens/layout;
- repeat at one narrow and one wide mobile viewport.
Do not wait until the entire screen is finished before comparing.
6. Verify code quality
Check that:
- styles live in colocated SCSS modules;
- no duplicate magic values replace existing tokens;
- dynamic values use data attributes or CSS variables cleanly;
- input interactions do not rerender the entire screen unnecessarily;
- preview/debug routes cannot ship as accessible production pages.
Run targeted tests, type-check, lint, and build when fonts or route boundaries changed. Summarize verified Figma values separately from provisional mappings.
