Changelog

arbiter publish --password puts your team board behind a password. Arbiter makes up a strong one and shows it once, so send it with the link, or you choose your own. --no-password takes it off.

arbiter unpublish deletes your team board from arbiter.design, with its pictures and comments. The comments are saved into your project first. Without --yes it only tells you what would go.

arbiter rename "Settings build" "Billing settings" renames a piece of work after the fact. Its decisions, its picture and its comments on the board follow it.

A board holds up to 100 pictures (25 MB). A picture that doesn’t fit is left off and publish tells you, instead of the whole publish failing.

Every team board now says how its owner takes it down, and anyone can ask for a board to be removed with Report or remove this board.

Installing asks once how Arbiter should check in while you work, so the introduction no longer comes back on every review.

The agent writes each decision the way a PM or designer would say it: short, plain words, no code or file names. One that doesn’t is sent back to be rewritten before you ever see it.

The review page in your browser looks like your team board, and sorts newest or oldest first.

On Windows, when PowerShell blocks npx, Arbiter tells you to use npx.cmd instead.

After updating, run npx arbiter update once, so your skill file is on the new version.

When you ask for something one of your rules goes against, the agent asks before building instead of picking a side: follow the rule, or do it your way just this once. Your way is saved as an exception, and the rule stays.

The same happens when a rule disagrees with your design system (DESIGN.md, pattern and component docs, or the shared components). Following the design system is the first option. A rule written as an exception to the design system is followed without asking, and the agent says so.

It also asks when two rules can’t both be true, when other screens don’t follow a rule you just built to, and when a rule needs a component your design system doesn’t have (you get a short plan before it builds one). Every clash reads the same way: the facts, one question, and two or three answers to pick from.

The review page in your browser now flags a change that goes against a rule, with the same choices as the chat: follow the rule, replace it, or keep this one as an exception.

Only real choices go into your review queue: what you asked for, what you corrected, and options the agent actually weighed. Each one says who made the call.

arbiter record --reword D-0003 --to "…" changes a rule’s wording and keeps its number, so everything that points at it still does. arbiter rules D-0003 lists the rule’s exceptions and the clashes waiting on it.

After updating, run npx arbiter update once. It refreshes your skill file and the line Arbiter keeps in CLAUDE.md and AGENTS.md, and leaves the rest of those files alone.

Anyone signed in to your board can press Request change on a screen or a decision. arbiter pull brings it to you as a request, and you answer it in the chat with /arbiter or on the review page: apply it, apply it differently, or decline with a reason. The agent makes what you say yes to, and your answer shows on the board after you publish.

On the board, a request and your answer read like any other conversation. If someone deletes a request before you’ve answered it, it leaves your queue at the next pull.

On the board, your rules are called Design rules, and each shows the day it was made.

Commenters’ email addresses are no longer saved in .arbiter/comments.json, which you commit. Pulling no longer rewrites .arbiter/hosted.json every time, so two machines or two teammates don’t keep conflicting on it.

After updating, run npx arbiter update once, so your skill file (and a publish-on-push workflow, if you have one) is on the new version.

When the agent records a change to a screen that has no picture yet, Arbiter tells it straight away, with the command to take one, while your app is still running.

arbiter publish names any screen that should have a picture and doesn’t, and the review page marks it. Cards that are right as an icon (a font change, an animation, a focus-order fix) are left alone, and so is work that’s only small one-off fixes, since those never appear on the board.

arbiter setup --app http://localhost:3000 saves where your app runs, so the agent knows which address to open for a screenshot instead of guessing.

Every 5 changes waiting, the agent asks in the chat whether you want to review them now. Say no and it asks again at 10. Small one-off fixes don’t count, and if you chose Nothing until I ask, it never asks.

The line after big work reads more plainly: Arbiter saved: Settings is now a tab row with four pages. Type /arbiter to review.

After a sizeable piece of work, the agent names up to three of your rules that shaped it, like Following D-0001 (removing asks first, no undo bar), so you can see the record working. If you chose Nothing until I ask, it follows them without saying so.

When a change waiting for review goes against one of your rules, the review says so and asks which wins: follow the rule, replace it, or keep this one as an exception.

After updating, run npx arbiter update once, so your skill file is on the new version.

The agent takes a picture when the work changed a screen you can point at, not only after big features. A font or colour change has no one screen, so it gets none, and neither do motion or behaviour, which a still can’t show.

The agent writes its screenshot to a file with a headless browser, so it no longer has to ask you for one. When it can’t take one, it says why, once.

arbiter remove takes out a record that was never real: a decision, a screen or a picture. arbiter unlink detaches a decision from the wrong screen and keeps both.

A decision now carries whoever actually made it, taken from git. Before, every decision in a project was signed with whoever first ran arbiter init — that name sits in a committed file, so a whole team inherited one person’s.

Arbiter notices when a project is behind. The skill file in your repo is a copy, and it went stale quietly whenever the package moved on; it now carries the version that wrote it, so the agent can say so in one line. It never updates anything on its own.

npx arbiterdesign@latest update does the whole thing at once: the newest package, a refreshed skill file, and the publish workflow re-pinned. DECISIONS.md, the archive and your settings are left alone. Once you’re on 0.1.3 the shorter npx arbiter update works too, and --check reports without changing anything.

npx arbiter publish --on-push hands the job to GitHub: the board republishes whenever decisions land on your main branch, so it is current without anyone remembering. It sets the repository secret for you when gh is signed in, and prints the one line to paste when it isn’t.

The first time you type /arbiter in a project, it says what Arbiter is, how it works, and the three commands, then asks one question: when to check in.

Your answer is kept. Once per feature, quietly, or every time. Say be quieter later and it changes.

arbiter setup --checkin stores the same answer from the command line and marks the project onboarded.

arbiter publish with nothing after it publishes to arbiter.design. No token to set up, nothing to sign in to.

--to pages publishes to GitHub Pages instead; --to with a URL publishes to an Arbiter you host yourself.

The agent knows how to publish: one command, no questions about where.

If the site is busy, it says so and asks you to try again in an hour, instead of showing an error code.

The command-line tool, the skill for Claude Code and Cursor, and the local review page.

Records the design decisions made during agent-assisted UI work into DECISIONS.md, queues them for a one-minute review, feeds the rules back to the agent, and publishes a board.