← All docs

Getting started

Three commands take you from nothing to a working design harness: init scaffolds it, scan reads your code, and validate checks for drift. Here is what each one does.

Before you start

Harnd reads the code your project already has and builds a design harness from it: your design tokens, your component specs, and a set of quality gates that flag drift. You do not need a design tool, and you do not need an account to try it.

The npm package is @harnd/cli, not harnd. Use npx @harnd/cli <command> to run it without installing anything first.

Only two commands talk to a server: link and sync. Everything below — init, scan, and validate — runs entirely on your machine, on your code, with no account.

1. Scaffold your harness with init

init scaffolds .harnd/ at the root of your repository. It is safe to run more than once — running it again on an existing harness does nothing unless you pass --force.

npx @harnd/cli init

This creates .harnd/config.yaml with a generated harness ID (hrn_…) that never changes afterward, and installs a default set of quality gates (raw-color and raw-spacing checks, among others) unless you skip them. Nothing outside .harnd/ is touched.

  • --name <name> — Harness name (default: the repository directory name)
  • --force — Recreate even if .harnd/config.yaml exists (the hrn_ id is preserved)
  • --no-gates — Skip the default gates
  • --lang <en|ja> — Language of generated files, not of this CLI (default: en). The CLI's own output is always English, regardless of this setting.
  • -y, --yes — Non-interactive (accept defaults)
  • --from <path> — Carry your gates and token meanings over from another harness (conventions only — components and tokens are read from this project)

2. Extract your tokens and components with scan

scan reads your codebase and extracts tokens, components, and how they are used, writing the results into .harnd/. This is the step that turns an empty harness into one that actually describes your project.

npx @harnd/cli scan

By default, scan looks in directories whose purpose is unambiguous (components/, ui/, route-colocated files under app/, and similar conventions). If your project uses a different layout — a monorepo package, a feature-folder structure — set scan.components in config.yaml explicitly (see the Configuration reference).

  • --dry-run — Show a summary without writing anything

3. Check for drift with validate

validate runs your gates against your code and reports drift — for example, a raw hex color where a token was expected. By default it checks your whole working tree.

npx @harnd/cli validate
  • --diff — Check only lines added in git diff (default: the whole working tree)
  • --staged — Use git diff --cached as the --diff target
  • --hook — For harnd hook install: report errors on stderr and exit 2 so your agent has to fix them; warnings go to stdout without stopping it

You will not run --hook by hand day to day — it is what harnd hook install wires up for you. See Putting it where it runs.

What's next

Once init, scan, and validate run cleanly, decide where validate should run automatically — see Putting it where it runs — and check the Configuration reference for every key in .harnd/config.yaml.