⚓ firstmate field guide
Using firstmate

Delivery modes & merge authority

How each project ships (no-mistakes, direct-PR, local-only, prod-only), what +yolo does and doesn't allow, branch prefixes, and the Gerrit forge binding.

Every project has a delivery posture recorded in data/projects.md. It answers two separate questions:

  1. How does work reach the project? That is the mode.
  2. Who approves landing it? That is the merge authority: you by default, or the first mate under +yolo.

The registry line#

bin/fm-project-mode.sh parses lines of this shape:

- <name> [<mode> +yolo branch=<prefix> forge=gerrit] - <description> (added <date>)
bin/fm-project-mode.sh xyz                  # → "no-mistakes off"
bin/fm-project-mode.sh --branch-prefix xyz  # → "fm/"
bin/fm-project-mode.sh --forge xyz          # → "none" | "gerrit"
bin/fm-project-mode.sh --raw xyz            # keeps "no-mistakes-prod-only" uncollapsed

You rarely edit this by hand. Say "set xyz to direct-PR" or "give xyz yolo", and the first mate updates it through the project-management skill.

Modes#

no-mistakes — the rigorous default#

The worker commits on its ship branch and pushes to the local no-mistakes gate. It then drives the nine-step pipeline (intent → rebase → review → test → document → lint → push → pr → ci) through to a green PR. It answers gates but never passes --yes. It reports done: PR <url> checks green. See no-mistakes.

This is the safe fallback: an unregistered project resolves to no-mistakes with yolo off, and the gap is surfaced to you.

direct-PR — fast path#

The worker pushes its branch and opens a non-draft PR itself (via gh-axi), with no pipeline, and reports done: PR <url>. A deliberately held draft reports paused: instead of done:.

local-only — no remote#

The worker stops with a clean ship branch and reports done: ready in branch <branch>. After approval, the first mate runs bin/fm-merge-local.sh <id>. That is a guarded fast-forward of the project's local default branch, and the only git write the first mate itself makes inside projects/. It refuses divergence and tells you to have the crewmate rebase.

no-mistakes-prod-only — per-task choice#

This is a registry classification. The project-management skill makes it the default suggestion for a new remote-backed project. At intake the first mate classifies each task by its surface:

  • Internal-only tooling, automation, contributor process or release work ships direct-PR.
  • Product-facing, mixed or uncertain work ships no-mistakes.

"Never infer internal-only from file location or project name."

Kun's rule of thumb for when you need no-mistakes

you can ask yourself 'would i ask another human to do code review for this change' and if the answer is no, then you probably don't need no-mistakes. — @kunchenguid, 2026-09-22

+yolo — standing merge autonomy#

+yolo is orthogonal to mode. It changes only who approves landing.

yolo off (default) yolo on
Green, in-scope PR waits for your word first mate merges it
Local-only landing waits for your word first mate lands it
Red PR or unreported required check never merged never merged
Destructive / irreversible / security-sensitive escalates still escalates
Scope — "exercised only within the captain's original request, and it never quietly widens"

Only your current explicit instruction can merge past a red required check, and only when it names the check (fm-pr-merge.sh --allow-red <check>).

Away mode is a separate grant. While you are /afk, a PR green at its live head may merge under away authority. Destructive actions still cannot be pre-authorized. See Daily commands.

branch=<prefix>#

This overrides the default fm/ prefix for ship branches in that project, for example branch=kun/. The brief records a Ship branch: line, and fm-spawn.sh cross-checks it against its arguments to catch drift.

forge=gerrit#

This binds the project to Gerrit instead of GitHub PRs:

  • The worker publishes a change with gerrit-axi publish --squash --json and reports done: PR <change url> published for review.
  • fm-pr-merge.sh refuses Gerrit outright. Submitting would require faking an attributed human Code-Review+2. A human reviewer submits the change server-side.
  • forge=gerrit with local-only is rejected, because local-only publishes nothing.

GitLab merge requests work through the ordinary PR path (see docs/gitlab-merge-watch.md).

Precedence, in one list#

  1. Your current, explicit, concrete instruction ("ship this one direct-PR"). It wins, "exactly as stated and no further".
  2. The project's registry entry, which is the standing posture.
  3. The safe default: no-mistakes, yolo off.

Ambiguous scope or a conflict still gets one concise clarifying question before action.

Unofficial guide built 2026-09-26 from kunchenguid/firstmate, the AXI repos, and Kun Chen's public posts. The repo moves daily; when this guide and the repo disagree, the repo wins.