mo-convergence

収束しない作業の診断

ユーザーが mo-convergence と明示した場合にのみ開始します。作業が遅いという指摘、長引くレビューの反復、失敗した試みでは開始されず、ほかのスキルから呼び出されることもありません。

Feature lifecycle と 方法論へのフィードバック を最後まで読みます。 直面した摩擦は回答でユーザーに伝え、このスキルから Issue を作成することはありません。

状況を確認する

作業を行っているエージェントと、スロットがまだアクティブなレビュー担当者全員に、ライフサイクルで既に使われているサーフェスを通じて、それぞれ通常のメッセージを1通送ります。収束を妨げているもの、自分自身が遅延の原因となったこと、そして妨げを解消するための変更を1つ尋ねます。意見を聞くために新しいセッションを開始してはならず、非アクティブなスロットを起こしてもなりません。参加者が離脱している場合は、状況を再構成せず、応答不可として記録します。

どちらの手順も判断に委ねるものではありません。レビュー担当者のスロットがアクティブかどうかは、バンドルされた scripts/mo-review-resource.mjs hot でスロットごとに判定します。フラグは --help に記載されています。判定には、最後の worker_done からの経過時間と画面に表示されるコンテキストを使います。詳細はOrca のネイティブな仕組みを参照してください。これには --alive が示す内容も含まれます。スロット自身が記録したターミナルと画面を確認し、Orca のワーカー稼働状況が unverifiable であることだけを根拠にしてはなりません。アクティブと判定されなかったスロットは非アクティブです。稼働中のエージェントにデータを送るには、空であることが確認済みの入力欄を経由する必要があります。各メッセージの直前に、バンドルされた scripts/mo-harness-screen.mjs がそのターミナルの現在の画面を読み取り、action=inject と判定しなければなりません。下書き、提案、信頼確認ダイアログ、シェルプロンプト、またはそれ以外の判定の場合は何も送信されません。その場合、その参加者は判定ツールの該当行とともに応答不可として記録します。

次に、公開されている証拠だけを使って、自分で一連の流れを確認します。候補の順序、各ラウンドの判定、attempt <n>/5 と deep_reads <m>、修正済みと記録された後に再び現れた指摘事項、そしてそれらが関わる要件を確認してください。新たな形で何度も再発する指摘事項は、修正箇所ではなく境界を示していることがよくあります。

推奨する

理由とともに、次のうち1つをユーザーに推奨し、採用しなかった選択肢も伝えます。

• continue — 残りの指摘事項は局所的で、減少しています。
• redesign — 同じ境界で失敗が続いており、1つのスライスを変更する必要があります。
• narrow — スコープの一部は、検証済みの状態でリリースでき、残りは保留できます。
• accept-limitation — 追加のラウンドを重ねるより、残存リスクを文書化するほうが低コストです。
• stop — 前提が誤っているか、もはやコストに見合いません。

現在のスコープ内で行う、元に戻せる技術的な修正は担当中のロールの役割です。そのロールに差し戻してください。プロダクトの境界の変更、スコープの縮小、制約の受け入れ、停止は人間が決定します。推奨は行いますが、自ら決定してはならず、仕様、候補、レビュー判定を自分で変更してもなりません。

このスキルから Issue を作成することはありません。Meta-O の文面で確認された摩擦は推奨事項としてユーザーに伝え、Issue を作成するかどうかはユーザーが決定します。

Meta-O の呼び出し

• なし