Getting started

This chapter installs Jig, sets up a project to use it, and carries one page through the design loop once, start to finish, in a new project or one you already have, on any of 6 agents. The 2 paths differ from Set the project up onward; choose yours below and this chapter follows it.

Before you start

Choose your path, a new project or one you already have, and your agent. The rest of this chapter shows only the case that matches both: the commands to run, what each one asks, and what it leaves behind. Open either disclosure to see the current choice and pick another; the page updates in place, with no reload and no new address.

Install

Install puts the Jig skill where Claude Code reads it, along with the rules the skill checks your work against. Paste this line for Claude Code and let it run; nothing else in your project changes.

Install puts the Jig skill where Codex reads it, along with the rules the skill checks your work against. Paste this line for Codex and let it run; nothing else in your project changes.

Install puts the Jig skill where Cursor reads it, along with the rules the skill checks your work against. Paste this line for Cursor and let it run; nothing else in your project changes.

Install puts the Jig skill where opencode reads it, along with the rules the skill checks your work against. Paste this line for opencode and let it run; nothing else in your project changes.

Install puts the Jig skill where Gemini CLI reads it, along with the rules the skill checks your work against. Paste this line for Gemini CLI and let it run; nothing else in your project changes.

Install puts the Jig skill where your agent reads it, along with the rules the skill checks your work against. Paste this line for your agent and let it run; nothing else in your project changes.

npx jig-ui@0.25.0 install --agent claude

npx jig-ui@0.25.0 install --agent codex

npx jig-ui@0.25.0 install --agent cursor

npx jig-ui@0.25.0 install --agent opencode

npx jig-ui@0.25.0 install --agent gemini

npx jig-ui@0.25.0 install --agent generic

Run interactively, Claude Code also asks whether to add a Stop hook, which holds the agent at the end of a step until its work is complete. It is off unless you say yes.

Codex’s own command installs globally only: at the project scope this chapter uses, install adds no slash command file for it, so its steps below are given in plain language instead.

Install reports exactly where the skill and its rules land for this agent.

Add --scope global to install once for every project instead of just this one: the same command, with no separate line to copy.

Set the project up

init reads your project and writes the token layer everything else in Jig checks against. It has to run before anything is built.

It also asks when this project’s pages are critiqued: after every build, left for ship, or decided page by page. Page by page is the default: it writes nothing and leaves each page’s own spec to ask instead. In a terminal, init asks you this itself. Through an agent, your agent asks first and writes the answer into jig.config.json before running init at all. Nobody is there to answer when a command runs non-interactively, with --yes or in continuous integration (CI): nothing is asked, so the default stands.

A new project

There is no CSS yet for init to read, so it says so rather than guessing, and prints the one line to add once you have a stylesheet:

npx jig-ui@0.25.0 init

Detected: unknown
Token layer: jig/ — no stylesheet found to follow, so the project root.
Could not find a single unambiguous stylesheet to wire the import into.
Add this near the top of your global stylesheet:
  @import "./jig/theme.css";

The brand colour resolves to the unbranded near-black default until you set one.

A project I already have

Look before you write anything: check --all reads the project and writes nothing at all, so you see where you stand before init changes anything.

npx jig-ui@0.25.0 check --all

What comes back below is a small example project’s own report, one with its own tokens already and not yours, shown here for the shape of it:

✗ H-47   Hard-coded colour `#fff` past the token layer      src/app.css:6
⚠ H-119  3 sibling article.card elements are a repeated set …
1 error, 1 warning · 8 files, 5 with styles

Then init, run plain, without --yes, so you see what it asks rather than only its result. It detects the CSS system, derives a brand colour from what is already there, validates it against the contrast floor, and writes the token layer beside the stylesheet it wires, adding one import line where it finds a single unambiguous entry point, or printing the line to add by hand where it cannot. Accepting every derived default as init offers it reaches the same result --yes would reach without asking.

npx jig-ui@0.25.0 init

Nothing written here restyles the project by itself. A declaration nothing references changes no pixel, and every file init writes is checksummed, so editing one by hand stays safe from a later update.

Ask your agent instead: /jig init runs the same command, then states the mode it chose and what it wired.

/jig init

Ask your agent, in your own words, to run Jig’s init step: the skill still loads, so plain words work.

Check where you stand

check is the half of a review a machine can decide. It reads the project and reports; judging what it cannot decide is the rest of this chapter.

npx jig-ui@0.25.0 check --all

Ask your agent instead: /jig check runs the same command, then applies the 120 judgment rules and reports both halves.

/jig check

Ask your agent, in your own words, to run Jig’s check --all step: the skill still loads, so plain words work.

The same example project, checked again after 2 hand edits: adding the import line init printed to its stylesheet, and changing one hard-coded colour to a token it provides, var(--color-on-brand).

⚠ H-119  3 sibling article.card elements are a repeated set …
0 errors, 1 warning

The error is gone because both edits are in place, not from init alone; the remaining warning is the same judgment call as before.

On a project this fresh, the report is typically brief: nothing has been styled yet, so there is little for a rule to find. The report that matters is the one run against a real page, after Build a page, below.

Every run ends with one line, JIG_CHECK:, naming the corpus version, the project’s own mode, whether the mechanical rules passed and how many warnings they found, whether judgment ran, and how many files it looked at. This first run always reads judgment=not-run: nothing here has rendered a page yet, which is what Build a page, below, is for.

Build a page

One page, carried through the design loop once: choose any page in your own project.

1.
decide: once per project. Interviews you for the project-wide decisions the rest of the loop checks a page against, and writes them down with a reason each.
```
/jig decide
```
Ask your agent, in your own words, to run Jig’s decide step: the skill still loads, so plain words work.

The loop, in full

2.
spec: for the one page or feature being built. Asks what it is for and what the smallest useful version of it is, then writes it to .jig/specs/<page>.spec.md for you to confirm. Before it asks, a reader who did not write it checks it, and you confirm by the sheet it gives you. The loop has the full list of what to check. Its last question is when this page is critiqued.
```
/jig spec <page>
```
Ask your agent to spec the page: say what it is, in your own words.
3.
mockup: a grayscale drawing of the confirmed spec, at every screen size. Asks how you want it drawn: HTML, Figma or Google Stitch. Leaves the drawing for you to review before any code is written. Approved against the spec, in your own words, or skipped. A skipped mockup means nothing waits on a drawing.
```
/jig mockup
```
Ask your agent for a mockup, and say how you want it drawn: HTML, Figma or Google Stitch.
4.
make: the real page, built from the confirmed spec and the approved drawing, with any deviation from the spec recorded back into it.
```
/jig make
```
Ask your agent to make the page from the confirmed spec and mockup.
5.
critique: what was built, scrutinised against the rules and the spec. Writes its verdicts to a file, by rule id, for jig verdicts to check against a render of the page. This first critique can run now, or wait until you ship. The loop says what ship then makes non-optional.
```
/jig critique
```
Ask your agent to critique what was built.

A page that does not exist yet

2.
spec: for the one page or feature being built. Asks what it is for and what the smallest useful version of it is, then writes it to .jig/specs/<page>.spec.md for you to confirm. Before it asks, a reader who did not write it checks it, and you confirm by the sheet it gives you. The loop has the full list of what to check. Its last question is when this page is critiqued.
```
/jig spec <page>
```
Ask your agent to spec the page: say what it is, in your own words.
3.
mockup: a grayscale drawing of the confirmed spec, at every screen size. Asks how you want it drawn: HTML, Figma or Google Stitch. Leaves the drawing for you to review before any code is written. Approved against the spec, in your own words, or skipped. A skipped mockup means nothing waits on a drawing.
```
/jig mockup
```
Ask your agent for a mockup, and say how you want it drawn: HTML, Figma or Google Stitch.
4.
make: the real page, built from the confirmed spec and the approved drawing, with any deviation from the spec recorded back into it.
```
/jig make
```
Ask your agent to make the page from the confirmed spec and mockup.
5.
critique: what was built, scrutinised against the rules and the spec. Writes its verdicts to a file, by rule id, for jig verdicts to check against a render of the page. This first critique can run now, or wait until you ship. The loop says what ship then makes non-optional.
```
/jig critique
```
Ask your agent to critique what was built.

A page you already have

No mockup for this case: spec goes straight to critique, then make fixes what critique finds.

2.
spec: written from the page as built, not designed from nothing. Your agent reads what is there and describes it (regions, hierarchy, navigation at each size), then writes it to .jig/specs/<page>.spec.md for you to confirm or correct. It is a description, not a redesign. Before it asks, a reader who did not write it checks it, and you confirm by the sheet it gives you. The loop has the full list of what to check. Its last question is when this page is critiqued.
```
/jig spec <page>
```
Ask your agent to spec the page as it already stands: a description of what is there, not a redesign.
3.
critique: has what it needs once the spec is confirmed: the rules, the spec, and your decisions. Renders the page, measures it, and writes its verdicts to a file, by rule id, for jig verdicts to check. This first critique can run now, or wait until you ship. The loop says what ship then makes non-optional.
```
/jig critique
```
Ask your agent to critique the page against its confirmed spec.
4.
make: fixes what the critique found, and the page is updated. Critique runs again until it is clean or you accept what is left.
```
/jig make
```
Ask your agent to fix what the critique found.

The chapter closes once one of these has run for real, on your own page: Jig installed, the project set up, a first check read, and one page carried once through its own path’s order.