onboarding

name	onboarding
description	First skill for new contributors, fresh clones, and setup questions in the mainline repo. Separates developing mainline from using mq on another repo, verifies the local baseline, explains canonical-root trust, and clarifies which commands should or should not work in this source checkout.

mainline onboarding

Use this skill when someone is new to this repository and needs a reliable first pass through setup, baseline checks, and terminology.

Use this before the worktree skill when the user is still figuring out what this repo is, how it is installed, or which commands are supposed to work in this checkout.

Goal

Separate these two jobs immediately:

• developing the mainline codebase in this repo
• using mainline to manage some other target repo

Do not let the user conflate them.

Read first

Read these before making claims:

1. README.md
2. docs/install.md
3. docs/FLOWS.md
4. SPEC.md
5. PLAN.md
6. AGENTS.md
7. CONTRIBUTING.md

Contributor baseline

From the repo root, run:

make build
go test ./...
./bin/mq --help
./bin/mq repo show --repo . --json
./bin/mq repo root --repo . --json
./bin/mq status --repo . --json

Interpretation:

• make build should succeed
• go test ./... should succeed; test helpers intentionally neutralize global Git signing config for temporary repos
• mq repo root --repo . --json is the source of truth for whether the current checkout is the canonical protected root checkout
• mq status --repo . --json may fail in a fresh source clone until this repo has been explicitly initialized as a managed queue target on this machine

Canonical-root explanation

Explain this concretely:

• the repo root checkout on main is the canonical protected root checkout
• topic worktrees are where feature work happens
• if the current checkout is not canonical, contributors should say so plainly
• if mq repo root --repo . --json says trustworthy: false, explain the recommended action rather than pretending the checkout is fine

Output expectations

At the end of onboarding, summarize:

• whether the user is developing mainline or using it on another repo
• whether the current checkout is canonical and trustworthy
• whether the local build/test baseline succeeded
• which commands are expected to work in this checkout right now
• the next step for a contributor versus the next step for an operator