mcpField
A
auto

auto

github.com/q00エージェントワークフロー6.3k63 回インストール今日更新
リポジトリ

auto について

タスクの説明からインタビュー、Seed の生成とレビューを行い、品質基準を満たすと実行に進む Ouroboros スキルです。セッションの再開とバックグラウンドジョブの監視にも対応します。

主な機能

  1. 01範囲を限定したソクラテス式インタビュー
  2. 02Seed の生成と修復
  3. 03Seed レビュー後の実行
  4. 04再開可能な自動セッション
  5. 05バックグラウンドジョブの監視

活用シーン

  1. 01タスク説明からレビュー済み Seed を作成
  2. 02タイムアウトしたフローの再開
  3. 03自動実行の進捗確認

MCP 対応

Ouroboros MCP ツールを使って自動フローを開始・管理し、ジョブを監視して結果を取得します。

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/q00/ouroboros --skill auto

インストール後、Claude Code で/autoを入力して読み込まれたか確認します。

詳細

翻訳後に原文が更新されています。最新の内容は原文をご確認ください。

/ouroboros:auto

単一のタスク説明から、品質を重視した自動パイプライン全体を実行します。

ディスパッチ要件

このスキルは、MCP ツール ouroboros_start_auto を呼び出して実行する必要があります。手動でリポジトリを調査したり、シェルコマンドを実行したり、GitHub に問い合わせたり、ファイルを編集したり、その他の方法で自動パイプラインを代替したりしないでください。フルオートの実行は、対話型 MCP ツール呼び出しのタイムアウトを日常的に超えるため、バックグラウンドスターターが既定のサポート対象です。これは job_id と auto_session_id をすばやく返します。両方を保持してください。response.meta.job_observer が存在する場合は、その読み取り専用の待機/結果確認の役割を、独立した子セッションをちょうど 1 つ使って委任してください。メインセッションは、開始と明示的なオンデマンドでのステータス確認のみを担当します。

ouroboros_start_auto が利用できない場合、または必要なジョブのポーリング/結果取得用 MCP ツールのいずれかが利用できない場合は、停止して、必要な MCP ツールが利用できないことを報告してください。手動の代替手段は ooo auto の実行ではありません。

開始した自動ジョブが後に detached、blocked、failed、または別の自動セッションステータスを返した場合は、その自動セッションのステータスとツールのブロッカーを報告してください。detached は、追跡中のバックグラウンド処理が終了していない状態です。ジョブ/Ralph のハンドルを提示し、同じオーナーのもとで引き続き監視してください。blocked または failed の結果を MCP のディスパッチ失敗と呼んではいけません。ディスパッチ失敗とは、MCP ツールを呼び出せなかった場合を指します。

アクティブなランタイムが ooo auto を ouroboros_start_auto などのバックグラウンドスターター経由で処理する場合は、job_id を返した時点で終了しないでください。会話上の UX を引き続き担い、返された job_id、auto_session_id、カーソルを保持したうえで、ホストが子セッションをサポートしている場合は監視を委任してください。メインセッションで ouroboros_job_wait/ouroboros_job_status を使って監視するのは、フォールバック経路のみです。ユーザーにジョブを手動でポーリングさせないでください。

使い方

ooo auto "Build a local-first habit tracker CLI"
ooo auto --resume auto_abc123
ooo auto "Build a local-first habit tracker CLI" --skip-run
/ouroboros:auto "Build a local-first habit tracker CLI"

ooo auto は親 Seed ID/パスを受け付けず、目標の説明文から系譜を推測することもありません。目標内で既存の Seed に言及しても、それは通常のコンテキストであり、承認された派生操作ではありません。型付きの親からの進化には ooo evolve を、既存の不変 Seed の実行には ooo run を使用してください。ooo auto の目標だけを根拠に、系譜が保持されていることや AC の編集範囲を主張しないでください。

CLI フラグ → MCP 引数への変換

ユーザーがチャット内で CLI 形式のフラグを付けて ooo auto と入力した場合、ouroboros_start_auto を呼び出す前に MCP 引数へ変換します。

CLI フラグMCP 引数型
--skip-runskip_run=trueboolean
--max-interview-rounds Nmax_interview_rounds=Ninteger
--max-repair-rounds Nmax_repair_rounds=Ninteger
--pipeline-timeout-seconds Xpipeline_timeout_seconds=Xnumber
--efficiency-mode adaptive|quality_firstefficiency_mode=<value>string
--frugality-assurance off|observe|strictfrugality_assurance=<value>string
--resume <id>resume=<id>string

--max-generations は ooo auto のフラグではありません。ooo ralph に属します。run ジョブによって開始される連鎖型 Ralph の上限は execution.auto_evolve_max_generations で設定されます。

--complete-product は非推奨であり、無視されます。run ジョブが run → evaluate → ralph を担うため、単一の Auto 呼び出しで Ralph 自体を実行することはなくなりました。ooo status またはジョブツールを使って、run ジョブの処理を追跡してください。

--pipeline-timeout-seconds はセッション開始時にのみ受け付けられます。--resume と一緒に渡すと拒否されます。プロセスの再起動後も元の期限が維持されるためです。

新しい Auto セッションを開始する前に、ユーザーが効率性ポリシーを選択していない場合は、まず永続的なデフォルトを確認します。~/.ouroboros/config.yaml の execution.default_policy が efficient または quality_first の場合は、質問せず、両方の引数を省略します。サーバーが設定済みのデフォルトを適用します(ハンドオフでは解決済みのポリシーが引き続き報告されます)。それ以外の場合は、実行結果に基づく表現で質問します。 効率的な実行 は adaptive/observe に対応し、品質優先の実行 は quality_first/off に対応します。 strict の保証は、証明のために追加の作業が発生する可能性があるため、別途明示的なオプトインが必要です。効率性の選択から strict を推測してはいけません。再開時には、質問もどちらかの引数の送信も行いません。Auto は永続化された契約を復元します。

動作

  1. Auto セッションを開始します。
  2. ソースタグ付きの自動回答を用いて、上限付きのソクラテス式インタビューを実行します。
  3. Seed を生成します。
  4. A 評価に達するかブロックされるまで、レビューと修正を行います。
  5. A 評価に達した後にのみ、実行を開始します。
  6. Auto は、run に永続的なハンドルが用意できるとすぐに COMPLETE に到達します。run はバックグラウンドジョブとして継続し、そのジョブは execution.auto_evaluate / execution.auto_evolve(どちらもデフォルトは true、Ralph の上限は execution.auto_evolve_max_generations)に従う独自の run → evaluate → ralph 連鎖を実行します。Auto 自体が run を評価するのではなく、連鎖内の evaluate ジョブが評価します。
事前チェックによるブロックと復旧

seed_preflight_unexecutable は新しいセッションを開始する境界であり、単なる --resume の境界ではありません。永続化された Seed アーティファクトはその セッション内で不変であるため、未解決の質問に回答しても、アーティファクトが 暗黙に置き換わることはありません。表示された質問を使って目標/Seed 契約を 見直し、新しい ooo auto セッションを開始してください。ブロックされた セッションは監査用に引き続き利用できます。

一時的なインタビュー、評価ツール、またはラテラルツールの枯渇は別の問題です。 その再開機能は永続的であり、外部依存関係またはプロバイダーが再び正常になれば、 同じセッションで再試行できます。seed_preflight_unexecutable のステータスを、 再試行可能なプロバイダーの障害として扱わないでください。

バックグラウンド監視 UX

Auto の開始レスポンスに response.meta.job_id が含まれる場合:

  1. auto が開始されたことを簡潔に伝え、ハンドルをローカル状態に保持します。 job_id、auto_session_id / session_id、および存在する場合は response.meta の cursor を保持します。利用可能な場合は response.meta.dashboard_url を表示し、そうでなければライブビューとして ouroboros tui open を一度だけ案内します。オブザーバーが、意味のある進捗/ 注意/完了イベントをここに通知すること、またこの会話は要件の調整、 読み取り専用の確認/レビュー、明示的な制御、または無関係な分離作業にも 引き続き利用できることをユーザーに伝えます。存在する場合は、解決済みの runtime_backend、llm_backend、efficiency_mode、および frugality_assurance を含めます。実際に有効なモデルと最初の並列レベルは、 推測せず、最初の構成/計画イベントから通知すると伝えます。
  2. MCP メタデータを取得できない場合は、最終的な `` content sentinel から job_observer を復元します。上限付きペイロードが正規の v1 検証を 通過し、そのジョブ/セッション ID が画面に表示された開始レシートと 一致しない限り、安全側に倒して処理を中止します。画面上の ID は 識別アンカーであり、ツールや引数を再構築する情報源ではありません。 構造化データとインライン情報に検証失敗や不一致があれば拒否します。
  3. 構造化データまたは復元された job_observer があり、ホストが独立した 子セッションをサポートしている場合は、読み取り専用のオブザーバーを ちょうど 1 つ起動し、契約を変更せずに渡します。Codex では spawn_agent、 OMP ではネイティブの Task 子、Claude Code では Task/Agent 子を 1 つ使用します。 オブザーバーがカーソルを所有し、終端状態まで待機して結果を取得し、 follow_result_job_keys で指定された後続 ID を追跡します。ファイルを 編集したり、実行を制御したり、実装ワーカーを起動したりしてはいけません。 メインセッションは同じジョブをポーリングしてはいけません。 Codex では task_name="run_observer" を指定して spawn_agent を ちょうど 1 回呼び出します。wait 呼び出しは起動ではありません。起動結果に 稼働中の子 ID/パスが返った後に限り、オブザーバーを起動したと報告できます。 起動が確認されたら、子がアクティブな間は最大 60 秒の wait_agent 呼び出しで 親ターンを開いたままにします。子の send_message はメールボックスイベントを キューに追加するだけで、終了した親ターンを再開することはできません。 意味のある更新を伝え、オブザーバーから終端要約が届くまで再度待機します。 OMP では RunObserver という名前のネイティブ Task 子をちょうど 1 つ送信し、 稼働中のエージェント/ジョブ ID を必須とし、終端状態までホストの wait/ inbox relay を使用します。 ユーザー入力で待機が中断された場合は対応し、ユーザーがライブ監視の停止を 求めるか、アクティブなリクエストを置き換えない限り、監視が続く間は待機を 再開します。その場合は relay ループのみを終了し、永続ジョブは実行を続けた ままにして、次のターンまたは明示的なステータス確認で追いつけることを 案内します。オブザーバーの子が失敗、キャンセルされた、または終端要約を 出さずに終了した場合は、無期限に待機せず同じ代替手段を使います。この親の relay ループでは、ジョブの wait/result を呼び出したり、カーソルを所有したり してはいけません。 起動に失敗した場合は、ライブでの能動的な中継を約束しません。stdio ターンの 後も分離ワーカーは実行を続けること、永続的な進捗は次の親ターンまたは 明示的なステータス確認で補足することを伝えます。代替のポーリングループで 現在のターンを開いたままにするのは、ユーザーがライブ監視を求めた場合に 限ります。
  4. 子から親への進捗メッセージがサポートされている場合、オブザーバーは 意味のある phase_changed、progress_advanced、attention_required、 terminal イベントのみを 1~2 行以内で中継します。インタビュー中は、 新しい保留中の質問や回答済みラウンドを伝えるため、 ouroboros_session_status(session_id=<auto_session_id>) を使用できます。 それ以外の場合はメインセッションを利用可能な状態に保ち、ユーザーが求めた 場合にのみオンデマンドでステータスを確認します。人間の判断が必要な ブロッカーは、attention_required として直ちに伝えます。変化のない ハートビートや生のツール出力は抑制します。 実行状況の中継は明示的に解釈します。run_configuration は現在の ランタイム/ハーネス/モデルポリシーを、execution_plan は AC の総数、 依存関係/並列レベルの総数、最初にスケジュールされた AC を、 discovery_summary は範囲を限定した対象と目的を報告します。レベル/ ルーティング/ハーネス/検証済みのサブタイプは、重要な変更のみ報告します。 生のコマンドや推論は中継しません。メインセッションがアクティブな auto ワークスペースに書き込む前に、ワーカーファイルとの重複を確認するか、 無関係な作業を分離された worktree に移します。
  5. 独立した子セッションがなく、かつユーザーがこのターンで監視を続けるよう 明示的に求めた場合は、ノイズを抑えた代替ループに入ります。それ以外の場合は 安全にターンを終了し、次のやり取りで永続カーソルから再開します。
    • ouroboros_job_wait(job_id=<job_id>, cursor=<cursor>, timeout_seconds=120, view="summary", stream="linked", wait_for="attention_or_ac_change")
    • wait/status の各応答後に cursor = response.meta.cursor と更新します。
    • response.meta を信頼できる情報源として扱い、応答テキストは人が読むための ヒントとしてのみ使用します。
  6. 意味のある変化のみ中継します。ステータスの変化、フェーズの変化、新しい 実行/セッション/系譜のハンドル、進捗カウンター、ブロッカー/エラーの テキスト、または終端状態です。response.meta.changed is false の場合、 ユーザーがハートビート更新を求めていない限り、何も伝えずに続行します。 Synapse の配信イベントは意味のあるイベントです。queued/delivering と applied/completed を区別し、rejected/delivery_uncertain は 直ちに伝えます。中継はユーザーが現在使用している会話言語で表示し、正確な 診断に役立つ場合に限り、生のイベントコードを保持します。 実行中の auto run にユーザーが実装意図を追加した場合、メインセッションは まず tool discovery query: "+ouroboros session signal" で Synapse スキーマを 再読み込みし、その後、観測した execution_id を使って ouroboros_session_signal_targets を呼び出します。ac_content と現在の アクティビティから意味的に一致する AC を選び、その対象の正確な ID を指定して ouroboros_session_signal を送信します。内部 ID をユーザーに尋ねてはいけません。 複数の稼働中 AC が本当に同程度に該当する場合に限り、簡潔な確認を求めます。 共有の目標/AC/制約の変更を 1 つのワーカーに送ってはいけません。 追加の実装調整は、正確なターゲットガードとともに contract_effect="additive"、source="user"、mode="redirect"、 明示的な fallback_mode="after_turn" を指定して送信します。読み取り専用の AC に関する質問または保証依頼には mode="inform" を使用し、このモードでは fallback_mode を一切指定せず、完了イベントからの上限付き応答を中継します。
  7. インタビューフェーズでは、ラウンド数だけでなく、ライブの Q&A を伝えます。 中継されたフェーズが interview の場合(例:進捗が interview round N/50)は 必ず ouroboros_session_status(session_id=<auto_session_id>) を呼び出し、 ユーザーに次を中継します。(a)現在の meta.pending_question(インタビューで 今まさに尋ねられている質問)、(b)meta.auto_answer_log の項目。各項目は {round, source, question, answer} で、auto-answerer が何にどう答えたかを 示します(source:conservative_default = 安全なデフォルトポリシー、 inference = モデルによる推論、assumption = auto-answerer による代替回答)。 単なるカウンターではなく、インタビューがどのような結論に向かっているかを ユーザーが確認できるように表示します。注:この Q&A は auto-session の状態に あるため、ouroboros_query_events が auto session に対して何も返さなくても、 session_status で取得できます。表示されるのは直近 3 件の回答のみで、それぞれ 省略されます。ノイズを抑えるため、同じ 3 件を毎回ポーリングして伝えず、 保留中の質問と新たに回答されたラウンドのみを中継します。
  8. ジョブのステータスが終端状態でない場合(queued、running、または別の アクティブ状態)は、待機を続けます。ジョブツールを自分で呼び出すよう ユーザーに指示してはいけません。
  9. ジョブが終端状態に達したら、ポーリングの所有者が ouroboros_job_result(job_id) を呼び出し、auto-session の最終結果を要約します。 最終的な auto の結果が detached の場合は、完了として提示せず、利用可能な 下流のジョブ/Ralph ハンドルを追跡し続けます。
  10. response.meta.status == "delegated_to_plugin" かつ response.meta.job_id is None の場合は、OpenCode プラグインモードが作業を 子 Task/セッションに委任したことを報告します。実際のジョブ ID がない状態で job wait/result を呼び出してはいけません。ホストの Task ウィジェット/ セッションのライフサイクルに従います。 短い進捗報告を行ってください。目的は大量のログではなく、「引き続きこちらで確認しています」と伝えることです。

アクティブな Conductor の判断ポリシー

英語を正規の指示言語とし、事実はユーザーが現在使用している会話言語で自然に伝えてください。

attention_required では、recommended_host_actions を信頼できる情報源として扱ってください。

  1. VERIFY は、読み取り専用で短時間だけ動作するホスト子プロセスを最大1つ使って行ってください。利用できない場合は、証拠を提示し、変更を加える前に停止してください。
  2. DECIDE は、エンジンの所有権が closed になった後に限り、順序付きメニューから選択してください。
  3. ACT の前に、ouroboros_record_conductor_decision で selected を LOG してください。
  4. ACT には、メニューに記載された登録済みツールのみを使用してください。Auto は、その注意イベントに対して、決定論的で範囲が限定され、制約を緩和しない後続処理を最大1つ開始できます。その際、監査済みの指示/判断/先行処理のレシートを、正確に引き渡す必要があります。
  5. completed、failed、declined のいずれかの終端結果を、正確に1つ LOG してください。黙って再試行してはいけません。仕様を変更する提案はユーザーにエスカレーションします。Auto が承認済みの目標、AC、制約、非目標を独自に緩和することはありません。
正規の stop_reason_code 分類
レイヤーコード表示先意味
インタビューinterview_max_rounds_exhaustedlast_error_code、result.stop_reason_codeAuto のインタビューで、max_interview_rounds までに台帳とバックエンドが相互に合意せず、安全にデフォルト設定できるセクションもなく、部分的なデフォルト設定も適用されませんでした。つまり、ポリシーで解消できるものが何もない真のデッドロックです。
インタビューinterview_unsafe_gaps_remainlast_error_code、result.stop_reason_codeAuto のインタビューが max_interview_rounds に達し、安全にデフォルト設定できるセクションが少なくとも1つある一方で、安全ではないセクション(例:CONFLICTING の台帳エントリ、本番環境/認証情報のコンテキスト)が少なくとも1つ残っています。永続化されたトランスクリプトと台帳の整合性を保つため、部分的なデフォルト設定はロールバックされます。再開すれば、安全ではない箇所に対処して再実行できます。
インタビューinterview_phase_deadlinelast_error_code、result.stop_reason_codeインタビューのフェーズが、フェーズごとのタイムアウトを超過しました。
Ralphiteration_timeoutブロッカーテキスト+(将来)result.stop_reason_codeRalph の1回のイテレーションが、イテレーションごとのタイムアウトを超過しました。
Ralphwall_clock_exhaustedブロッカーテキスト+(将来)result.stop_reason_codeRalph が収束する前に、ウォールクロック予算を使い切りました。
Ralphoscillation_detectedブロッカーテキスト+(将来)result.stop_reason_codeRalph が進展しないまま、2つのグレード状態の間を行き来しました。
Ralphgrade_regressingブロッカーテキスト+(将来)result.stop_reason_codeRalph の後続の生成で、直前の生成より明確に低いグレードが生成されました。
Ralphmax_generations reachedブロッカーテキスト+(将来)result.stop_reason_codeRalph が A グレードに達する前に、設定された生成回数の上限に達しました。

正規のコードがないブロッカーには、引き続き自由形式の last_error テキストを使用します。現在、Ralph レイヤーのコードはブロッカーテキストを通じて表示されています。結果エンベロープへの格上げは、後続対応として記録されています。

インタビュー終了モードの分類

result.status == "seed_ready" のとき、result.interview_closure_mode はインタビューがどのように終了したかを区別します。

値意味
None相互合意 — バックエンドと台帳の両方が同じラウンドでシードを ready と宣言しました。デフォルトの正常パスです。
"ledger_only"PR-B1 / #1148: max_rounds に到達しました。台帳は構造的に完全でしたが、バックエンドが終了の宣言を拒否しました。インタビューは台帳のみの合意で終了します。デフォルト化されたセクション(存在する場合)は result.defaulted_sections にタグ付けされます。
"safe_default"PR-B2: max_rounds に到達しました。セーフデフォルトポリシーが、残っているすべての必須ギャップを監査可能な前提で埋めることに成功しました。シンセシスは永続化されたトランスクリプトに押し戻されたため、シードジェネレーターは台帳が記録するのと同じ前提を参照します。デフォルト化されたセクションは result.defaulted_sections にタグ付けされます。

真のデッドロックおよび部分的に安全でない結果は interview_closure_mode を設定しません。代わりに、上記の対応する stop_reason_code を伴う blocked ターミナルに到達します。

前提の出所の来歴 (PR-C2 / #1157)

result.assumptions: tuple[str, ...](既存の前提テキストのリスト)には、result.assumption_sources: tuple[AssumptionRecord, ...] が伴うようになりました。ここで各 AssumptionRecord は以下のフィールドを持つ frozen データクラスです。

フィールド型意味
textstr前提テキスト(存在する場合、対応する assumptions エントリと同じ表面)。
sourcestr"assumption"(自動回答のフォールバック)、"inference"(モデルの推論)、"conservative_default"(セーフデフォルトポリシー)のいずれか。これらは assumption_only_sections を生成する 3 つの前提クラスの LedgerSource 値です。
confidencefloat台帳によって記録されたエントリごとの信頼度。

assumption_sources は assumptions よりも広い表面です — assumptions(LedgerSource.ASSUMPTION のみにフィルタリングされる)が表面化しない、推論クラスおよび保守的デフォルトクラスのエントリを含みます。システムがユーザーに代わって行った前提を知りたい呼び出し元は assumption_sources を読むべきです。古い文字列のみの契約を維持する呼び出し元は引き続き assumptions を読みます。

パイプラインは無限にハングしてはなりません。すべてのループは境界があり、タイムアウト失敗は再開可能な auto_session_id を返します。ooo auto --resume <auto_session_id> で再開します。A グレードの Seed の後で停止するには --skip-run を使用します。--complete-product は非推奨であり無視されます。実行ジョブが run → evaluate → ralph を所有します。チェーンされた Ralph は execution.auto_evolve_max_generations(デフォルト 3)世代に制限され、各世代は Ralph の反復ごとのタイムアウトで上限が設定されます — 有限ですが、チェーンディスパッチが max_total_seconds を渡さないため、単一の総実時間上限はありません。自動セッションの --timeout はもはやそれを制限しません。CLI 専用の --show-ledger フラグは前提/非目標を出力します。MCP スキルの応答には、利用可能な場合、同じ台帳サマリーがすでに含まれています。

RFC #1392 状態ブレッドクラムフッター

最終応答は、正確に 1 行のブレッドクラムフッター行で終わらなければなりません。

◆ <current state> → next: <recommended action>

<current state> は、その MCP プロジェクションが利用可能な場合は ouroboros_session_status を介してライブセッション状態から導出してください。そうでない場合は、このスキルの実際の結果から導出してください。Ouroboros は進化的ループであるため、線形の Step N of M フッターを決して使用しないでください。次のアクションが本当に選択である場合は、next: 節に 2〜3 個の正直な選択肢をリストしてください。ブレッドクラム行は応答の最後の行でなければなりません。

コメント