mainline

Mainline

このスキルは、エージェント向けの Mainline 統合機能です。リポジトリの AGENTS.md にまだ Mainline に関する記述がなく、Mainline フックがインストールされていない場合でも、これだけで十分に利用できます。

Mainline は、AI 主導の変更が行われる理由を記録し、その意図をコードコミットに結び付け、PR レビュー前に意味上の競合を明らかにします。任意のドキュメントではなく、コーディングワークフローの一部として扱ってください。

現在のセッションに、Mainline フックが挿入した mainline:context ブロックがすでに含まれている場合、そのフックのコンテキストは読み込み済みとして扱ってください。重複させるだけのために、汎用のブートストラップコンテキストコマンドを再実行しないでください。タスク固有のコンテキストコマンドは、必要な場合にのみ実行してください。

Stop-Line のクイックマトリックス

各境界の詳細な実行方法は以下のワークフローで説明します。まずはこのマトリックスを使って、境界を判断してください。

最新のユーザー指示は、キーワードの照合ではなく、意味に基づいて解釈してください。

指示の種類	有効な境界	新たな明示的な依頼なしに越えてはならない範囲
アドバイスのみ／読み取り専用	assist	編集、コミット、シール、メタデータの公開、プッシュ、PR
ローカル作業の完了／コミット／シール／引き継ぎ	handoff	コードブランチのプッシュ、PR
ブランチのプッシュ／PR の作成または更新	チームの max_autonomy を上限とする review	main へのプッシュ、マージ、リリース、デプロイ、マージ後のクリーンアップ
次のタスクを続行	現在の有効な境界を維持	自然な次のステップであり、許可されている場合を除き、ライフサイクルを先に進めない
マージ／リリース／デプロイ／パッケージの公開／マージ後のクリーンアップ	自律性ではなく、明示的なデリバリータスク	対象が曖昧、またはリポジトリのワークフローチェックが不足している場合

用語に関するガードレール：

• mainline publish は、Mainline の意図メタデータ／アクターログの状態を公開します。Git ブランチのプッシュ、PR の作成、マージ、パッケージの公開、デプロイ、製品リリースとは別のものです。ユーザーが対象を明確にせず「公開」と言った場合は、実行前に対象を特定してください。
• Git ブランチのプッシュ、PR の作成、PR のマージ、製品のリリース／デプロイは、それぞれ別のデリバリーステップです。これらをひとまとめにして「公開」という操作にしないでください。
• ファイルの重複はあくまで兆候です。調査によって実際に矛盾する可能性があると確認された場合にのみ、競合ワークフローに進んでください。

言語ルール（重要）

Mainline に書き込むすべての内容では、ユーザーの言語に合わせてください。対象には、mainline start の目標文、mainline append の各ターン、シールの summary.title／what／why／user_goal／decisions／review_notes、明示的なシグナルコマンドのテキスト、PR の説明文が含まれます。 ユーザーが中国語で書いた場合は、中国語でシールしてください。英語で入力されたら、英語で出力してください。言語が混在している場合は、最も多く使われている言語に合わせてください。

これが重要な理由：シールの記録は、チームの長期記憶になります。後日、チームメイトが mainline show <id> を読んだとき、自分たちの作業だと認識できなければなりません。中国語のタスクを英語のシールに翻訳すると、その記録を利用する人にとって、コーパスが読みづらくなります。

ユーザーの具体的な目標文は、そのまま引き継いでください。mainline start "<goal>" は、mainline log の見出しになります。最新の指示が、作業を長期的に説明できる内容ではなく、コンテキスト依存の参照だけである場合は、ユーザーの言語で短く、分かりやすい目標に展開してください。参照の内容は、見出しにするのではなく、ターンまたはシール内の参照として保持してください。会話の言語にかかわらず、コード識別子、コマンド名、ファイルパス、CLI のスニペットは元の形式のままにしてください。

トリガーポリシー

Git リポジトリでのタスクでは、次のいずれかに該当する場合、このスキルを使用してください。

• リポジトリに .mainline/config.toml、.ml-cache/、AGENTS.md 内の Mainline ブロック、Mainline の参照、またはプロジェクトドキュメント内の既存の Mainline コマンドがある。
• ユーザーが Mainline、インテント、競合チェック、エージェント向けガイダンス、フック、シーリング、提案、カバレッジ、ギャップ、未カバーのコミット、エージェントの自律性、agent_authority、max_autonomy、停止ライン、allowed_boundary、inspect_or_stop、現在の指示による上書き、引き継ぎ／レビュー／デリバリーの境界、または自動送信／自動コミット／自動シールの動作に言及している。
• Mainline を使用していると判明しているリポジトリで、コードの編集、リファクタリング、コードの削除、テストまたは CI の変更、コミット、プッシュ、PR の作成、PR のレビュー、または過去の作業ですでに決定済みかどうかの調査を行う予定である。

リポジトリで Mainline が使用されていると思われるためにこのスキルが適用される場合は、広範なコード検索や編集の前に Mainline のチェックを実行してください。リポジトリで Mainline が使用されていないと思われ、ユーザーからセットアップを依頼されていない場合は、ユーザーの確認なしに Mainline を初期化しないでください。

セットアップの責任

人間がすでに Mainline をインストールまたは初期化していると決めつけないでください。タスクで Mainline が必要なのに mainline が見つからない場合は、続行する前にインストールするか、インストールを支援してください。

まず、次を確認してください。

command -v mainline
mainline status --json

CLI が見つからない場合は、macOS/Linux では公開インストールスクリプトを優先してください。

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

ユーザーが Go のネイティブインストーラーを希望する場合、またはインストールスクリプトが利用できない場合は、Go 1.22 以降を使用してください。

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

ユーザーが現在の未リリースの開発バージョンを明示的に希望する場合に限り、@main を使用してください。

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

インストール後、インストール先ディレクトリ（スクリプトの場合は一般的に ~/.local/bin、go install の場合は ~/go/bin）が PATH に含まれていることを確認してください。mainline status --json を再実行してください。

CLI は存在するがリポジトリが初期化されておらず、ユーザーから Mainline のセットアップを依頼されている場合は、初期化してください。mainline init はデフォルトの Mainline スキルとリポジトリローカルのフック連携をインストールします。新しいフック設定ファイルは、リポジトリですでに追跡されている場合を除き、クローンローカルの .git/info/exclude を使って管理されます。ユーザーからリポジトリレベルのポリシーを明示的に依頼されない限り、AGENTS.md には書き込みません。

mainline init --actor-name "<name>"

<name> は、ユーザーが明示的に指定した名前、既存の Git ID、または安定したローカルのアクター名から選んでください。狭い範囲のコード変更だけを依頼されているのに、初期化によって共有リポジトリのガイダンスや Git の refspec が変更される場合は、初期化する前に確認してください。

フック

フックは動的なコンテキストを提供し、トリガー率を高めますが、信頼できる情報源ではありません。スキルが引き続きワークフロー全体を定めるものであり、エージェント自身が意味上の判断を行う必要があります。

mainline init はデフォルトでフックをインストールします。ユーザーからフック連携の確認、修復、または手動インストールを依頼された場合は、次のコマンドを使用してください。

mainline hooks status
mainline hooks install

フックがインストールされていない場合も、以下のコマンドワークフローに従って続行してください。フックがないことだけを理由に、コード作業を中断しないでください。

タスクの開始

目標が曖昧で有用なインテントを設定できない場合は、mainline start を実行する前に、手短に確認する質問を一つすることを優先してください。これを PRD／タスク計画に発展させないでください。それでも続行する場合は、最も安全で範囲の狭い解釈を採用し、最初の mainline append に前提を記録してください。

読み取り専用の診断、履歴の調査、計画のレビュー、「まず確認する／まだ変更しない」という依頼も Mainline を意識した作業ですが、インテントの宣言ではありません。必要に応じて preflight、status、context、show、trace などの読み取り専用コマンドを使用してください。現在の指示で、実質的な編集、コミット／シール／引き継ぎ、またはその他の永続的なエンジニアリング記録が許可されるまでは、mainline start を実行しないでください。調査が後から変更作業に移行した場合は、その時点でインテントを開始し、役立つ診断結果を最初の append に記録してください。

Mainline を意識したタスクの開始時には、まず読み取り専用ゲートを実行してください。

mainline preflight --json

preflight は、ノイズを抑えた準備状況のゲートです。"level": "ok" と "ok_to_continue": true が返された場合は、念のためにコンテキストの範囲を広げることなく、そのまま続行してください。warn または block が返された場合は、findings、overlaps、recommended_next の各フィールドを読み、その後で、示された対象を絞ったフォローアップコマンド（show、trace、context --files/--query、または check）のみを実行してください。

agent_authority がある場合は、それも確認してください。CLI の JSON ではコマンドのペイロードが .data の下に格納されるため、実行時のパスは通常 .data.agent_authority です。例やテストでは、ラップされていないエンジンのフィールドとして agent_authority が示される場合があります。これは参考情報ですが、人間から新たな指示がない状態でエージェントがどこまで進めてよいかを定める、チーム内で可視化された停止ラインの契約です。

• assist / before_commit：分析、編集、検証を行い、ユーザーが明示的に引き継ぎを依頼しない限り、コミット、seal、公開、push、または PR の前に停止します。
• handoff / proposed_intent：作業範囲を限定してコミットし、準備ができたら seal してから、ユーザーが明示的にレビューを依頼しない限り、コードブランチの push、または PR の作成・更新の前に停止します。
• review / opened_pr：生成された Mainline PR 本文を使って、main 以外のブランチで外部レビューに進み、マージ、リリース、またはマージ後のクリーンアップの前に停止します。

ハードゲートと現在のユーザー指示が優先されます。チームの max_autonomy は上限です。現在のユーザー指示によって停止ラインを下げることはでき、上限まで引き上げることもできますが、チームの上限を超える境界は許可できません。1 ターン限りの上書きを .mainline/config.toml または .mainline/local.toml に書き込まないでください。

preflight によって .data.agent_authority.current.allowed_boundary が inspect_or_stop に引き下げられた場合は、ライフサイクルを確認せずに進めないでください。まず、名前が示された findings と overlaps を確認してください。各 overlap を分類します。

• 同じブランチ、同じ目標、または明示的なフォローアップ → 関係を記録します。
• 隣接・補完関係にあるプロトコルまたはドキュメント作業 → 矛盾しない理由を記録します。
• 同じ動作に影響する上流のずれ → 実装または完了処理の前に、rebase、merge、または確認を行います。
• 実際に存在し、意味的に矛盾する可能性のある競合 → mainline check を実行するか、人間に判断を求めます。

ファイルが重複しているというだけの理由で mainline check を実行しないでください。overlap を黙って無視しないでください。次の append または seal に分類を記録してください。

status または preflight における notes_health.likely_history_rewrite は、直近の同期時にキャッシュされた値であり、ホットパスコマンドを実行するたびに再計算されるわけではありません。ユーザーが最近の force-push、rebase、filter-repo による書き換え、author の書き換え、contributor のクリーンアップ、リモートのロールバック、または提案・カバレッジの状態が突然誤ったことに言及した場合は、キャッシュされた警告がなくても、読み取り専用の診断を実行してください。

mainline doctor --notes --json

doctor が移行を推奨する場合は、まずプレビューしてください。

mainline migrate notes --infer --dry-run --json

ユーザーが計画を明示的に承認しない限り、mainline migrate notes --write または --push を実行しないでください。--push は共有 notes ref を変更します。

インストール済みバイナリが古く、preflight がない場合は、次にフォールバックしてください。

mainline status --json

その後、status またはタスクの内容から重複のリスクが示唆される場合に限り、mainline list-proposals --json と、対象を絞った mainline context --files ... --json を実行してください。

履歴の書き換えとノートの復旧

mainline preflight --json が notes_rewrite_drift の検出結果を報告する場合、または mainline status --json に notes_health.likely_history_rewrite: true が含まれる場合は、 まず読み取り専用の診断を実行してください。

mainline doctor --notes --json

ユーザーが最近の強制プッシュ、リベース、filter-repo による書き換え、作成者情報の書き換え、コントリビューターの整理、リモートのロールバック、または履歴変更後に提案されたインテント／未カバーのコミットが急増したことに言及した場合も、mainline doctor --notes --json を実行してください。

doctor が移行を推奨する場合は、プレビューのみを実行してください。

mainline migrate notes --infer --dry-run --json

書き込みを行う前に、安全／要確認／未解決の件数をユーザーに提示してください。ユーザーが計画を明示的に確認しない限り、mainline migrate notes --write または --push は実行しないでください。--push は共有ノート参照を変更するため、影響の大きい Git 操作として扱う必要があります。

アクティブなインテントがなく、タスクが非自明な変更や永続的なエンジニアリング記録の作成に踏み込んでいる場合は、ユーザーの実際の目標を使ってインテントを開始してください。

mainline start "<user goal>" --json

mainline start がブランチの既存のドラフトを返した場合は、追記する前に、それがユーザーのタスクと一致することを確認してください。一致しない場合は、停止して作業を分離してください。

同じブランチに封印済みまたは提案済みのインテントがすでにあり、ユーザーが変更の追加を求めている場合は、封印済みのインテントを変更しようとせず、追加分の新しいインテントを開始してください。

変更を設計する前に、進行中の作業を確認してください。

mainline list-proposals --json

preflight を利用でき、問題がなければ、別途 list-proposals を呼び出す必要はありません。preflight は提案済みインデックスをすでに読み込み、ファイルの重複を報告します。古いバイナリを使う場合の代替手段として、または preflight で重複の調査が必要と示された場合に、list-proposals を使用してください。

インテント優先のコード読み取り

非自明な作業では、広範な grep、ファイル読み取り、実装に着手する前に、まず簡潔な preflight ゲートを使用してください。

mainline preflight --json

重複、古いビュー、またはブランチの不一致が報告された場合は、範囲を絞って詳しく調べてください。

mainline context --files <path>... --json

タスクが意味的なものの場合：

mainline context --query "<task summary>" --json

返された要約、決定事項、リスク、フィンガープリントを確認してください。これらを過去の文脈として利用し、現在のコードと照らし合わせて検証してください。ユーザーが明示的に再検討を求めない限り、放棄または置き換えられたアプローチを繰り返さないでください。

関連するインテントについて：

mainline show <intent_id> --json
mainline trace <intent_id> --json

すべてのタスクで、慣例として広範な context --current、list-proposals、show、trace を実行する必要はありません。意図する流れは、まず preflight を実行し、問題がなければ続行し、警告または問題ありの場合は、指定されたインテント／ファイルを調べて特定のリスクに対処することです。

重複の収束ツリー：

• 上流ですでにユーザーの目標が達成されている → ローカルのドラフトを破棄するか、重複する前に停止します。
• ローカルの作業に追加の価値がある → 範囲を絞り、追加分のインテントにします。
• 2つのインテントが意味的に両立しない → 続行する前に mainline check を実行するか、人間の判断を仰ぎます。

ワークツリーとインテントの所有権

調整スコープが local_worktrees の場合、別個のクレーム／リースレジストリを作成または模倣しないでください。兄弟エージェントがチェックアウトしたブランチのドラフトインテントが、アクティブなローカルクレームになります。preflight はそのワークツリーのパス、目標、確認済みのファイルを提示するため、エージェントは既存の作業を再利用したり、スコープを絞ったり、編集前に依存作業の順序を決めたりできます。作業をブロックするのは、進行中の明示的なファイルの重複のみです。目標だけが一致する場合、提案済み／封印済みの履歴、古いドラフトは警告にとどまります。チェックアウト済みのワークツリーを封印、破棄、または削除すると、クレームは自然に終了します。

クリーンな状態、または現在のタスクが明らかに所有している状態であれば、現在のワークツリーを再利用してください。

git switch、mainline append、または mainline seal の前に、ブランチ、アクティブなインテント、変更済み／未追跡ファイルが、引き続き同じタスクに対応していることを確認してください。そうでない場合は、停止して作業を分離してください。並行してアクティブなインテントを進める場合は、別の Git ワークツリーを優先してください。

編集ワークフロー

Mainline のコンテキストパスの後、通常どおりコードを調べ、依頼された変更を行います。

重要な節目でターンを記録します。

mainline append "<what changed and why>" --json

サブタスクの完了後、方針の転換後、またはアプローチを変える必要がある発見の後に追記します。分刻みの作業ログは追記しないでください。

調査中、アイデアを検証中、またはブランチがリベース、修正、スコープ変更される可能性が高い間は、意図のドラフトを続けてください。ローカルコミットは有用な証拠ですが、それだけで作業をチームの記憶として提出できる状態になったことにはなりません。

停止ラインのワークフロー

agent_authority と現在のユーザー指示に基づいて、作業を終了する境界を決定します。「作業が実装された」ことを、境界を越えて進む自動的な許可として扱わないでください。現在の指示による上書きは、このターンに限ってエージェントが解釈します。.mainline/config.toml または .mainline/local.toml に書き込まないでください。

1. mainline preflight --json でコラボレーションのコンテキストを確立します。
2. .data.agent_authority.current.allowed_boundary を読み取り、現在のユーザーによる上書きを判断します。
3. 作業を行い、検証します。
4. 許可された境界までのみ進めます。
5. ハードゲートに達したら停止します。

実効境界は、チームポリシー、ハードゲート、現在の指示のうち最も低いものです。ユーザーからの直接の依頼によってターンを review に引き上げられるのは、.data.agent_authority.team.max_autonomy が許可する場合に限ります。マージ、リリース、マージ後のクリーンアップは、自律的に行う作業ではなく、明示的なデリバリータスクです。

現在の指示による上書きの分類：

指示の分類	扱い
助言のみ／読み取り専用	assist に下げます
ローカル作業の完了／コミット／シール／引き継ぎ	境界を handoff に設定します
ブランチのプッシュ／PR の作成または更新	max_autonomy の上限内で review に引き上げます
マージ／リリース／デプロイ／パッケージの公開／マージ後のクリーンアップ	明示的なデリバリータスクであり、自律的に行う作業ではありません。対象を特定し、直接依頼され、ほかのハードゲートが許可する場合に限って進めます

曖昧な継続指示によって PR まで進められるのは、実効自律性が review の場合に限ります。また、実装が完了し、検証に合格し、未解決の設計上の疑問がなく、コミット／シール／PR が次の自然な境界である必要があります。それ以外の場合は、未完了の実装または設計の手順を続けてください。

コミットワークフロー

Mainline は、リポジトリで変更をステージする方法、コミットを作成する方法、コミットをまとめる方法を規定しません。リポジトリに既存の Git ワークフローとコミット規約を使用してください。自分でコミットを作成する場合は、まずステージ前とステージ済みの差分を確認し、意図したファイルのみを含めてください。

コミットまたはシールの前に、準備状況ゲートを再実行します。

mainline preflight --json

block が報告された場合は停止し、指定された重複／ドリフトを解決またはエスカレーションしてください。差分のみのシールや古いベースに基づくシールを作成してはいけません。warn のみが報告された場合は、引き継ぎ時に警告に触れ、続行する前に意識的に判断してください。

シールの前に、Mainline が参照できるコミットが存在する必要があります。そのコミットは Mainline が作成するものではありません。

実効自律性が assist の場合は、差分と検証状況を報告した時点でここで停止します。その後、ユーザーがコミットとシールを明示的に依頼できます。これは現在の指示による引き継ぎです。

ユーザーがコミットまたは PR を依頼し、ブランチに有効な意図がない場合は、変更が真に機械的で、リポジトリポリシーでスキップ対象とされている場合を除き、コミット前に意図を作成するか、後から補完してください。

シールワークフロー

作業が引き継ぎ、レビュー、PR、プッシュ、またはチームで共有されるその他の記憶の境界に達したときにのみシールしてください。ローカルの実験や中間コミットが存在するというだけでシールしてはいけません。

ユーザーが引き継ぎ、コミット、またはシールの境界を明示的に依頼していない場合は、実効自律性が assist の状態でシールしてはいけません。

リポジトリに意図したコミットがあり、作業がその引き継ぎ境界に達したら、シールの準備をします。

mainline seal --prepare --json > .ml-cache/seal.json

.ml-cache/ は mainline init によって Git の追跡対象から除外されるため、一時的なシールファイルは Git に含まれず、送信時の v0.3 のワークツリークリーンチェックにも合格できます。パッケージには、決定的な情報（intent_id、fingerprint.files_touched、fingerprint.subsystems）があらかじめ入力された seal_result_starter フィールドが含まれています。JSON を最初から入力するのではなく、該当する場合は title／what／why／decisions／rejected／acknowledged_constraints／review_notes／fingerprint／confidence を補完してください。

シールでは、デフォルトで決定事項が記録されます。シールサマリーの書き込みスキーマには、従来の summary.risks、summary.followups、summary.anti_patterns など、永続的なシグナルの作成フィールドは含まれていません。これらのキーを含む古い一時シールファイルは拒否されるため、mainline seal --prepare --json で再生成してください。

情報源が実在する場合にのみ、明示的なシグナルコマンドを使用してください。

• mainline risks add を使用するのは、トリガーまたは影響に加え、緩和策／検証方法／担当者を含む具体的な障害モードがある場合に限ります。
• mainline followups add を使用するのは、ユーザーが作業を明示的に先送りした場合、外部の issue／ticket／PR が存在する場合、またはこの PR で実際のスコープを明示的に削った場合に限ります。
• 制約を独自に作成しないでください。mainline guard add は対話式で、人間の確認が必要です。

レビュー担当者のコンテキスト、検証メモ、受け入れたトレードオフ、スコープの説明、「あとで対応するかもしれない」という考えしかない場合は、review_notes、decisions、最終回答に記載するか、記載を省略してください。制約の候補をユーザーに提案することはできますが、人間の確認を経た guard コマンドによってのみ永続化されます。

返されたスキーマに一致する SealResult JSON を生成してください。競合検出に使えるよう、fingerprint は十分に具体的なものにしてください。

• summary.decisions はオブジェクトの配列（point、chose、任意の rationale、任意の文字列配列 rejected）であり、文字列配列ではありません。
• summary.rejected はオブジェクトの配列（alternative、任意の reason）です。上位レベルで却下した代替案がない場合は [] のままにしてください。
• summary.review_notes は文字列配列です。一時的なレビュー担当者のコンテキストがない場合は [] のままにしてください。
• fingerprint.api_changes と fingerprint.data_model_changes はオブジェクトの配列です。該当する変更がない場合は [] のままにしてください。
• サブシステムと親概念
• 変更したファイル
• アーキテクチャに関する主張
• 動作の変更
• API または CLI の変更
• データモデルの変更
• セキュリティへの影響
• 移行に関する注意事項
• 類義語や関連技術を含むタグ

シールを送信します。

mainline seal --submit --json < .ml-cache/seal.json

ユーザーに属するためクリーンアップできない、無関係な変更済みファイルまたは未追跡ファイルがワークツリーにある場合は、Mainline がそのダーティ状態を永続的に記録することを明記したうえでのみ、--allow-dirty を使用してください。

mainline seal --submit --allow-dirty --json < .ml-cache/seal.json

応答に conflicts が含まれる場合は、意味上の競合判定ではなく、フェーズ 1 の重複警告として扱ってください。クローズアウトの前に調査して分類してください。隣接、補完的、または既に考慮済みの重複は、有用な場合に限り、人間向けの表現で簡潔にまとめてください。デフォルトでは生の JSON を貼り付けないでください。警告を分類できない場合、または実際の意味上の競合と思われる場合は、関連する intent、競合する可能性がある理由、推奨する次の対応を示してユーザーにエスカレーションしてください。ユーザーがデバッグ情報を求めた場合、または失敗の診断にツール出力が必要な場合にのみ、生の JSON を含めてください。

送信はローカルでシールされたものの、ネットワーク障害により公開に失敗した場合は、後で再試行してください。

mainline publish --intent <intent_id> --json

これはメタデータの公開であり、製品のリリースやデプロイではありません。シール済みの Mainline intent 状態の公開を再試行するだけです。

シール文言、lint 警告、rebase／amend 後のコミットハッシュのずれを直すために、定型的な修復手段として mainline abandon を使用しないでください。abandon は作業のキャンセルまたは却下に使用します。送信済みのシールに問題がある場合は、その問題を報告し、ユーザーとともに明示的な修復／置換方法を選択してください。

公開、プッシュ、PR

Mainline では、Git のプッシュ、プルリクエスト、GitHub は必要ありません。ユーザーから明示的に変更を求められない限り、リポジトリの既存のレビューおよびリリースのワークフローを維持してください。

handoff の自律性は、コードブランチのプッシュまたは PR の作成／更新の前で終了します。review の自律性では、main 以外のブランチをプッシュし、PR を作成または更新できますが、マージ、リリース、マージ後のクリーンアップの前で終了します。現在のブランチが main の場合、プッシュまたは PR の作成の前に main 以外のブランチを作成するか、そこへ切り替えてください。review の自律性では、git push origin main は決して許可されません。

ユーザーがリモートブランチへのプッシュまたは PR の作成を依頼し、停止ラインで許可されている場合は、実行前にインテントが提案済みまたは公開可能であることを確認してください。

mainline status --json
mainline publish --intent <intent_id> --json

ユーザーのワークフローで PR を作成または更新する場合は、確定済みの Mainline インテントから PR の本文を生成してください。

mainline pr-description --intent <intent_id> > .ml-cache/pr-description.md

生成した Markdown を PR の本文として使用してください。確定済みのインテントがある場合、代わりの PR 説明を手書きしたり、汎用の GitHub 公開ヘルパーのデフォルト本文に頼ったりしないでください。生成された本文には mainline:pr-description マーカーが含まれています。PR インテントコメントのワークフローでは、このマーカーを使って重複した固定コメントの作成を防ぎます。

GitHub の公開ヘルパー、コネクター、または gh pr create のフォールバックを呼び出す前に、生成されたファイルを確認し、引き続き `` が含まれていることを検証してください。そのファイルの内容をそのまま PR の本文として渡してください。表示されている Markdown だけをコピーしたり、見た目が似た本文を再生成したり、--fill／デフォルトの文章で公開ヘルパーに本文を上書きさせたりしないでください。gh のフォールバックでは、次の安全な形式を使用してください。

gh pr create --body-file .ml-cache/pr-description.md

確定済みのインテントがある場合は、gh pr create --fill やコネクターのデフォルト本文を使用しないでください。

ユーザーがプッシュや PR の作成を依頼していない場合は、Mainline インテントの確定／公開後に停止し、ローカルでの結果を報告してください。Mainline のメタデータが準備できているという理由だけで、リモートのワークフローを持ち込まないでください。

ユーザーから明示的に依頼されない限り、次の操作は実行しないでください。

mainline pin <intent> <commit>
mainline init --rewire
mainline doctor --setup --fix

レビューと競合のワークフロー

Mainline の状態のレビュー、過去の作業の説明、または競合マーカーの判断を依頼された場合は、次のコマンドを使用してください。

mainline log --json --limit 30
mainline show <intent_id> --json
mainline trace <intent_id> --json
mainline check --prepare --intent <intent_id> --json
mainline check --submit --json < judgment.json

判断とリスクを理解するには show を使用してください。作業の経緯を理解するには trace を使用してください。調査したフェーズ 1 の重複が実際にあり、矛盾する可能性がある場合に限り check を使用してください。隣接または補完的な重複は、check にエスカレーションするのではなく、append／seal で判断として記録してください。

カバレッジと復旧

status または gaps で未カバーのコミットが報告された場合：

mainline gaps --json

最も破壊的でない復旧方法を選んでください。これらは復旧の選択肢であり、リポジトリの通常の Git ワークフローに取って代わるものではありません。

• コミットがローカルにあり、まだプッシュされていない場合は、git reset --soft HEAD^ でコミットを取り消し、適切なインテントを開始して、リポジトリの通常のワークフローで再コミットし、seal できます。
• コミットがすでにプッシュされている場合は、mainline start "<why>" --commits <sha> でインテントを後から補い、事後の説明を append してから seal してください。
• 定型的なもので、意図的に Mainline の対象外にする場合は、Mainline-Skip: トレーラーを追加するか、スキップパターンを設定してください。

ユーザーから明示的に依頼されない限り、公開済みの履歴を書き換えないでください。

スキルの配布

対応するターゲットエージェントには、npx skills を使ってこのスキルをインストールしてください。

npx --yes skills add mainline-org/mainline --skill mainline --agent codex claude-code cursor pi --global --yes

このリポジトリでローカル開発を行う場合：

npx --yes skills add ./skills/mainline --skill mainline --agent codex claude-code cursor pi --global --yes

mainline init は、ベストエフォートでデフォルトのスキルとフックをインストールします。既存のグローバルスキルのインストールは、mainline agents update や mainline init --rewire では更新されません。次のコマンドで明示的に更新してください。

npx --yes skills update mainline --global --yes

update でソースを特定できない場合は、上記の対応する skills add コマンドを再実行してください。このスキルの永続的な目的は、Mainline のインテントデータを正しくインストール、初期化、使用、公開、レビューする方法をエージェントに教えることです。