/mainline

name: mainline
description: "Use for coding-agent work in Git repos that use or may need Mainline, or when users mention Mainline, intents, agent autonomy, agent_authority, max_autonomy, stop lines, allowed_boundary, inspect_or_stop, before_commit/proposed_intent/opened_pr, current-instruction overrides, commit/seal handoff, push/PR review boundaries, merge/release/deploy boundaries, auto-submit/auto-commit/auto-seal behavior, hooks, proposals, gaps, conflicts, committing, pushing, opening PRs, PR descriptions, or setup."

Mainline

This skill is the agent-facing Mainline integration. It should be sufficient even when the repository does not yet have Mainline text in AGENTS.md and when Mainline hooks are not installed.

Mainline records why AI-driven changes happen, connects those intents to code commits, and surfaces semantic conflicts before PR review. Treat it as part of the coding workflow, not as optional documentation.

If the current session already contains a `mainline:context` block injected by Mainline hooks, treat that hook context as already loaded. Do not re-run generic bootstrap context commands just to duplicate it. Run task-specific context commands only when needed.

Stop-Line Quick Matrix

Use this as the first-pass boundary decision; detailed workflows below explain how to execute each boundary.

Interpret the latest user instruction semantically, not by keyword matching.

| Instruction class | Effective boundary | Do not cross without a new explicit request | |---|---|---| | Advice-only / read-only | `assist` | edits, commits, seals, metadata publish, push, or PR | | Finish local work / commit / seal / handoff | `handoff` | code branch push or PR | | Push branch / open or update PR | `review`, capped by team `max_autonomy` | push to `main`, merge, release, deploy, or post-merge cleanup | | Continue next task | keep the current effective boundary | lifecycle advancement unless it is naturally next and permitted | | Merge / release / deploy / package publish / post-merge cleanup | explicit delivery task, not autonomy | ambiguous target or missing repository workflow checks |

Vocabulary guardrails:

• `mainline publish` publishes Mainline intent metadata / actor-log state. It is

distinct from pushing a Git branch, opening a PR, merging, package publishing, deployment, or product release. If the user says "publish" without a clear object, identify the target before acting.

• Git branch push, PR creation, PR merge, and product release/deploy are

separate delivery steps. Do not collapse them into one "publish" action.

• A file overlap is only a signal. It becomes a conflict workflow only after

inspection shows it is real and potentially contradictory.

Language Rule (load-bearing)

Match the user's language in everything you write into Mainline: the goal text on `mainline start`, every `mainline append` turn, the seal `summary.title` / `what` / `why` / `user_goal` / decisions / review_notes, explicit signal command text, and PR description prose. If the user wrote in Chinese, seal in Chinese. English in, English out. Mixed inputs → match the dominant language.

Why this matters: the seal record is the team's long-term memory. A teammate reading `mainline show <id>` later must recognise the work as theirs. Translating a Chinese task into an English seal makes the corpus harder to read for the people whose memory it is.

Pass the user's substantive goal text through verbatim — `mainline start "<goal>"` becomes the headline in `mainline log`. If the latest instruction is only a context-dependent reference rather than a durable description of the work, expand it into a short, human-readable goal in the user's language. Preserve the reference in a turn or seal reference instead of making it the headline. Code identifiers, command names, file paths, and CLI snippets stay in their original form regardless of conversation language.

Trigger Policy

Use this skill for any task in a Git repository when one of these is true:

• The repository has `.mainline/config.toml`, `.ml-cache/`, a Mainline block in

AGENTS.md, Mainline refs, or existing Mainline commands in project docs.

• The user mentions Mainline, intents, conflict checks, agent guidance, hooks,

sealing, proposals, coverage, gaps, uncovered commits, agent autonomy, `agent_authority`, `max_autonomy`, stop lines, `allowed_boundary`, `inspect_or_stop`, current-instruction overrides, handoff / review / delivery boundaries, or auto-submit / auto-commit / auto-seal behavior.

• You are about to edit code, refactor, delete code, change tests or CI, commit,

push, create a PR, review a PR, or investigate whether prior work already made a decision in a repository known to use Mainline.

If the skill triggers because the repository appears to use Mainline, run the Mainline checks before broad code search or edits. If the repository does not appear to use Mainline and the user did not ask to set it up, do not initialize Mainline without user confirmation.

Setup Responsibility

Do not assume the human has already installed or initialized Mainline. If the task needs Mainline and `mainline` is missing, install or help install it before continuing.

First check:

command -v mainline
mainline status --json

If the CLI is missing, prefer the public install script on macOS/Linux:

curl -fsSL https://raw.githubusercontent.com/mainline-org/mainline/main/install.sh | bash

If the user prefers Go's native installer or the install script is unavailable, use Go 1.22+:

go install github.com/mainline-org/mainline@latest

Use `@main` only when the user explicitly wants the current unreleased development version:

go install github.com/mainline-org/mainline@main

After install, ensure the install directory (commonly `~/.local/bin` for the script or `~/go/bin` for `go install`) is on PATH. Re-run `mainline status --json`.

If the CLI exists but the repository is