| name | cds-docs |
| description | 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/....
|
| license | Apache-2.0 |
| metadata | {"version":"2.0.0"} |
CDS Documentation Skill
Goal: Pull CDS documentation into the session so your next edits, recommendations, and
API usage are grounded in current docs—not to produce a documentation handout for the user.
Treat fetched pages as source material you have read: internalize props, patterns, imports, and
setup constraints, then act (code, refactors, answers) from that understanding. Quote or
summarize for the user only when it helps. Keep the actual doc page contents to yourself
and only share their contents directly to the user if they ask.
Whether you use the CDS MCP server or fetch the pages yourself with curl is an implementation detail.
The use does not need to know your methodology unless they indicated they are debugging this skill.
Ambiguous product requests (e.g. “turn this into tabs,” “make it a card”) after you’ve read the
index: if CDS components could be relevant (e.g. underline vs pill vs
), it is to ask short, concrete question (e.g.
which visual pattern matches their spec) while briefly naming the options and how they differ per
the docs. Do not pick one arbitrarily just to avoid asking.