Oboe MCP

コーディングエージェント向けの構造化されたOne-by-Oneワークフロー。

コーディングエージェント向けに、優先順位付けされたセッション状態を備えた、永続的なOne-by-OneレビューワークフローのためのMCPサーバーです。

優先順位付けされたセッションファイル内のアイテムを作成、ナビゲート、解決するための16個のツールを提供します。これには、ブロックされたアイテムの処理、ファーストクラスの承認更新、ネストされた子セッションなどが含まれており、/oboワークフローで生のJSON編集の代わりにMCP操作を使用できるようになります。

AGPL-3.0-or-laterでライセンスされており、商用ライセンスも利用可能です。 完全な条件についてはLICENSEを参照してください。

PyPIパッケージ

以下のいずれかの方法で、PyPIから直接Oboe MCPをインストールまたは実行します：

• インストールせずに実行： uvx oboe-mcp

• 現在の環境にインストール： pip install oboe-mcp

oboe-mcpをインストールすると、oboe-cliコマンドもインストールされます：

# After pip install oboe-mcp
oboe-cli --help

# From PyPI 
uvx --from oboe-mcp oboe-cli --help

# From a local checkout (no install needed)
uvx --from /path/to/oboe-mcp oboe-cli --help

CLIリファレンス (oboe-cli)

oboe-mcpをインストールすると、MCPツールが操作するのと同じセッションファイルに対して、人間が使いやすいコマンドラインコンパニオンであるoboe-cliもインストールされます。

oboe-cli [--session SESSION] [--base-dir DIR] COMMAND [ARGS...]

グローバルオプション：

Base-dir自動検出: --base-dirが省略された場合、oboe-cliは.github/obo_sessions/フォルダを含む現在の作業ディレクトリを使用し、そうでない場合は作業ディレクトリをそのまま使用します。

コマンド

クイックスタート

# Create a session from a JSON items file
oboe-cli --base-dir /path/to/project create \
    --title "Code review findings" \
    --input-file findings.json

# List sessions
oboe-cli --base-dir /path/to/project sessions

# Work through items
oboe-cli --base-dir /path/to/project --session session_20260411_120000.json next
oboe-cli --base-dir /path/to/project --session session_20260411_120000.json \
    in-progress 1
oboe-cli --base-dir /path/to/project --session session_20260411_120000.json \
    complete 1 "Fixed the validation bug"

注: 以前のバージョンで提供されていたobo_helper.pyスクリプトは、現在oboe-cliに委譲する薄い非推奨のシムとなっています。

OBOセッションの理由

One-by-Oneセッションは、単なる保存されたチャットメモではありません。これらは、複数のアイテムの作業を永続的で順序付けられた対話セッションとして処理するためのワークフローモデルです。

通常のチャットやエージェントの組み込みのフォローアップ質問と比較して、OBOはそれらの軽量な対話モードでは通常提供されない機能を追加します：

• 概要優先のワークフロー：エージェントがスコープ、アイテム数、主要カテゴリ、提案された実行順序から開始可能

• チャットに現れた順序ではなく、緊急性、重要性、労力、依存関係の圧力に基づく明示的な優先順位の再設定

• pending、in_progress、deferred、blocked、completed、skippedを通じた永続的なライフサイクル状態

• approval_status、approval_mode、approved_at、approval_noteを通じた個別の承認メタデータ

• 保存されたブロッカーメタデータ：ブロックされた作業がアクティブなキューから黙って消えるのではなく、可視化され説明可能になる

• 親セッションを一時停止し、サブ問題を処理してから親セッションをクリーンに再開するネストされた子セッション

• ファーストクラスのセッションライフサイクル管理：名前付きワークフローオブジェクトとしてセッションを一覧表示、作成、検査、マージ、一時停止、再開、終了

• モデルの再起動、エディタの再読み込み、エージェントの引き継ぎ後の決定論的な復旧

• 会話メモリに頼るのではなく、セッションファイル内の機械可読な監査証跡

これは、作業が多くの調査結果にまたがる場合、明示的なユーザー承認が必要な場合、中間的なサブ調査に依存する場合、または複数のエージェントのターンにわたって存続する必要がある場合に最も重要です。チャットは会話に適しています。構造化された質問ツールは、現在のターンでクリーンな回答を得るのに適しています。OBOは永続的なワークフローオーケストレーションのためのものです。

制御された順次処理、永続的なキュー状態、またはネストされたサブ作業が必要な場合はOBOを使用してください。タスクが小さく、完全なワークフローオブジェクトが価値よりもオーバーヘッドを追加してしまう場合は、通常のチャットを使用してください。

状態モデル

OBOは各アイテムを2つの独立した軸で追跡します。

ライフサイクル軸

• pending: 作業はキューに入れられているが、まだ開始されていない

• in_progress: 作業が現在進行中

• deferred: 作業は後の実行のために承認されており、アクティブなレビューパスが終了するか、ユーザーが明示的に延期された作業を要求するまで、即時のレビューキューから外しておくべき

• blocked: 外部の依存関係またはサブ問題が解決されるまで作業を続行できない

• completed: 作業は完了し、クローズされている

• skipped: 作業は意図的に実行されていない

承認軸

• unreviewed: 明示的なユーザーの決定がまだ記録されていない

• approved: ユーザーが作業を承認した

• denied: ユーザーが作業を明示的に拒否した

承認メタデータフィールド：

• approval_status: アイテムに対する承認決定

• approval_mode: 承認タイミングの決定が記録された場合のimmediateまたはdelayed

• approved_at: 承認が記録されたタイムスタンプ

• approval_note: 承認決定に関するオプションの自由記述メモ

一般的な組み合わせ：

• 即時承認: obo_set_approval(..., approval_status="approved", approval_mode="immediate")を呼び出す。アイテムは通常、作業が開始されるかin_progressに移動されるまでpendingのままです

• 遅延承認: obo_set_approval(..., approval_status="approved", approval_mode="delayed")を呼び出す。これにより遅延承認が記録され、アイテムはdeferredに移動されます

• 拒否: approval_status=deniedを設定する。アイテムがキューからクローズされる場合は、status=skippedと組み合わせる

対話モード

3つの一般的な対話パターンは、通常のチャット、構造化された質問ツール、および完全なOBOセッションです。これらは異なる問題を解決します。

進行例：

• 通常のチャット：エージェントがいくつかの調査結果を文章でリストアップし、会話自体が何が処理されたかの唯一の記録となる。

• askQuestions：エージェントはクリーンなメニュー選択を求めることができるが、他で保存しない限り永続的なアイテムキューを持たない。

• OBOセッション：エージェントは概要から開始し、完全なアイテムリストを保存し、意図的に順序付けし、承認、スキップ、ブロッカーを記録し、チャット履歴からセッションを再構築することなく後で再開できる。

おもちゃの例：5つのレビューアイテム

エージェントが小さなおもちゃのToDoアプリをレビューし、この生の発見順序で5つのアイテムを見つけたとします：

1. UIの曖昧な設定ラベルを改善する。

2. バックグラウンド同期ジョブの競合状態を解決する。

3. 重複するタスクIDの回帰テストを追加する。

4. create-taskエンドポイントの入力バリデーションを追加する。

5. ログインハンドラのパスワードログを修正する。

通常のチャット

エージェント：

おもちゃアプリで5つの問題を見つけました： 問題1：UIの曖昧な設定ラベルを改善する。 問題2：バックグラウンド同期ジョブの競合状態を解決する。 問題3：重複するタスクIDの回帰テストを追加する。 問題4：create-taskエンドポイントの入力バリデーションを追加する。 問題5：ログインハンドラのパスワードログを修正する。

次に何をしますか？

ユーザー：

4と2を先にやって。

解説：

• これは高速ですが、チャット自体がシーケンスの唯一の記録となり、アイテム4と3の間の依存関係は暗黙的です。

• 他の問題の状態はキャプチャされておらず、ユーザーはエージェントに他の問題を表示または作業するように明示的に要求する必要があります。

• セッションが中断された場合、別のエージェントはトランスクリプトから状態を再構築する必要があります。

askQuestionsスタイルのチャット

エージェント：

5つの問題を見つけました。どれを先にしますか？

オプション： • 4. create-taskエンドポイントの入力バリデーションを追加する • 2. バックグラウンド同期ジョブの競合状態を解決する • 5. ログインハンドラのパスワードログを修正する • 3. 重複するタスクIDの回帰テストを追加する • 1. UIの曖昧な設定ラベルを改善する

ユーザー：

4

エージェント：

次のアクションは？

オプション： • 2を続ける • 残りのリストを並べ替える • 停止

解説：

• これは通常のチャットよりもクリーンなユーザー選択を提供しますが、ツールはそれ自体で永続的で依存関係を認識するワークフローオブジェクトを作成しません。

• 他の問題の状態は依然としてキャプチャされておらず、ユーザーはエージェントに他の問題を表示または作業するように明示的に要求する必要があります。

• 同様に、セッションが中断された場合、別のエージェントはトランスクリプトから状態を再構築する必要があります。

One-by-Oneセッション

OBOエージェントのプロンプト指示に従い、エージェントはこの順序付けロジックを割り当てます：

• アイテム4が最初です。フォローアップの回帰テストが書かれる前に、create-taskエンドポイントの動作を安定させる必要があるためです。

• アイテム2が次です。競合状態は同期フロー全体の正確性に影響を与える可能性があり、ネストされた調査セッションが必要になる可能性があるためです。

• アイテム5が続きます。重要なセキュリティ修正ですが、バリデーションや並行性の作業をブロックしません。

• アイテム3はアイテム4の後ろに留まります。回帰テストは、先行するのではなく、最終的なバリデーション動作をロックインする必要があるためです。

• アイテム1は依然として有用ですが、他の4つのアイテムと比較して影響が小さいため、最後になります。

エージェント：

5つの調査結果のためにOBOセッションを作成しました。

エグゼクティブサマリー： • 合計アイテム：5 • カテゴリ：1 API正確性、1 並行性、1 セキュリティ、1 テスト、1 UX • 優先順位：4, 2, 5, 3, 1 • 推定労力：11 • クリティカルアイテム：3 • 依存関係メモ：アイテム3