/ds
Which design-system skill to reach for — routes between /ds-doctor, /ds-plan, and /ds-drift.
Claude Code
$ npx -y skills add igloude/ds-skills --skill ds --agent claude-code
Codex
$ npx skills add igloude/ds-skills --skill ds -a codex -y
Cursor
$ npx skills add igloude/ds-skills --skill ds -a cursor -y
Gemini CLI
$ npx skills add igloude/ds-skills --skill ds -a gemini-cli -y
GitHub Copilot
$ npx skills add igloude/ds-skills --skill ds -a github-copilot -y
OpenCode
$ npx skills add igloude/ds-skills --skill ds -a opencode -y
Windsurf
$ npx skills add igloude/ds-skills --skill ds -a windsurf -y
SKILL.md
ds.SKILL.mdname: ds
description: Which design-system skill to reach for — routes between /ds-doctor, /ds-plan, and /ds-drift.
disable-model-invocation: true
license: MIT
metadata:
author: Ian Gloude
version: "0.5.0"
ds — the router
Three sibling skills police design-system conformance. All are **report-only** — they write verdicts, maps, and plans, never code. This skill only routes; when the user's intent matches a row below, tell them the command (or invoke the named skill if they ask you to proceed).
/ds-doctor → audits the DS itself, writes ds/MANIFEST.md + ds/tokens.json
└→ everything below reads it
/ds-plan → classifies a feature's UI against the DS before it is built
├→ Covered / Composable → exact props, to the generators
└→ Extension / Net-new → DS work items → the DS backlog
generators → N branches of AI work
/ds-drift → reviews finished code for DS conformance
├→ reviews: verdicts + specs → back to the generators
└→ plans: self-contained specs → cheap executor, or --issuesReach for
- **`/ds-drift`** — the work exists and needs judging: gate a branch or PR, batch-review parallel agent branches, sweep a repo for token/adoption/a11y drift, audit a DS version upgrade, or `reconcile` the backlog.
- **`/ds-plan`** — the work doesn't exist yet: a ticket, spec, or design needs classifying against the DS, sequencing into DS-repo vs app-repo waves, or a quick "do we have something for this?" (`element`).
- **`/ds-doctor`** — the design system itself is the subject: is it enforceable, where are the doc/token/policy gaps, and generate or refresh the conformance manifest (run `manifest` after every DS release).
The loop
1. In the DS repo: `/ds-doctor`, fix blockers, `/ds-doctor manifest`, publish `ds/` with the package. 2. Before a feature: `/ds-plan <ticket|design>` in the app repo; ship Wave 0 DS work, hand the map to the building agent. 3. After generation: `/ds-drift` on the branch (or `batch` across parallel branches); feed the review back to the generator. 4. Periodically: `/ds-drift sweep` for the baseline, `coverage` for the trendline, `reconcile` to keep the record honest.
Read more
name: ds description: Which design-system skill to reach for — routes between /ds-doctor, /ds-plan, and /ds-drift. disable-model-invocation: true license: MIT metadata: author: Ian Gloude version: "0.5.0"
ds — the router
Three sibling skills police design-system conformance. All are **report-only** — they write verdicts, maps, and plans, never code. This skill only routes; when the user's intent matches a row below, tell them the command (or invoke the named skill if they ask you to proceed).
/ds-doctor → audits the DS itself, writes ds/MANIFEST.md + ds/tokens.json
└→ everything below reads it
/ds-plan → classifies a feature's UI against the DS before it is built
├→ Covered / Composable → exact props, to the generators
└→ Extension / Net-new → DS work items → the DS backlog
generators → N branches of AI work
/ds-drift → reviews finished code for DS conformance
├→ reviews: verdicts + specs → back to the generators
└→ plans: self-contained specs → cheap executor, or --issuesReach for
- **`/ds-drift`** — the work exists and needs judging: gate a branch or PR, batch-review parallel agent branches, sweep a repo for token/adoption/a11y drift, audit a DS version upgrade, or `reconcile` the backlog.
- **`/ds-plan`** — the work doesn't exist yet: a ticket, spec, or design needs classifying against the DS, sequencing into DS-repo vs app-repo waves, or a quick "do we have something for this?" (`element`).
- **`/ds-doctor`** — the design system itself is the subject: is it enforceable, where are the doc/token/policy gaps, and generate or refresh the conformance manifest (run `manifest` after every DS release).
The loop
1. In the DS repo: `/ds-doctor`, fix blockers, `/ds-doctor manifest`, publish `ds/` with the package. 2. Before a feature: `/ds-plan <ticket|design>` in the app repo; ship Wave 0 DS work, hand the map to the building agent. 3. After generation: `/ds-drift` on the branch (or `batch` across parallel branches); feed the review back to the generator. 4. Periodically: `/ds-drift sweep` for the baseline, `coverage` for the trendline, `reconcile` to keep the record honest.
Police large volumes of AI-generated frontend work for design-system adherence, plan features against the system before they're built, and audit the design system itself so it can be policed. The idea: generation is cheap, the bottleneck is judgment.
More skills from other plugins.
brainstorming
You MUST use this before any creative work - creating features, building components, adding functionality, modifying behavior, or…
ask-matt
Ask which skill or flow fits your situation. A router over the skills in this repo.
Questions about ds.
- Which coding agents can use ds?
- ds installs in Claude Code, Codex, Cursor, Gemini CLI, GitHub Copilot, OpenCode and Windsurf with the skills CLI, using each agent's flag shown on this page. Flowy's auto-invocation, which fires a skill when your prompt matches, runs in Claude Code only.

