One-prompt install

What this is

You paste one prompt into any capable coding agent. The agent installs M8Shift, configures a shift, and launches its lanes. You never type a command line — you answer questions.

The pieces have always existed: install.sh, install.ps1, init, listener start, providers.json. What this adds is the conductor — an agent that asks in order, checks the ground before it writes, and invents no path.

🟣 one paste → a running shift

Before you start

An agent that can run shell commands in a directory you choose, plus Python 3 on the machine. git is recommended but not required — the installer has Python fallbacks.

Native Windows

M8Shift assumes a POSIX shell. On Windows you need WSL (preferred) or Git Bash. The conductor checks this before writing anything and stops with the remedy if neither is present. It does not start an install that would break halfway.

The prompt

Paste this to your agent, as is.

Install and configure M8Shift on this machine, acting as the onboarding conductor.

Read https://m8shift.ai/guide/onboarding-conductor and follow it exactly, in order,
without improvising.

It governs you with three rules: no guessed path, no silent default, no unverified
success. Ask me every location instead of assuming one. Give each question a
recommended default and tell me what my choice engages, not only what it does. Report
an absent prerequisite before your first write, never as a failure halfway through.
Report a launched lane by what you verified on disk, never by what you started.

If your agent cannot fetch a URL, open The onboarding conductor and paste the page to it. The canonical copy is docs/en/onboarding.md in the repository, where a hermetic test extracts its command sequence and executes it, so the instructions cannot drift from what is tested.

The probe is not on the public mirror yet

Step 0 of the conductor runs scripts/onboard-probe.py, and the public GitHub mirror is still on the v4.2.0 release from 2026-08-23 — one day before the conductor and its probe shipped. Until the mirror is refreshed, an agent that cannot reach the private repository establishes the same prerequisites by hand, and the conductor tells it to say which instrument it used. The installer itself (install.sh, install.ps1) is on the mirror and works.

What it will ask you

Five questions, in this order.

1. Where does this instance live? The kit installs per instance, so the install directory and the instance directory are the same one. Recommended: a directory named after the instance, beside the project it coordinates. Never a temporary or generated tree — a lane pinned to a throwaway worktree dies with it.
2. Will any agent run headless? Recommended yes. This installs the reference lane runner alongside the kit, manifest-verified like the rest. Answering no keeps the kit smaller; the runner can be added later.
3. Configure a shift now, or stop after installing? Stopping is clean and loses nothing. You get a verified kit and no instance, and the agent tells you exactly what remains.
4. What is the instance named? This name appears in every status surface and notification.
5. Which agents, and in which mode? For each agent, interactive or headless with a runner. Headless means a resident process on your machine that polls the relay and spends that provider's budget on its turns. Interactive engages nothing resident.

What it will not do

• Guess a path. Every location is asked. A guessed path is paid for later.
• Start an install it knows will break. The read-only probe runs first and gates everything after it.
• Claim a lane is running because it started one. It reads the lane back and reports the evidence. A status command that exits zero on a dead lane is not proof, and the conductor is told so explicitly.
• Create a roster before you chose one. The installer runs with initialization disabled, so no default-roster instance appears behind your back.

Staying current afterwards

An instance created months ago runs a version nobody checked. The same probe answers that question on demand:

python3 -B scripts/onboard-probe.py --update-check --target "<INSTANCE_KIT_DIR>" --source "<RELEASE_SOURCE_DIR>"

It compares the installed core's bytes against the digest the source manifest pins. Equal version strings alone never certify currency: a stale or tampered core carrying the right version string passes a string comparison and fails this one. When it reports drift, the upgrade runs only on your explicit yes, and it never reaches for the network by itself.

Where to go next

• Quickstart if you would rather type the commands yourself.
• Headless runner for what a resident lane actually does.
• Two-agent relay for the workflow once the shift is up.