<Use_When>

ユーザーがアイデアから動作するコードへのエンドツーエンドの自律実行を希望する場合
ユーザーが「autopilot」、「auto pilot」、「autonomous」、「build me」、「create me」、「make me」、「full auto」、「handle it all」、または「I want a/an...」と言った場合
タスクに計画、コーディング、テスト、検証の複数フェーズが必要な場合
ユーザーがハンズオフ実行を希望し、システムが完了まで実行しても構わない場合 </Use_When>

<Do_Not_Use_When>

ユーザーがオプションの探索やブレインストーミングを希望する場合 — 代わりに plan スキルを使用
ユーザーが「just explain」、「draft only」、または「what would you suggest」と言った場合 — 会話形式で応答
ユーザーが単一のコード変更を希望する場合 — ralph を使用するか、エグゼキューターエージェントに委任
ユーザーが既存の計画のレビューや批評を希望する場合 — plan --review を使用
タスクが簡単な修正や小さなバグの場合 — エグゼキューターに直接委任 </Do_Not_Use_When>

<Why_This_Exists> ほとんどの非自明なソフトウェアタスクには、要件の理解、ソリューションの設計、並列実装、テスト、品質検証といった協調的なフェーズが必要です。オートパイロットはこれらの全フェーズを自動的に調整するため、ユーザーは何を望むかを説明するだけで、各ステップを管理することなく動作するコードを得られます。 </Why_This_Exists>

<Execution_Policy>

各フェーズは次のフェーズが開始する前に完了しなければなりません
可能な場合（フェーズ2とフェーズ4）、フェーズ内では並列実行が使用されます
QAサイクルは最大5回繰り返されます。同じエラーが3回続いた場合は停止し、根本的な問題を報告します
検証はすべてのレビューアの承認が必要です。拒否された項目は修正され、再検証されます
/oh-my-claudecode:cancel でいつでもキャンセルできます。進行状況は再開のために保存されます </Execution_Policy>

<Workflow_Profiles>

名前付きステージプロファイル (v1)

設定済みのプロファイルは /autopilot --workflow <name> <task> でのみ選択します。プロファイルはオートパイロットが所有するステージスケジュールであり、コマンド、モード、プラグイン、ファイル名、または独立した状態IDではありません。--workflow が指定されない場合、オートパイロットは従来のライフサイクルと振る舞いを保持します。

名前付きワークフロープロファイルはv1ではLinuxと flock ユーティリティを必要とします。これは、トランスクリプト証拠境界がLinuxのno-followファイルディスクリプタトラバーサルを使用し、回復可能なミューテーションロックがカーネルアドバイザリロックを使用するためです。サポートされていない環境では、状態ミューテーションの前に明示的な --workflow アクティベーションを拒否します。代わりに従来のオートパイロットを使用してください。

プロファイルはプロジェクトまたはユーザーのJSONCで autopilot.workflows.<slug> として設定されます。すべてのv1プロファイルは正確に version: 1 と stages を持ちます。他のプロファイルキーは受け入れられません。許可されるステージシーケンスは以下のみです：

{
  "autopilot": {
    "workflows": {
      "plan-build-qa": {
        "version": 1,
        "stages": ["ralplan", "execution", "qa"]
      }
    }
  }
}

[ralplan, execution]
[ralplan, execution, ralph]
[ralplan, execution, qa]
[ralplan, execution, ralph, qa]

ralplan は execution で消費される計画を作成します。execution は ralph と qa で必要とされる実装済みワークスペースを作成します。したがって、前提条件の欠落や順序変更、重複ステージ、および組み込みでないステージは無効です。プロファイル名は ^[a-z][a-z0-9-]{0,62}$ を使用し、検証されたメタデータのみであり、組み込みステージ、オートパイロット/モード名、または非推奨のエイリアスと衝突できません。

ユーザー設定とプロジェクト設定はそれぞれ、合成前に検証されます。異なる名前は共存できます。同じ名前のプロジェクトプロファイルは、ユーザープロファイルをディープマージするのではなく、完全に置き換えます。環境設定はプロファイルを定義したり置き換えたりできません。

選択が成功すると、オートパイロットは既存のセッションスコープ状態を、不変の正規化された記述子と選択されたパイプライントラッキングで原子的に作成します。記述子には、ワークフロー名、プロファイルバージョン、正規ステージ、および決定論的なSHA-256プロファイルハッシュが含まれます。タスクテキストや可変の進行状況は除外されます。再開と停止はそのハッシュを検証し、不一致がある場合は設定を再読み込みせずに、ステージプロンプトを発行せずに拒否します。キャンセル、再開、クリーンアップ、状態検査、HUD、および停止継続はオートパイロットが所有します。

インストール済みプラグインおよびスタンドアロンインストール済み停止フックは、アクティブステージの承認されたアシスタント完了レコードが、そのステージの永続化されたアクティベーショントランスクリプト境界の後にのみ進行します。それらは証拠を所有者セッションと境界付きの非シンボリックリンクトランスクリプトにバインドし、ユーザー/ツール/ローカルコマンド出力や古い/間違ったステージの証拠を拒否し、compare-before-writeトラッキング更新を使用して、重複または同時のStopイベントが正確に1回だけ進行するようにします。公開状態、HUD、および停止出力は、安全なワークフローメタデータと進行状況のみを表示し、タスク、記述子内部、トランスクリプト参照、オフセット、またはレコードハッシュは表示しません。

V1 延期事項

V1は以下をサポートしません：stageModels、モデルルーティング、プロバイダーまたはロール選択、インライン/ノースポーン実行、動的コマンド、モード、状態ファイル、任意のステージ、プロンプト、プラグイン、ブランチ、ループ、DAG、コールバック、環境定義のプロファイル定義。カスタムスキルのインライン配列フロントマターパーサーの不一致も延期されます。 </Workflow_Profiles>

フェーズ 1 - 計画: 仕様から実装計画を作成する
- ralplan合意計画が存在する場合：スキップ — 3ステージパイプラインですでに完了
- アーキテクト（Opus）: 計画を作成（直接モード、インタビューなし）
- クリティック（Opus）: 計画を検証
- 出力: .omc/plans/autopilot-impl.md
フェーズ 2 - 実行: 必要に応じてRalph永続性を持つエグゼキューターエージェントを使用して計画を実装する
- エグゼキューター（Haiku）: 簡単なタスク
- エグゼキューター（Sonnet）: 標準的なタスク
- エグゼキューター（Opus）: 複雑なタスク
- 独立したタスクを並列実行
フェーズ 3 - QA: すべてのテストが合格するまでサイクル
- ビルド、リンター、テスト、障害修正
- 最大5サイクル繰り返し
- 同じエラーが3回続いた場合は早期停止（根本的な問題を示す）
フェーズ 4 - 検証: 並列での多視点レビュー
- アーキテクト: 機能の完全性
- セキュリティレビューア: 脆弱性チェック
- コードレビューア: 品質レビュー
- すべてが承認する必要があります。拒否された場合は修正して再検証
フェーズ 5 - クリーンアップ: 正常完了時にすべての状態ファイルを削除する
- .omc/state/autopilot-state.json、ralph-state.json を削除（古い ultraqa-state.json/ultrawork-state.json のレガシーコピーが存在する場合はそれらも）
- クリーンな終了のために /oh-my-claudecode:cancel を実行

<Tool_Usage>

フェーズ4のアーキテクチャ検証には Task(subagent_type="oh-my-claudecode:architect", ...) を使用
フェーズ4のセキュリティレビューには Task(subagent_type="oh-my-claudecode:security-reviewer", ...) を使用
フェーズ4の品質レビューには Task(subagent_type="oh-my-claudecode:code-reviewer", ...) を使用
エージェントは独自の分析を形成して返します。LEADは自身でクロス検証エージェントを起動します。Claude Codeの深さ設定を確認せずにサブエージェントがさらにサブエージェントを起動することに依存しないでください：Claude Code 2.1.217–2.1.218では CLAUDE_CODE_MAX_SUBAGENT_SPAWN_DEPTH がデフォルトで1でしたが、2.1.219+ではデフォルトで3です。ネストされた委任が意図的であり、アクティブなランタイムでサポートされている場合を除き、クロス検証はLEADレベルで維持してください。
外部ツールでブロックしないでください。委任が失敗した場合は利用可能なエージェントで続行してください </Tool_Usage>

<Escalation_And_Stop_Conditions>

同じQAエラーが3サイクル続いた場合は停止して報告する（人間の入力が必要な根本的な問題）
検証が3ラウンドの再検証後も失敗し続ける場合は停止して報告する
ユーザーが「stop」、「cancel」、または「abort」と言った場合は停止する
要件があいまいすぎて拡張で不明確な仕様が生成された場合、ソクラテス式明確化のために /deep-interview へのリダイレクトを提案するか、一時停止してユーザーに明確化を求めてから続行する </Escalation_And_Stop_Conditions>

<Final_Checklist>

5つの全フェーズ完了（拡張、計画、実行、QA、検証）
フェーズ4ですべての検証者が承認した
テスト合格（新しいテスト実行出力で確認）
ビルド成功（新しいビルド出力で確認）
状態ファイルがクリーンアップされた
構築されたものの概要とともに完了をユーザーに通知 </Final_Checklist>

並列セッションの注意点

マルチリポジトリワークスペースアンカー: .omc-workspace マーカーを親ディレクトリに配置して、複数のサブリポジトリにわたる複数セッションが1つの .omc/ を共有できるようにします。解決順序: OMC_STATE_DIR > .omc-workspace > git > cwd。docs/REFERENCE.md を参照してください。
セッションIDソース: CLIコンテキストでは OMC_SESSION_ID 環境変数が優先され、フックコンテキストではフックペイロードの data.session_id が優先されます。
プランID（該当する場合）: オートパイロットの状態はセッションスコープです。同じワークスペースに2つのオートパイロットがある場合は、異なるセッションIDが必要です。
並列判定: サポートされています（セッションスコープの状態）

.claude/omc.jsonc（プロジェクト）または ~/.config/claude-omc/config.jsonc（ユーザー）のオプション設定：

{
  "autopilot": {
    "maxIterations": 10,
    "maxQaCycles": 5,
    "maxValidationRounds": 3,
    "pauseAfterExpansion": false,
    "pauseAfterPlanning": false,
    "skipQa": false,
    "skipValidation": false,
    "execution": "solo"
  }
}

tmux CLIチームランタイムを通じてオートパイロット実装を実行し、Cursorエグゼキューターを優先する場合：

{
  "autopilot": {
    "execution": "team",
    "team": { "agentTypes": ["cursor"] }
  }
}

この設定では、実行ステージは以下のようにエグゼキューター形式の作業を起動する必要があります：

omc team 1:cursor "<implementation task>"

またはClaude Codeスラッシュ互換性サーフェス：

/omc-teams 1:cursor "<implementation task>"

制限事項：

Cursorワーカーは実装およびレビューア形式のチームロールをサポートします。critic、code-reviewer、security-reviewer、test-engineer ワーカーは、チームリーダーが消費する構造化された評決ファイルを出力する必要があります。最終承認はリードセッションの責任です。
Cursorは cursor-agent CLIがインストールされ認証されている必要があります。cursor-agent が利用できない場合は、このセットアップ要件を報告し、サイレントにClaudeのみの実行にフォールバックしないでください。

再開

オートパイロットがキャンセルまたは失敗した場合、もう一度 /oh-my-claudecode:autopilot を実行して中断した場所から再開します。

入力のベストプラクティス

ドメインを具体的に指定 — "store"ではなく"bookstore"
主要機能を記載 — "with CRUD"、"with authentication"
制約を指定 — "using TypeScript"、"with PostgreSQL"
実行を許可 — 本当に必要な場合を除き、中断しない

トラブルシューティング

フェーズでスタック？ TODOリストでブロックされたタスクを確認し、.omc/autopilot-state.json を確認するか、キャンセルして再開します。

QAサイクルを使い果たした？ 同じエラーが3回続いた場合は根本的な問題を示します。エラーパターンを確認してください。手動介入が必要な場合があります。

検証が失敗し続ける？ 具体的な問題を確認してください。要件があいまいすぎた可能性があります。キャンセルして、より詳細な情報を提供してください。

ディープインタビュー統合

オートパイロットがあいまいな入力で呼び出された場合、フェーズ0は /deep-interview にリダイレクトしてソクラテス式の明確化を行うことができます：

ユーザー: "autopilot build me something cool"
オートパイロット: "リクエストが自由形式です。まずディープインタビューを実行しますか？"
  [はい、最初にインタビュー（推奨）] [いいえ、直接拡張]

.omc/specs/deep-interview-*.md にディープインタビュー仕様がすでに存在する場合、オートパイロットはそれをフェーズ0の出力として直接使用します（仕様は明確さのためにすでに数学的に検証されています）。

3ステージパイプライン: deep-interview → ralplan → autopilot

推奨される完全パイプラインは、3つの品質ゲートを連鎖させます：

/deep-interview "曖昧なアイデア"
  → ソクラテス的Q&A → 仕様（曖昧さ ≤ 20%）

/ralplan <仕様ファイル>
  → プランナー/アーキテクト/クリティックの合意計画

raftで検証された計画が存在する場合、オートパイロットはフェーズ0とフェーズ1をスキップして、フェーズ2から直接開始します。ユーザーは次のように発話します：

/オートパイロット 確認済みの計画 "<仕様ファイル>" を実装

これにより、すべての品質ゲートを維持しながら、最も高速な実行パスが提供されます。

オートパイロット