From ffab936c8bcc2c14d97a47681ff67f9bca92de62 Mon Sep 17 00:00:00 2001 From: Harry Hao Date: Fri, 27 Mar 2026 18:14:49 -0500 Subject: [PATCH 1/3] feat: added cds-code and cds-design-to-code skill for distribution --- skills/cds-code/SKILL.md | 269 +++++++++++++++++++++++++++++ skills/cds-design-to-code/SKILL.md | 257 +++++++++++++++++++++++++++ 2 files changed, 526 insertions(+) create mode 100644 skills/cds-code/SKILL.md create mode 100644 skills/cds-design-to-code/SKILL.md diff --git a/skills/cds-code/SKILL.md b/skills/cds-code/SKILL.md new file mode 100644 index 000000000..9ddc05d68 --- /dev/null +++ b/skills/cds-code/SKILL.md @@ -0,0 +1,269 @@ +--- +name: cds-code +description: | + Produces high quality Coinbase Design System (CDS) UI code for React and React Native. + Use this skill whenever the task involves UI, CDS components, layouts, theming, styling, + charts, or data visualization. +license: Apache-2.0 +metadata: + author: ruikun.hao@coinbase.com + version: "1.0.0" +--- + +# CDS Code + +Use this skill to produce CDS-first UI code that is accurate, composable, and aligned with the official docs. + +## When to use + +- Use when building or editing React or React Native UI with CDS components. +- Use when the task involves layouts, theming, styling, or design tokens. +- Use when working with charts, sparklines, or data visualization components. +- Use when refactoring UI to adopt CDS components. +- Do not use when the task has no UI or frontend component work. + +## Prerequisites + +- **CDS MCP server** must be connected for doc lookups via `list-cds-routes` and `get-cds-doc`. + +--- + +## Part 1: Workflow -- what to do + +This section describes the steps you follow, in order, when working on a UI task. + +### Setup (once per session) + +When this skill first loads, run these steps once so all later work is grounded in the docs: + +1. Detect the target platform from the codebase: `web` or `mobile`. +2. Call the CDS MCP tool `list-cds-routes` for that platform to get the full route listing. +3. Read the platform-specific foundation docs with `get-cds-doc`: + - `web/getting-started/styling.txt` (or `mobile/getting-started/styling.txt`) + - `web/getting-started/theming.txt` (or `mobile/getting-started/theming.txt`) + +You do not need to repeat these steps for every task -- once per session is enough. + +### Step 1: Choose the right component + +Follow this order: + +1. Look for a CDS component that fits the need. Check the route listing and component guidance in Part 3. +2. If no CDS component fits, use a native platform element only when it is clearly the simplest correct choice. +3. Build custom UI only as a last resort. + +### Step 2: Read the docs for that component + +1. Find the component in the route listing you fetched during setup. +2. Read its doc with `get-cds-doc`. +3. Use the documented imports, props, examples, and composition patterns instead of guessing. + +### Step 3: Write the code + +Apply the code style rules from Part 2 below. + +### Step 4: Verify visually + +When rendering and inspection tooling are available, do one visual verification pass before finishing: + +1. Open the running app in a browser or simulator. +2. Navigate to the screen where your code changes are visible. The app landing page may not show your work -- infer the correct tab, dropdown selection, or route from the code you just edited and click through to reach it. If you cannot find the right screen after a reasonable attempt, ask the user to navigate to it in the browser for you and then continue verification from there. +3. Take a screenshot or visually inspect the rendered output. +4. Compare against the design intent -- check spacing, alignment, typography, color, and overflow. +5. If something looks off, fix the code and verify again. + +Do not claim the UI looks correct based only on reading code or DOM structure. If the dev server is not running or inspection tooling is unavailable, note this to the user instead of skipping verification silently. + +> **Cursor example:** Use the built-in browser tools -- `browser_navigate` to open `http://localhost:8080` (or whatever port the local app runs on), then `browser_snapshot` to see the page structure and click through tabs or dropdowns to reach the right screen, then `browser_screenshot` to capture the rendered output for comparison. + +### Step 5: Final checklist + +Before returning code, confirm: + +1. A CDS component was chosen whenever one exists. +2. Layout uses CDS primitives where practical. +3. Styling prefers StyleProps, tokens, and CSS variables over hardcoded values. +4. No `style` override duplicates a value that could be set via a component prop (e.g. `font`, `color`, `textAlign`, `textTransform`, `padding`, `gap`). +5. Imports and prop usage match the docs you just read. +6. Imports come from `@coinbase/cds-web` for web or `@coinbase/cds-mobile` for mobile, using the documented component path instead of guessing. +7. Charts use `@coinbase/cds-web-visualization` or `@coinbase/cds-mobile-visualization` when CDS provides the needed visualization primitive. +8. The UI has gone through at least one visual verification pass when rendering and inspection tooling are available. + +--- + +## Part 2: Code style -- how to write it + +This section defines the coding preferences and patterns to follow when writing CDS code. + +### Layout + +Prefer CDS layout primitives over raw platform elements such as `div` and `span` on web or `View` and `Text` on mobile when they express the intent clearly: + +- Use `Box` as the default container. +- Use `HStack` for horizontal layout and spacing. +- Use `VStack` for vertical layout and spacing. +- Use `Grid` when you need equal columns, repeated tracks, or true grid behavior. +- Use `Spacer` and `Divider` when they match the layout intent better than custom filler elements. + +`Box`, `HStack`, and `VStack` should usually be your first choice for page and component structure. They encode CDS spacing, responsive props, and composition more reliably than ad hoc markup. + +On web, remember that `Box` is not semantic by default. Use `as` and `role` when the container should behave like `main`, `section`, `aside`, `button`, or another semantic element. + +### Styling + +Prefer CDS StyleProps before custom styles: + +- Reach for props like `gap`, `padding`, `margin`, `background`, `borderColor`, `borderRadius`, `alignItems`, and `justifyContent` first. +- Prefer responsive StyleProps over custom media queries when the component supports them. +- Prefer component variants and documented props before overriding styles manually. + +Use semantic theme values: + +- Prefer semantic color tokens such as `bg`, `bgAlternate`, `bgPrimary`, `fg`, `fgMuted`, and `fgPositive`. +- Prefer semantic `color` values over raw `spectrum` values. Raw spectrum colors should be a rare exception. +- Prefer CSS variables over hardcoded values when styling directly on web. + +Examples: + +- On web, prefer `marginTop: 'var(--space-0_5)'` over `marginTop: '4px'`. +- On web, prefer `borderRadius: 'var(--borderRadius-200)'` over `borderRadius: '8px'`. +- On mobile, prefer `marginTop: theme.space[0.5]` over `marginTop: 4`. +- On mobile, prefer `borderRadius: theme.borderRadius[200]` over `borderRadius: 8`. +- Prefer `` over a custom wrapper with hardcoded CSS. + +### Avoiding unnecessary `style` overrides + +Before adding any property to a `style` prop, check whether the component already exposes a dedicated prop or StyleProp for that value. Raw `style` overrides bypass the design system's built-in tokens, responsive behavior, and font stacks, which leads to subtle visual bugs. + +**Read the component's prop table first.** Only reach for `style` when you have confirmed that no existing prop covers the value you need. + +Common props that are frequently misused via `style` instead of the proper prop: + +| Instead of `style` | Use the prop | +|---|---| +| `style={{ color: "var(--color-fgMuted)" }}` | `color="fgMuted"` | +| `style={{ fontSize: 12, fontWeight: 500, lineHeight: "16px" }}` | `font="caption"` (or the matching CDS font token) | +| `style={{ textAlign: "center" }}` | `textAlign="center"` | +| `style={{ textTransform: "uppercase" }}` | `textTransform="uppercase"` | +| `style={{ display: "flex", flexDirection: "column" }}` | Use `VStack`, or `flexDirection="column"` on `Box` | +| `style={{ gap: 8 }}` | `gap={1}` | +| `style={{ padding: 16 }}` | `padding={2}` | +| `style={{ backgroundColor: "..." }}` | `background="bgAlternate"` (or semantic token) | + +**Why this matters:** When you set `font`, `color`, `textAlign`, or other typography properties through `style` instead of props, the component loses its connection to the CDS theme. For example, setting `fontSize` and `fontWeight` via `style` without a `font` prop means the CDS font family never applies -- the text falls back to `inherit` and may render in the wrong typeface. + +Prefer: + +```tsx + + Label + +``` + +Avoid: + +```tsx + + Label + +``` + +The second example bypasses the CDS font family entirely -- `Text` will inherit whatever font its parent has rather than using the CDS typeface. + +**When `style` is appropriate:** Use `style` only for values that have no CDS prop equivalent, such as `cursor`, `transform`, `userSelect`, `letterSpacing`, or truly custom layout values like an exact pixel `height` that no spacing token matches. Even then, keep the prop-based values on the prop and only put the leftovers in `style`. + +### Theme usage + +Use `ThemeProvider` correctly at app boundaries and when nesting themes intentionally. + +When you need runtime access to theme values, use `useTheme`. On web, prefer CSS variables when possible for better performance and simpler styling. Use `useTheme` when you truly need computed values in JavaScript or React Native styles. + +Prefer theme-derived spacing, radius, typography, and colors over hardcoded numbers and strings. + +### Visualization and illustration + +Treat visualization and illustration packages as part of the CDS-first workflow. If the task includes charts, sparklines, axes, scrubbers, pictograms, hero art, or spot illustrations, look for CDS visualization or CDS illustration components before reaching for custom SVG or bespoke assets. + +When a design includes a chart, sparkline, axis, scrubber, or other data visualization: + +1. Check CDS visualization docs first. +2. Prefer `@coinbase/cds-web-visualization` on web and `@coinbase/cds-mobile-visualization` on mobile when CDS provides the chart or primitive. +3. Scan routes first when the task is broad to see whether CDS already has a purpose-built visualization component before composing with lower-level primitives. +4. Use custom SVG, canvas, or drawing code only when the CDS visualization package clearly cannot achieve the required behavior or appearance in a reasonable way. + +--- + +## Part 3: Reference + +Quick-lookup information for component selection and package mapping. + +### Package mapping + +- For standard web UI, use `@coinbase/cds-web`. +- For standard mobile UI, use `@coinbase/cds-mobile`. +- For web charts and data visualization, use `@coinbase/cds-web-visualization`. +- For mobile charts and data visualization, use `@coinbase/cds-mobile-visualization`. +- For illustrations and pictograms, use the documented CDS component import paths for the target platform rather than guessing from the standalone package name. + +The CDS MCP server exposes visualization and illustration docs through the same route listing as other CDS components. Do not assume that because a route is listed under `mobile/components/...` or `web/components/...` it should be imported from `@coinbase/cds-mobile` or `@coinbase/cds-web`. Read the doc and use the documented import path. + +### Component selection guidance + +Before composing custom UI from `Box` and `Text`, check whether CDS already provides a higher-level component for the job. + +Common examples: + +- Actions: `Button`, `IconButton`, `ButtonGroup` +- Inputs and selection: `TextInput`, `SearchInput`, `Select`, `Combobox`, `Checkbox`, `Radio`, `Switch` +- Layout and structure: `Box`, `HStack`, `VStack`, `Grid`, `PageHeader`, `SectionHeader`, `Sidebar` +- Feedback and status: `Banner`, `Toast`, `Spinner`, `ProgressBar`, `ProgressCircle` +- Data display: `Table`, `ListCell`, `ContentCell`, `DataCard`, `MessagingCard` +- Navigation and overlays: `Tabs`, `Dropdown`, `Modal`, `Alert`, `Tooltip` +- Visualization: `LineChart`, `AreaChart`, `BarChart`, `Sparkline`, `PeriodSelector`, `XAxis`, `YAxis`, `ReferenceLine`, `Point`, `Legend`, `Scrubber` +- Illustration and media: `Pictogram`, `HeroSquare`, `SpotIcon`, `SpotSquare`, `SpotRectangle`, `LogoMark`, `LogoWordMark` + +Do not memorize this list as exhaustive. Use it as a reminder to check the docs before inventing custom markup. + +### Code examples + +Prefer: + +```tsx +import { HStack, VStack } from '@coinbase/cds-web/layout'; +import { Box } from '@coinbase/cds-web/layout/Box'; + + + + + +``` + +Avoid: + +```tsx +
+
+
+
+``` + +Prefer: + +```tsx + +``` + +Avoid: + +```tsx +
+``` diff --git a/skills/cds-design-to-code/SKILL.md b/skills/cds-design-to-code/SKILL.md new file mode 100644 index 000000000..55f4f3223 --- /dev/null +++ b/skills/cds-design-to-code/SKILL.md @@ -0,0 +1,257 @@ +--- +name: cds-design-to-code +description: | + Turns frontend designs from Figma into CDS-first React or React Native code. + Use this skill whenever the user shares a Figma URL such as + `figma.com/design/...?...node-id=...` while working in a frontend application context. +license: Apache-2.0 +metadata: + author: ruikun.hao@coinbase.com + version: "1.0.0" +--- + +# CDS Design To Code + +This skill provides a structured workflow for translating Figma designs into CDS-first production code with high visual fidelity. It bridges the Figma MCP server with the Coinbase Design System, ensuring that designs are implemented using real CDS components and conventions rather than raw Figma HTML output. + +The goal is not to copy the Figma output literally. The goal is to use Figma MCP as the design source, then adapt that output into the target project's real CDS component stack. + +## When to use + +- Use when the user shares a Figma URL like `figma.com/design/...?node-id=...` and wants it implemented. +- Use when translating a Figma design into CDS-first React or React Native code. +- Use when the user asks to "implement this design" or "build this from Figma." +- Do not use when there is no Figma design to reference -- use the `cds-code` skill instead for general CDS UI work. +- Do not use for design feedback or critique without an implementation request. + +## Prerequisites + +- **`cds-code` skill** -- this skill depends on `cds-code` for component selection, styling rules, doc lookup workflow, and code quality standards. If `cds-code` is not installed, tell the user to install it first. +- **Figma MCP server** must be connected and accessible. Verify by checking whether `get_design_context` is available as an MCP tool. +- **CDS MCP server** must be connected for doc lookups via `list-cds-routes` and `get-cds-doc`. +- User must provide a Figma URL in the format: `https://figma.com/design/:fileKey/:fileName?node-id=1-2` + +If the Figma MCP server is missing or the `get_design_context` tool is not available: + +1. Tell the user that this workflow depends on the Figma MCP server and its `get_design_context` tool. +2. Suggest they configure a Figma MCP server in their project (e.g. via `.cursor/mcp.json` or their agent's MCP settings). +3. Continue only if you still have enough reliable design context from the prompt, screenshot, or pasted reference code. +4. If the design source is too incomplete to implement safely, stop and explain the blocker clearly. + +## Required Workflow + +**Follow these steps in order. Do not skip steps.** + +### Step 1: Parse the Figma URL + +When the user provides a Figma URL, extract the file key and node ID. + +**URL format:** `https://figma.com/design/:fileKey/:fileName?node-id=1-2` + +**Extract:** + +- **File key:** `:fileKey` (the segment after `/design/`) +- **Node ID:** `1-2` (the value of the `node-id` query parameter) + +**Branch URLs:** `figma.com/design/:fileKey/branch/:branchKey/:fileName` -- use `branchKey` as the file key. + +**Example:** + +- URL: `https://figma.com/design/kL9xQn2VwM8pYrTb4ZcHjF/DesignSystem?node-id=42-15` +- File key: `kL9xQn2VwM8pYrTb4ZcHjF` +- Node ID: `42-15` + +Convert `node-id=123-456` into `nodeId: "123:456"` when the tool requires colon-separated format. + +Prefer the exact node the user shared. Do not widen the request to a larger parent frame unless you have a concrete reason. + +### Step 2: Fetch Design Context + +Call `get_design_context` with the extracted file key and node ID. + +``` +get_design_context(fileKey=":fileKey", nodeId="1-2") +``` + +Use these defaults unless the user explicitly asks otherwise: + +- `disableCodeConnect: false` -- Code Connect is the highest-value signal from Figma MCP +- Keep screenshots enabled + +Pass accurate client context when you know it: + +- `clientFrameworks`: `react` for web React apps, `react-native` for React Native apps +- `clientLanguages`: `typescript`, `javascript`, or the known project languages + +**If the response is too large or truncated:** + +1. Keep the original user node as the source-of-truth entry point. +2. Run `get_metadata(fileKey=":fileKey", nodeId="1-2")` to get the high-level node map and discover child node IDs. +3. Identify the most relevant child frame or section for the requested implementation scope. +4. Re-run `get_design_context` on the narrower child node. +5. Tell the user briefly that you narrowed to a child section because the original node was too large. + +Do not treat `get_metadata` as a replacement for `get_design_context`. It is only a way to navigate large trees when the initial node is too broad. + +**Staying narrow:** Figma MCP becomes less helpful when the selected node contains many unrelated frames. Stay on the specific node the user provided, prefer a clearly scoped child frame over a giant parent screen if the tool becomes noisy, and keep Code Connect enabled. If the tool still reports many unmapped frames, check whether the returned screenshot and code are still actionable before bouncing the problem back to the user. + +### Step 3: Capture Visual Reference + +Run `get_screenshot` with the same file key and node ID. + +``` +get_screenshot(fileKey=":fileKey", nodeId="1-2") +``` + +This screenshot is the visual source of truth throughout implementation. Keep it accessible for comparison during the visual verification step. + +### Step 4: Download Required Assets + +Download any assets (images, icons, SVGs) returned by the Figma MCP server. + +- If the Figma MCP server returns a `localhost` source for an image or SVG, use that source directly. +- Do not import or add new icon packages -- all assets should come from the Figma payload. +- Do not create placeholders if a `localhost` source is provided. + +### Step 5: Ground the Target Platform + +Before translating the design into CDS code, ground yourself in the target app. + +1. Identify whether the user is targeting `web` or `mobile`. +2. Confirm that choice from repo context when the project is available. +3. Only then decide which CDS platform docs to read. + +Do not guess the platform from the Figma design alone when the repo tells you more. + +If both web and mobile exist and the target is genuinely ambiguous, ask one concise clarifying question. + +**Read the CDS coding standards:** Before writing any CDS code, read the `cds-code` skill for the full set of CDS-first coding standards including layout defaults, styling defaults, component selection guidance, package mapping, and theme usage. That skill is the canonical reference for how to write CDS code -- this skill focuses on the Figma-to-CDS bridge. + +### Step 6: Translate to CDS Components + +This is the core translation step. The Figma MCP response is a mixed-confidence input -- treat each part accordingly. + +**Confidence hierarchy:** + +| Source | Confidence | How to use | +|--------|-----------|------------| +| `CodeConnectSnippet` | Highest | Preserve the component choice. It maps to a real component chosen by the design system team. Keep the composition close to the snippet after fixing imports, props, and data wiring. | +| Screenshot | High | Use for layout hierarchy, spacing rhythm, and visual intent verification. | +| Default HTML / Tailwind classes | Lower | Structural hints that must be adapted into CDS components. Never ship raw Figma HTML in a CDS app. | + +**CDS doc lookup:** Follow the `cds-code` skill's setup and component selection steps to discover and read CDS docs before choosing imports, props, or composition patterns. + +**Translating fallback HTML and Tailwind classes:** + +When parts of the Figma response fall back to raw HTML or Tailwind-like classes, use them as evidence, not as the final implementation. Look for clues: + +- Layout classes like `flex`, `flex-row`, `flex-col`, `items-start`, `justify-between` +- Spacing classes like `gap-[8px]`, `px-[var(--spacing/...)]`, `pb-[16px]` +- Semantic names in `data-name` attributes like `SectionHeader`, `List`, `Card`, `Row`, `Header` +- Repeated structures that imply a CDS collection or cell pattern + +Translate those clues into CDS primitives and components: + +- `flex-row` -> `HStack` +- `flex-col` -> `VStack` +- Padding and gap values -> CDS spacing props or tokens, not raw Tailwind classes +- `data-name` hints -> check CDS docs before inventing custom UI + +Example: a fallback wrapper like `flex flex-col gap-[8px] px-[8px]` likely wants a `VStack` with `gap` and `paddingX`. A `data-name="SectionHeader"` is a strong signal to check whether CDS already has a `SectionHeader` component. + +Do not guess the final component tree from CSS alone when CDS docs can confirm the intended abstraction. + +**Props before `style`:** + +When translating Figma values to CDS code, always check the target component's prop table before reaching for `style`. Figma MCP output often includes raw CSS values for font size, weight, color, alignment, and transforms. Do not copy those values into a `style` prop when the CDS component already has a dedicated prop. + +For example, Figma may output a label with `font-size: 10px`, `font-weight: 500`, `text-transform: uppercase`, `color: var(--palette/foregroundmuted)`. The correct translation is to find the matching CDS `font` token (e.g. `font="caption"`), then use `color="fgMuted"` and `textTransform="uppercase"` as props -- not to dump everything into `style`. Using `style` for these values bypasses the CDS font family and theme wiring, causing the text to render in the wrong typeface. + +Only use `style` for values that have no CDS prop equivalent (e.g. `cursor`, `transform`, `letterSpacing`, exact pixel dimensions). See the "Avoid unnecessary `style` overrides" section in the `cds-code` skill for the full rule and examples. + +### Step 7: Achieve Visual Parity + +Strive for high visual fidelity with the Figma design. Do not stop after the first implementation pass when you have tooling to inspect the result. + +After writing or updating the code: + +1. Render the target UI locally when possible. +2. Use the Figma screenshot from Step 3 as the visual source of truth. +3. Inspect the rendered implementation visually in the browser tooling. +4. Compare at a matching viewport as closely as possible. +5. Fix the most obvious visual mismatches before finishing. + +Pay special attention to: + +- Section widths and content stretch behavior +- Spacing between nav, tabs, chips, cards, and footer +- Corner radius, border, and shadow treatment +- Typography hierarchy, truncation, and wrapping +- Scroll containers, clipping, and overflow behavior +- Active and inactive states for tabs, chips, and nav items +- Colors matching design tokens exactly +- Responsive behavior following Figma constraints + +Prefer a short corrective loop: implement, visually compare, correct the largest differences, re-check once more. + +Do not claim visual fidelity based only on reading code or DOM structure. If browser inspection is available, use it. + +### Step 8: Validate Against Figma + +Before marking complete, validate the implementation against the Figma screenshot. + +**Validation checklist:** + +- [ ] Layout matches (spacing, alignment, sizing) +- [ ] Typography matches (font, size, weight, line height) +- [ ] Colors match design tokens +- [ ] CDS components used wherever one exists +- [ ] Code Connect mappings preserved from Figma MCP response +- [ ] No raw Tailwind classes left in the final output (unless the target project uses them) +- [ ] Interactive states work as designed (hover, active, disabled) +- [ ] Responsive behavior follows Figma constraints +- [ ] Assets render correctly +- [ ] Imports and props match CDS docs +- [ ] No `style` overrides for values that have a CDS prop (font, color, textAlign, padding, gap, etc.) +- [ ] Accessibility standards met + +## Implementation Rules + +Follow the `cds-code` skill for all component selection, styling, and code quality rules. When a Code Connect snippet already uses CDS components cleanly, preserve that mapping rather than re-deriving it. + +## Common Issues and Solutions + +### Issue: Figma output is truncated + +The design is too complex for a single response. Use `get_metadata` to get the node structure, then fetch specific child nodes individually with `get_design_context`. + +### Issue: Design doesn't match after implementation + +Compare side-by-side with the screenshot from Step 3. Check spacing, colors, and typography values in the design context data. Run the corrective loop from Step 7. + +### Issue: Assets not loading + +Verify the Figma MCP server's assets endpoint is accessible. The server serves assets at `localhost` URLs -- use them directly without modification. + +### Issue: Code Connect returns unexpected components + +The Code Connect snippet maps to a real component chosen by the design system team. Preserve it unless the target repo clearly documents a different import path. If the snippet already uses CDS components, it is often nearly copy-pasteable after fixing imports, props, and data wiring. + +### Issue: Mostly fallback HTML with few Code Connect mappings + +This is normal for designs with many unmapped elements. Use the fallback HTML as structural evidence, translate layout classes to CDS primitives, and use `data-name` hints to look up CDS components before inventing custom markup. + +### Issue: Design token values differ between Figma and CDS + +When CDS tokens differ from Figma values, prefer CDS tokens for consistency. Adjust spacing or sizing minimally to maintain visual fidelity. + +## Communication Style + +Be concise and implementation-oriented. + +- Mention when the design source was high confidence versus inferred. +- Call out when you preserved a Code Connect mapping directly. +- If you had to infer a CDS replacement from fallback HTML, explain the reasoning briefly. +- Ask clarifying questions only when the ambiguity would materially change the shipped UI. + +Avoid turning the workflow into a long design critique unless the user asked for one. From bbf9c7bd04a768434bf96b5a3c83ffea43e19ee2 Mon Sep 17 00:00:00 2001 From: Harry Hao Date: Fri, 27 Mar 2026 18:26:40 -0500 Subject: [PATCH 2/3] chore: format --- skills/cds-code/SKILL.md | 32 +++++++++++++++--------------- skills/cds-design-to-code/SKILL.md | 12 +++++------ 2 files changed, 22 insertions(+), 22 deletions(-) diff --git a/skills/cds-code/SKILL.md b/skills/cds-code/SKILL.md index 9ddc05d68..6fe21e8ca 100644 --- a/skills/cds-code/SKILL.md +++ b/skills/cds-code/SKILL.md @@ -7,7 +7,7 @@ description: | license: Apache-2.0 metadata: author: ruikun.hao@coinbase.com - version: "1.0.0" + version: '1.0.0' --- # CDS Code @@ -139,16 +139,16 @@ Before adding any property to a `style` prop, check whether the component alread Common props that are frequently misused via `style` instead of the proper prop: -| Instead of `style` | Use the prop | -|---|---| -| `style={{ color: "var(--color-fgMuted)" }}` | `color="fgMuted"` | -| `style={{ fontSize: 12, fontWeight: 500, lineHeight: "16px" }}` | `font="caption"` (or the matching CDS font token) | -| `style={{ textAlign: "center" }}` | `textAlign="center"` | -| `style={{ textTransform: "uppercase" }}` | `textTransform="uppercase"` | -| `style={{ display: "flex", flexDirection: "column" }}` | Use `VStack`, or `flexDirection="column"` on `Box` | -| `style={{ gap: 8 }}` | `gap={1}` | -| `style={{ padding: 16 }}` | `padding={2}` | -| `style={{ backgroundColor: "..." }}` | `background="bgAlternate"` (or semantic token) | +| Instead of `style` | Use the prop | +| --------------------------------------------------------------- | -------------------------------------------------- | +| `style={{ color: "var(--color-fgMuted)" }}` | `color="fgMuted"` | +| `style={{ fontSize: 12, fontWeight: 500, lineHeight: "16px" }}` | `font="caption"` (or the matching CDS font token) | +| `style={{ textAlign: "center" }}` | `textAlign="center"` | +| `style={{ textTransform: "uppercase" }}` | `textTransform="uppercase"` | +| `style={{ display: "flex", flexDirection: "column" }}` | Use `VStack`, or `flexDirection="column"` on `Box` | +| `style={{ gap: 8 }}` | `gap={1}` | +| `style={{ padding: 16 }}` | `padding={2}` | +| `style={{ backgroundColor: "..." }}` | `background="bgAlternate"` (or semantic token) | **Why this matters:** When you set `font`, `color`, `textAlign`, or other typography properties through `style` instead of props, the component loses its connection to the CDS theme. For example, setting `fontSize` and `fontWeight` via `style` without a `font` prop means the CDS font family never applies -- the text falls back to `inherit` and may render in the wrong typeface. @@ -167,10 +167,10 @@ Avoid: style={{ fontSize: 10, fontWeight: 500, - lineHeight: "12px", - textTransform: "uppercase", - textAlign: "center", - color: "var(--color-fgMuted)", + lineHeight: '12px', + textTransform: 'uppercase', + textAlign: 'center', + color: 'var(--color-fgMuted)', }} > Label @@ -244,7 +244,7 @@ import { Box } from '@coinbase/cds-web/layout/Box'; - +; ``` Avoid: diff --git a/skills/cds-design-to-code/SKILL.md b/skills/cds-design-to-code/SKILL.md index 55f4f3223..d1047eb5e 100644 --- a/skills/cds-design-to-code/SKILL.md +++ b/skills/cds-design-to-code/SKILL.md @@ -7,7 +7,7 @@ description: | license: Apache-2.0 metadata: author: ruikun.hao@coinbase.com - version: "1.0.0" + version: '1.0.0' --- # CDS Design To Code @@ -133,11 +133,11 @@ This is the core translation step. The Figma MCP response is a mixed-confidence **Confidence hierarchy:** -| Source | Confidence | How to use | -|--------|-----------|------------| -| `CodeConnectSnippet` | Highest | Preserve the component choice. It maps to a real component chosen by the design system team. Keep the composition close to the snippet after fixing imports, props, and data wiring. | -| Screenshot | High | Use for layout hierarchy, spacing rhythm, and visual intent verification. | -| Default HTML / Tailwind classes | Lower | Structural hints that must be adapted into CDS components. Never ship raw Figma HTML in a CDS app. | +| Source | Confidence | How to use | +| ------------------------------- | ---------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| `CodeConnectSnippet` | Highest | Preserve the component choice. It maps to a real component chosen by the design system team. Keep the composition close to the snippet after fixing imports, props, and data wiring. | +| Screenshot | High | Use for layout hierarchy, spacing rhythm, and visual intent verification. | +| Default HTML / Tailwind classes | Lower | Structural hints that must be adapted into CDS components. Never ship raw Figma HTML in a CDS app. | **CDS doc lookup:** Follow the `cds-code` skill's setup and component selection steps to discover and read CDS docs before choosing imports, props, or composition patterns. From ca28b2e26c8133a6a15d866b130cdad5e00b0fb0 Mon Sep 17 00:00:00 2001 From: Harry Hao Date: Mon, 30 Mar 2026 10:31:23 -0500 Subject: [PATCH 3/3] chore: trigger CI