Skills

A skill is a command you type in Claude Code. The plugin ships 33 skills: 13 for design work and 20 for engineering workflow. The design family carries the dx-design- prefix. They install together when you install the plugin. You do not need to memorise the list: type /dx-harness:dx-design and it determines what you need and routes you.

Two rules hold for every design skill:

• You cannot break anything by asking. One design skill edits the product: dx-design-execute. It stops and shows you a plan before it writes code. The critique and the five passes propose; they do not edit. The other design skills never edit product code: dx-design-language writes DESIGN.md after you confirm each section, dx-design-git commits your work but pushes only after you say yes, dx-design-setup installs a tool only after you say yes, and dx-design-feedback files an issue only after you approve it.
• You can answer in plain words. "The page feels cluttered" is a valid instruction. The skill translates it into the standard's terms.

Say what you want

Engineering workflow

These commands carry work from a clear issue to reviewed code, then keep the repository gates healthy.

What they change

Unlike the design passes, most engineering skills change your repository or your issue tracker when you ask:

• Issues. dx-create-story, dx-create-task, dx-create-chore, and dx-create-bug create an issue after you confirm its body. dx-create-issue picks the kind and hands over to one of them. dx-split-issue shows you the proposed cut and creates nothing until you confirm it.
• Pull requests. dx-create-pr opens a draft pull request after you confirm its description.
• Code. dx-implement-issue creates a branch and states its plan before any test or code exists. dx-write-tests commits failing tests, and dx-write-implementation commits the code that makes them pass.
• Tooling. dx-lint-setup installs and configures linters and formatters once you confirm its plan. dx-git-hooks-setup installs a hook manager and writes the hooks. dx-update-npm-dependencies updates your manifest and lockfile, then offers to commit, push, and open a pull request. dx-house-style-setup changes a Claude Code settings file, and asks before it writes to the shared .claude/settings.json.
• Documents. dx-create-adr, dx-create-sprint-logs, and dx-create-skill write a new file. dx-trim-doc and dx-trim-leakage edit the document you name.
• Review. dx-code-review changes no file. It posts its findings as comments on the pull request.

GitHub or GitLab

The issue skills (dx-create-issue, dx-create-story, dx-create-task, dx-create-chore, and dx-create-bug), dx-split-issue, and dx-design-feedback need GitHub: they work through the gh command-line tool. Without gh, the issue skills give you the issue as Markdown to file by hand. dx-create-pr and dx-code-review work with both: GitHub pull requests through gh, and GitLab merge requests through glab.

Four shapes of issue

Each shape needs different questions, so each has its own skill. A story is user-facing work described from the perspective of whoever benefits. A task is one discipline's slice of a story or chore, with no persona of its own. A chore keeps the system healthy without changing what a user can observe. A bug is something already built that behaves wrongly.

Reach for dx-create-issue when the shape is not obvious, or when one request mixes several kinds of work. It makes that one decision and hands over. When you already know the shape, call the skill for it directly.

When an issue turns out too big to deliver in one pull request, dx-create-task is not the whole answer: deciding which acceptance criteria belong together is the real work. dx-split-issue proposes that cut, then hands each confirmed slice to dx-create-task. The parent stays open and tracks the slices as sub-issues.

Tests before code

dx-implement-issue writes nothing itself. It reads the issue, plans, and then runs two skills in a fixed order: dx-write-tests, then dx-write-implementation.

The order is what you get out of it. dx-write-tests leaves a committed branch whose tests fail for the reasons the issue states, and dx-write-implementation writes code against those tests. A test written before the code cannot be shaped to fit code that already passes.

Where your repository cannot settle a criterion with a test, dx-write-tests writes none and records the criterion as manual with the reason. You get an honest gap instead of an assertion that passes without checking anything.

Run either skill on its own. dx-write-tests hands you a failing branch and names what continues. dx-write-implementation picks up a branch someone else left, so the two halves need not happen in one sitting or by one person.

The front door

/dx-harness:dx-design is the orchestrator. It asks what you want, one question at a time. If you cannot say, it offers five plain modes: make something new, improve what exists, brainstorm, define your design language, set up or fix your tools. It routes you and hands your answers over, so no skill interviews you twice.

It also answers rule and waiver questions — "does TOK-1 apply here?", "can I waive this, and who approves?" — with citations from the catalogue, then offers the one next step that fits. It never builds.

The builder

/dx-harness:dx-design-execute is the only design skill that edits the product. It runs the loop: intent → diverge → plan approval → implement → design review → rule proposal. You describe the screen in your own words; it comes back with 2–3 genuinely different directions as real HTML pages; you pick one. No code exists until you approve the plan. If you change your mind mid-run, say so — the loop goes back a phase rather than pushing on.

It also builds the findings you accept from the critique and specialist skills.

Specialist skills and subagents

dx-design brings in focused specialists when a request needs more than one kind of design judgement. It gives each specialist the same intent, relevant DESIGN.md decisions, and in-scope catalogue entries. They return their findings to the orchestrator, so you get one coordinated plan rather than a set of disconnected recommendations.

The five specialists below can run in two ways. Call one directly when you already know which dimension needs attention. For a broader improvement, dx-design runs the relevant ones as propose-only subagents. Each can record up to five ranked findings on the surface's design ticket, but none edits the product.

• /dx-harness:dx-design-copy — wording, tone, names, error messages.
• /dx-harness:dx-design-polish — spacing, type, colour, radius, shadow.
• /dx-harness:dx-design-motion — transitions, easing, timing, reduced motion.
• /dx-harness:dx-design-flow — multi-step tasks: steps, waiting states, safe exits, drafts.
• /dx-harness:dx-design-pattern — structure, hierarchy, density, and whether the page uses the right named pattern (list vs cards, master-detail, wizard). It can propose a whole-page rebuild that keeps the same content.

/dx-harness:dx-design-critique is the whole-page specialist for "I do not like this page but I cannot say why." It captures the page, grades it against the catalogue, and returns ranked findings with scores. It also handles re-audits. Like the five specialists, it proposes changes but never builds them.

The orchestrator merges accepted findings into one ranked plan and asks for approval once. dx-design-execute then builds that plan. After implementation, dx-design sends the full result to the separate dx-design-review agent, which checks the original intent, approved plan, DESIGN.md, and relevant catalogue standards. The same reviewer re-checks fixes from new screenshots.

The design language

/dx-harness:dx-design-language defines your product's design language and writes DESIGN.md — the per-product decisions any agent can read. It scans your code first: on a healthy repo it mines the answers and asks you to confirm or correct; on a token-less repo it interviews you. It can ingest Figma and brand documents. It never writes product code.

Behind the scenes

• /dx-harness:dx-design-git is Gitty, a friendly git companion for designers who design in code. It also runs the branch guard: when a build starts on main or behind the remote, it proposes the fix before anything changes.
• /dx-harness:dx-design-feedback files a GitHub issue on the harness repo the moment something about the harness itself confuses you, even mid-task. Confusion is a bug report, not a user error.
• /dx-harness:dx-design-research-brief writes a research plan that aligns a study before a participant is recruited.
• The design reviewer (dx-design-review) is an agent, not a command: after dx-design-execute builds something, a separate agent grades the result against what you asked for, then re-checks each fix. The builder never reviews its own work.

One deliberate stance carried by every skill: unwarranted novelty is flagged as readily as generic output. A custom pattern where a stack component already exists is a finding.