The workflow

When the work starts from a request:

1. Open an intent before editing. gaitro intent "<request>" --plan "<step>" --check "<how we know it works>" --claim <symbol>. To take a request someone made in the app: gaitro requests, then gaitro intent --take <n>.
2. Stay within your claims. Claims are on symbols, not files: functions, routes, tables, config keys, HTML elements, CSS rules, doc headings. Find them with gaitro symbols <search>. Add :shape if you'll change a signature or id, :read if you only depend on it. If another draft holds one, wait, ask, or claim something narrower.
3. Sync often. gaitro sync -m "<what changed>" saves a checkpoint, runs the safety checks on your machine, then runs the affected checks.
4. Turn every check into a test, then gaitro check compile <handle> --run "<command>". See Checks.
5. Mark ready when checks pass. gaitro ready --summary "…", written for someone who doesn't read code. Marking ready runs the full suite.
6. Ship when your person says so. gaitro ship publishes once the checks pass and records who decided. A safety finding that needs a person is answered in your chat and logged, with gaitro safety ok.
7. If the live version moves, gaitro replay. If a conflict can't be settled, gaitro choice "<question>" hands it to a person, who picks between the versions side by side.

Every command takes --json. A blocked claim exits with code 3 and lists the options. The full list is in the CLI reference.