Superdesign skill: giving a coding agent something to design with

A skill is a set of instructions and a CLI bridge, not a design engine

It helps to be precise about what this repository contains, because the name can mislead. The package published here is superdesign-dsh at version 0.6.0, an ES module whose main entry is dsh/index.js. The files it ships are dsh/index.js, a patch file, the skills directory and the assets directory. That is the whole payload.

So the skill is a bundle of instructions, plus the plugin manifests for the agent platforms: .claude-plugin/, .codex-plugin/ and .cursor-plugin/ sit at the repository root, and a .claude/ directory holds the Claude-specific parts. The keywords in the manifest name the shape of it, including dsh-plugin, deepseek-harness, infinite-canvas and design.

The actual design work is not here. The documentation points at superdesign.dev as the AI product design agent that powers the skill, and the skill calls a command line tool that talks to that service. The design agent reads your codebase context, gathers style references, and produces drafts on an infinite canvas that you branch and refine.

That split is the key thing to evaluate. You are installing a well-packaged prompt and workflow into your agent, plus a client for someone else's design service. If the service disappears or changes its pricing, the skill in your repository will not carry the capability with it.

The differentiator is designing into an existing design system, not swapping a theme

The documentation draws a comparison that tells you where the effort went. Style-preset skills, in its framing, swap in a theme or a component library. Superdesign instead designs into your existing design system: it reads your code for context, gathers real style references, and produces branchable drafts that you refine.

The mechanism for reading your code is worth spelling out, because it is unusual. The skill does not have direct access to your codebase. Instead, the workflow creates a pixel perfect HTML replica of the current UI of the page being designed on top of, stored at .superdesign/replica_html_template/<name>.html, and that replica plus the design system guide becomes the input to a new project. The document is supposed to reflect how the UI looks now, with the actual redesign left to the design agent.

The always-on rules pin down two more conventions. The design system file lives at .superdesign/design-system.md, and if that file is missing the skill is supposed to run a Design System Setup first. The workflow also asks the user high-signal questions about constraints, taste and tradeoffs using whatever user-input mechanism the session provides, falling back to asking in chat.

So the design system file is not documentation for humans. It is a required input to the process, and a project without one starts with a setup step rather than a design.

Installation differs by agent, and Claude Code warns against mixing the two paths

For a generic coding agent, the install is a single command that targets any of the 70 or more supported agents.

npx skills add superdesigndev/superdesign-skill

Claude Code has its own path, installing it as a plugin so it stays namespaced and updates with a plugin update command.

/plugin marketplace add superdesigndev/superdesign-skill
/plugin install superdesign@superdesign

The skill is then invoked as /superdesign:superdesign. The documentation includes an explicit warning here: do not also run npx skills add inside Claude Code, because that installs a second, unnamespaced copy of the same skill. That is a small detail with a large practical consequence, since a duplicated skill means the agent can load two descriptions of the same workflow and pick either one.

Whichever route you take, the CLI that the skill drives has to be installed and authenticated separately.

npm install -g @superdesign/cli@latest
superdesign login

The login step is where the dependency on the hosted service becomes explicit. The skill is MIT licensed and open source, but the capability it drives requires an authenticated account with superdesign.dev. Installation is therefore three-part, not one-part, and the third part is the one with a service behind it.

The repository also carries INSTALL.md, DESIGN.md, CLAUDE.md, AGENTS.md and a CHANGELOG.md, so the agent-specific instructions live in files that a coding agent will read on its own.

The CLI exposes a prompt library, site extraction and canvas commands

The skill drives a CLI whose command surface is worth knowing, because it is what the agent calls on your behalf. The first group is generic and always available: searching the prompt library for style, component and page references, and fetching prompt details.

  superdesign search-prompts --query "<keyword>"
  superdesign search-prompts --tags "style"
  superdesign search-prompts --tags "style" --query "<style keyword>"

The pattern in those commands matters. The documentation tells the agent to read the compact index first and only then fetch the full body for the slugs it picks, which keeps the context window small.

  superdesign get-prompts --slugs "<slug1,slug2,...>"          # index
  superdesign get-prompts --slugs "<slug>" --full             # full body of the chosen slug(s)

Third, a site can be reduced to a design DNA document, with a style guide, tokens, content, brand and clone as the target output.

  superdesign extract-website --url https://example.com --design-md

The second group is the canvas tools, and they are described as operations rather than commands with documented flags: create a project, optionally seeding a baseline draft from an HTML template via --template, create a design draft, iterate a draft by replacing or branching it, plan flow pages then execute them, fetch a specific draft, create a presentation from an approved ordered slide outline, read a stored outline and preferences for safe iteration, and list reusable project brand assets.

One output convention applies to everything. Each command's default output is agent-optimised, using compact TOON plus help[] next-step hints, and --json is only for when the full machine-readable payload is genuinely needed, with --full only to expand truncated fields.

Cross session continuity is what separates the skill from a one-shot prompt

The feature that makes this more than a prompt template is described as cross session continuity. After the first real-codebase design, the skill remembers the project, the draft, the extracted components and a budgeted source-context bundle, so later unchanged iterations resume without repeating codebase discovery.

That is a specific engineering claim with a specific motivation. Codebase discovery is the expensive part of a design pass, and repeating it on every iteration is what makes agent-driven design slow and expensive. Caching the discovery result and the extracted component set means a second pass on the same page starts from the known context.

The bundle is described as budgeted, which suggests an explicit context allowance rather than an unbounded cache. Combined with the compact TOON output convention and the index-then-full-body pattern for prompts, the whole design is oriented around one constraint: an agent session has a finite context budget, so the tooling returns small structured payloads by default and the agent pulls more only when it decides to.

That focus also explains why the skill is described as remembering what it extracted rather than what it produced. Components are the reusable part of a design system, so extracting them once and reusing them across drafts is where the value of continuity lies.

Five scenarios, and a workflow that asks before it designs

The scenario list covers five jobs: designing or improving UI for a feature, page or flow; creating a presentation with an editable approved outline; creating graphics such as posters, covers, social posts and ads; setting or extracting a design system; and generating supporting images or video.

The presentation path is the one with the strictest workflow. A presentation is created from an approved ordered slide outline, and there is a dedicated command to read a stored presentation outline and preferences for safe iteration. The word approved is doing real work there, since the outline is a gate before slides exist.

The overall procedure for designing a feature on top of an existing application is spelled out as a numbered sequence. Investigate the existing UI and workflow. Set up the design system file if it does not exist yet. Gather requirements by asking the user. Then ask whether to design in superdesign or implement the UI directly. Only if the answer is yes does the replica HTML get created, the project get seeded with that replica and the design system guide, and the drafting begin by iterating and branching on the design draft ID returned from the project.

That fourth step is the one an engineering team should notice. The skill is designed to hand the work back to the agent when the user prefers direct implementation, which means the design agent is an option in the flow rather than a mandatory detour before every UI change.

Where Superdesign skill is the wrong tool

The clearest wrong-tool case is a team that cannot depend on a hosted design service. The skill is MIT licensed and the instructions are readable, but the canvas, the prompt library, the site extraction and the design agent all live behind superdesign.dev and the CLI's login. A team with a policy against sending design context to a third party has no offline path here, and the repository does not describe one.

The second case is a codebase with no design system and no patience for the setup step. The always-on rules require .superdesign/design-system.md to exist, and the workflow begins by asking questions and creating a replica of the current UI before any drafting. On a large legacy frontend with several visual dialects, that discovery step is the bulk of the work, and the skill produces a replica rather than a finished design.

The third case is a team that wants a deterministic, reviewable design artifact. What comes back is a draft produced by an agent, and the documentation frames the deliverable as something you branch and refine. That is a good fit for exploration and a poor fit for a design system that has to match an approved spec exactly.

On licensing and upkeep, the manifest declares MIT and the repository carries the LICENSE file, which is permissive and easy to vendor. The maintenance picture is less settled. The last push was on 2026-08-21, and the repository has no GitHub releases, so the version you see in the manifest, 0.6.0, is the only version marker available. The documentation also warns that the archived superdesigndev/superdesign VS Code extension is an older, separate project, so anyone arriving from that extension should not expect its behaviour.

Editorial conclusion

superdesign-skill suits a developer who works inside a coding agent and wants a design pass with real style references before code gets written, especially when the codebase already has a design system file at .superdesign/design-system.md to build on. It does not suit a team that needs the design work to run entirely on its own infrastructure, because the agent, the canvas and the CLI reach superdesign.dev, and the skill itself is thin enough that its value depends on that service. Before adopting, install the CLI with npm install -g @superdesign/cli@latest, run superdesign login, and confirm the agent variant you use installs the skill the way its documentation expects, since running npx skills add inside Claude Code installs a second unnamespaced copy.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. superdesigndev/superdesign-skill on GitHub