cds

Reviews already-written Coinbase Design System (CDS) UI for accessibility: verifying documented accessibility props (e.g. accessibilityLabel, accessibilityState), confirming the chosen CDS primitives cover the right assistive technology behavior, and checking usage against official CDS documentation—not generic web ARIA tutorials. Use this skill to review CDS UI for screen reader, keyboard, and labeled control requirements after the code has been written.

Provides a workflow for building and reviewing high-quality React and React Native UI with the Coinbase Design System (CDS). Use this skill to create UI or make visual changes to existing UI with CDS components, tokens, style props, icons, and illustrations. Use it for explicit CDS-adherence audits and reviews, not non-visual logic, data, analytics, navigation, tests, generated code, or refactoring. Examples: "build this screen", "fix spacing on this component", "replace this UI with CDS components", "perform a CDS audit on our changes", "check our codebase for CDS adherence", "does this feature use CDS well?"

Turn Figma designs into CDS React (cds-web) or React Native (cds-mobile) code. Use when the user shares a Figma design URL (e.g. `figma.com/design/...?node-id=...`) or asks to "implement this design" or "build this from Figma" in a frontend project that is using Coinbase Design System (CDS). Do not use for general CDS UI work with no Figma reference (use `cds-code`), or for design critique without an implementation request.

Retrieve Coinbase Design System (CDS) documentation: setup, installation, theming, tokens, and per-component APIs/examples. Use this skill whenever the task involves CDS components, design-system rules, theming, or choosing between web and mobile CDS packages, even if the user only says "use CDS" or names a component. Always start from the docs route index, then fetch only the pages you need to reason and implement correctly. Prefer the CDS MCP server (`list-cds-routes`, `get-cds-doc`); if MCP is unavailable, use curl against https://cds.coinbase.com/llms/....

Use when a CDS change in **cds-web**, **cds-common**, **cds-mobile**, **web-visualization**, or **mobile-visualization** needs a **jscodeshift** migration in `packages/migrator` to update callers or mitigate breaking API or import moves (add or change a transform, tests, or preset entry).

Use this skill whenever working on CDS React components in any package.

Guidelines writing styles API (styles, classNames, and static classNames) for a CDS component. Use this skill when adding customization options to a React component via `styles` or `classNames` props or when needing to update the docsite with component styles documentation.

Guidelines for creating or updating documentation for a CDS component on the docsite (apps/docs/). Use this skill after creating or making updates to a CDS React component to write high quality documentaiton in the CDS docsite.

Deprecates a CDS component, hook, or other exported symbol with consistent JSDoc, version tags, and docsite metadata across every public export path (web, mobile, common, visualization), not only the original package. Use whenever the user asks to deprecate a CDS component or API, mark something as deprecated, add @deprecated / @deprecationExpectedRemoval, or update deprecation warnings in apps/docs metadata under components or hooks (webMetadata.json / mobileMetadata.json / metadata.json). Also use when replacing a component or hook and sunsetting the old one. Always finish by running `yarn nx run <project>:lint` on modified packages so `internal/deprecated-jsdoc-has-removal-version` passes.

USE THIS when asked to work on a new or existing (MOBILE) CDS React component in packages/mobile

USE THIS when asked to work on a new or existing (WEB) CDS React component in packages/web

USE THIS when asked to create a new eslint plugin rule for the eslint-plugin-cds package

A guided workflow for non-technical contributors (designers, PMs) to describe a feature idea and produce a detailed technical implementation plan for an engineer. Invoke manually with /feature-planner.

Enumerates every public component set in a CDS Figma file and produces a list of [Component Name]: [Figma URL] entries grouped by page section. Use this skill whenever asked to list, generate, or audit Figma component URLs, produce a component inventory from a Figma file, or when doing a Code Connect refresh/audit that requires knowing which Figma node each component maps to. Also trigger when someone asks "what are the Figma URLs for CDS components" or wants to find the node-id for a specific component.

Back-port a specific commit from master to a release branch via cherry-pick. Creates a dedicated backport branch, attempts the cherry-pick, pushes it, and opens a PR by default. Returns to the original branch when done (success or failure). If there are merge conflicts, diagnoses the root cause without attempting an autonomous resolution. Use when asked to "backport", "cherry-pick to release", or "port a fix to a release branch".

Analyzes the previous N commits for breaking changes across the CDS public API surface. Use this skill when you need to check if any recent changes will cause breaking changes in the CDS public API surface.

Instructions to manage a local cache of GitHub repositories. This would typically done in cases where the user want to perform research/analysis on a repository. Invoke whenever you need to clone a repo that isn't present locally, bring an existing clone up to date, or remove a repo from the cache. This skill handles only the mechanical filesystem/git operations — not research, analysis, or anything about the repo's contents.

Resolve rebase/merge conflicts in CDS release-versioning files — package.json "version" fields and CHANGELOG.md entries — that arise because packages were versioned independently on master and the current branch. Recomputes each package's version by applying the branch's bump type (patch/minor/major) on top of master's latest version, rewrites CHANGELOG entries with today's date and the new version, then continues the rebase and formats. Use when the user asks to "resolve a versioning conflict", "resolve a package.json conflict", "resolve a changelog conflict", or when you organically detect conflict markers in package.json / CHANGELOG.md files during a rebase or merge. When detected organically, ALWAYS ask the user for confirmation before running this flow.

USE THIS when writing or reviewing Jetpack Compose / Kotlin code in packages/cds-android or apps/android-app - @Composable APIs, Modifier parameters, CompositionLocal, state hoisting, or naming. Not for React or React Native work.

Instructions to fetch assigned Linear issues in the current cycle and potentially kick off a development session.