# dx-harness

> Make the quality bar independent of staffing. Shared product intent, checkable
> standards, and a repeatable workflow help people and agents ship coherent interfaces.
> Every page below is also available as Markdown by
> appending `.md` to its path.

## About

- The dx-harness design standard (v0.1 draft).
- Litmus for the catalogue: if you can't check it, it's guidance and lives in a standards page's prose, not in the catalogue.
- Tiers: L0 non-negotiable (no waiver) · L1 mandatory (documented waiver) · L2 recommended (inline rationale).
- Waiver syntax: `dx-waive <ID> reason="<specific reason>"`.
- Product context: implemented stack and standing deviations belong in the product repo's DESIGN.md. Typefaces and token values resolve from the product's DESIGN.md, then the codebase's theme tokens, then shadcn/Tailwind defaults. Components come from Base UI, functional colours from Radix Colors.

## Machine readers

- [Full Markdown corpus](/llms-full.txt): optional single-response corpus generated from every Markdown twin.

## Start here

- [dx-harness home](/index.md)
- [Overview](/overview.md)
- [A note from the builders](/note.md)

## Standards

- [Standards catalogue](/standards/catalog.md): overview, readable standards + embedded YAML
- [Standards catalogue (YAML)](/standards/catalog.yaml): machine source
- [Writing](/standards/writing.md): Not written to be read. Written to be acted on.
- [Voice and tone](/standards/voice-tone.md): The voice reflects who you are. When you speak consistently, your product feels familiar and trustworthy.
- [Grammar and mechanics](/standards/grammar-mechanics.md): The consistent small choices in capitalisation, numbers, and punctuation that keep copy scannable in one pass.
- [Components and text patterns](/standards/text-patterns.md): The repeatable shapes of microcopy (errors, empty states, loading, confirmations) so each surface reads the same way every time.
- [Naming](/standards/naming.md): A name that requires explanation has already failed.
- [Colour](/standards/colour.md): Colour tells people which product they're in and what needs their attention. Each product keeps its own primary; neutrals and status colours stay shared.
- [Typography](/standards/typography.md): Type sets the hierarchy a tired reader scans first: what's a heading, what's next, what can wait. Your DESIGN.md names the fonts, their roles, and the scale.
- [Spacing and radius](/standards/spacing-radius.md): Consistent spacing and corners are what make a screen feel calm instead of busy. One shared scale, so nothing is arbitrary.
- [Tokens](/standards/tokens.md): Every token this site uses, in one place: colour, type, spacing, radius, and motion. A worked example of the token set a DESIGN.md points to.
- [Iconography](/standards/iconography.md): Icons help people spot an action faster than words alone. One consistent set for the UI, a warmer hand-drawn style for brand moments.
- [Motion](/standards/motion.md): Motion is feedback, not decoration: four durations, two easings, and one rule — nothing moves that doesn't mean something.
- [Interaction](/standards/interaction.md): How a screen responds decides whether a person feels in control or ambushed. Show the core path first; make every action easy to undo.
- [Web interface](/standards/web-interface.md): The craft floor for anything you ship in a browser: the polish that separates merely working from genuinely feeling right.
- [Data visualisation](/standards/data-viz.md): People read charts between other tasks, so clarity beats density. Make the one number that matters impossible to miss.
- [Illustration](/standards/illustration.md): Illustration is where the product feels human instead of corporate. One warm, hand-drawn style — and shipping none beats shipping off-brand.

## Design in code

- [Design in code overview](/getting-started.md): Make your first UI change in a real repo, from setup to a merged pull request.
- [Introducing Git](/getting-started/git-basics.md): The handful of Git words you'll hear, and what each one means.
- [Step 0: Prep guardrails](/getting-started/guardrails.md): Work with your engineer to make sure the repo has guardrails before you build.
- [Step 1: Set up](/getting-started/set-up.md): Get your AI tools and the product repo onto your computer. You do this once, when you first join a repo.
- [Step 2: Plan](/getting-started/plan.md): Start from the problem, pick your mode, and decide how much to plan.
- [Step 3: Build](/getting-started/build.md): The build loop, step by step, and how to keep an eye on the basics.
- [Step 4: Ship](/getting-started/ship.md): Commit, open a pull request, get it reviewed, and merge.
- [Help and prompts](/getting-started/help.md): What to do when something breaks, where to go next, and prompts you can copy.

## Harness

- [Harness overview](/harness.md): The skills and tools that apply all of it, fast, with or without a designer on the team.
- [Quick start](/harness/install.md): Install the harness, check it works, and set up the tools it uses.
- [The loop](/harness/loop.md): One orchestrator, focused specialists, one approved plan, and an independent design review.
- [Skills](/harness/skills.md): The 33 commands shipped with dx-harness: design work, issue delivery, review, and repository upkeep.
- [Designer on-ramp](/harness/on-ramp.md): Four stages, from asking questions to orchestrating full runs. Skipping stages is how people get stuck.
- [Tools](/harness/tools.md): The runnable tools that let you produce on-brand work without re-reading the rules — generators and checks, not docs about the brand.
- [Research brief](/harness/research-brief.md): Turn a rough research ask into a scoped brief before you talk to a single user.