design-data
Validate, query, resolve, diff, and author spec-conformant design tokens and components using the design-data MCP tools against a…
Look up Spectrum 2 (S2) component documentation, design guidelines, and usage patterns when building with React Spectrum or Spectrum Web Components. Use when the user mentions Spectrum, S2, React Spectrum, RSP, Spectrum Web Components, or SWC, or names a Spectrum component
$ npx -y skills add adobe/spectrum-design-data --skill s2-docs --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/s2-docsContext preview
The summary Claude sees to decide when to auto-load this skill.
Look up Spectrum 2 (S2) component documentation, design guidelines, and usage patterns when building with React Spectrum or Spectrum Web Components. Use when the user mentions Spectrum, S2, React Spectrum, RSP, Spectrum Web Components, or SWC, or names a Spectrum component
name: s2-docs
description: >
Look up Spectrum 2 (S2) component documentation, design guidelines, and usage
patterns when building with React Spectrum or Spectrum Web Components. Use
when the user mentions Spectrum, S2, React Spectrum, RSP, Spectrum Web
Components, or SWC, or names a Spectrum component (Button, Picker, ComboBox,
TextField, ActionButton, etc.). Helps prevent drift from documented S2 design
decisions during prototyping.
metadata:
author: adobe
version: "1.3.0"
when_to_use: >
Trigger on: "which Spectrum component", "React Spectrum", "Spectrum Web
Components", "@adobe/react-spectrum", "@spectrum-web-components", component
name imports, "S2 tokens", "Spectrum spacing", "Spectrum variant", or any
question about what a Spectrum component should do or look like.
allowed-tools: Bash(node ${CLAUDE_SKILL_DIR}/scripts/lookup.js *)Fetch canonical S2 docs before suggesting any Spectrum component or pattern. This prevents common vibe-coding mistakes: wrong variant, hard-coded sizes, divider-first layouts, missing required props.
**Get a specific component** (use before writing any RSP/SWC code):
node ${CLAUDE_SKILL_DIR}/scripts/lookup.js get <component-name>**Find components by use case**:
node ${CLAUDE_SKILL_DIR}/scripts/lookup.js use-case "<phrase>"**Search by name**:
node ${CLAUDE_SKILL_DIR}/scripts/lookup.js search <query>**List all components in a category** (`actions`, `containers`, `feedback`, `inputs`, `navigation`, `status`):
node ${CLAUDE_SKILL_DIR}/scripts/lookup.js list --category <category>Cursor does not support inline shell injection. Use Bash explicitly with `--cursor` for trimmed, delimited output:
node ${CLAUDE_SKILL_DIR}/scripts/lookup.js get <component-name> --cursor
node ${CLAUDE_SKILL_DIR}/scripts/lookup.js use-case "<phrase>" --cursor1. **Identify the component(s)** the user needs — use `use-case` or `search` if unsure. 2. **Fetch the docs** with `get <name>` for each relevant component. 3. **Read the "Component options" table** — note variants, sizes, required props. 4. **Apply the anti-drift checklist** before writing code.
After fetching docs, verify every suggestion against:
This repo uses: pnpm for package management moon to manage task running Changesets for automated versioning and releasing Prettier for code formatting/linting commitlint and Convetional Commits to standardize commit messages husky to automate formatting of
Validate, query, resolve, diff, and author spec-conformant design tokens and components using the design-data MCP tools against a…