# Skills > The 33 commands shipped with dx-harness: design work, issue delivery, review, and repository upkeep. 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](/harness/install). 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 | You want to... | Type | | --- | --- | | Get routed, or you are not sure which skill fits | `/dx-harness:dx-design` | | Build a new screen, or change an existing one | `/dx-harness:dx-design-execute` | | Hear what is wrong with a page before you change it | `/dx-harness:dx-design-critique` | | Fix one dimension: wording, spacing, motion, a multi-step flow, structure | `/dx-harness:dx-design-copy` · `/dx-harness:dx-design-polish` · `/dx-harness:dx-design-motion` · `/dx-harness:dx-design-flow` · `/dx-harness:dx-design-pattern` | | Define your product's design language, write DESIGN.md | `/dx-harness:dx-design-language` | | Ask whether a rule applies, or whether you can waive it | `/dx-harness:dx-design` | | Get help with git in plain words | `/dx-harness:dx-design-git` | | Set up your machine (once) | `/dx-harness:dx-design-setup` | | Tell us the harness itself confused you | `/dx-harness:dx-design-feedback` | ## Engineering workflow These commands carry work from a clear issue to reviewed code, then keep the repository gates healthy. | You want to... | Type | | --- | --- | | File an issue when you are not sure which kind it is | `/dx-harness:dx-create-issue` | | File a user-facing story, the "As a [persona], I want..." shape | `/dx-harness:dx-create-story` | | File one discipline's slice of a story or chore, engineering or design | `/dx-harness:dx-create-task` | | File a chore: maintenance, config, tooling, infrastructure, nothing a user sees | `/dx-harness:dx-create-chore` | | File a bug with reproduction steps and an expected-versus-actual delta | `/dx-harness:dx-create-bug` | | Record an architecture decision as a numbered MADR file in the repository | `/dx-harness:dx-create-adr` | | Cut an issue that turned out too big into task sub-issues | `/dx-harness:dx-split-issue` | | Implement an issue end to end: tests, then code, then its pull request | `/dx-harness:dx-implement-issue` | | Write a failing test for each acceptance criterion, before any code exists | `/dx-harness:dx-write-tests` | | Write the code that satisfies failing tests already on the branch | `/dx-harness:dx-write-implementation` | | Open a pull request, or update one to match new commits | `/dx-harness:dx-create-pr` | | Review a pull request or GitLab merge request across eight angles | `/dx-harness:dx-code-review` | | Configure linting and formatting | `/dx-harness:dx-lint-setup` | | Wire existing checks into pre-commit and pre-push hooks | `/dx-harness:dx-git-hooks-setup` | | Resolve vulnerable npm dependencies with a release cooldown | `/dx-harness:dx-update-npm-dependencies` | | Turn on the bundled house-style output style | `/dx-harness:dx-house-style-setup` | | Record a sprint and hand a workstream over | `/dx-harness:dx-create-sprint-logs` | | Make a document shorter without changing what it does | `/dx-harness:dx-trim-doc` | | Fix prose that reads from an authoring session rather than the repository | `/dx-harness:dx-trim-leakage` | | Write a new skill, or rewrite one to the skill prose standard | `/dx-harness:dx-create-skill` | ### 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.