pstack-omp

OMP での pstack

唯一のルーターは poteto-mode です。プレイブック、正規ロール、ステップの順序、ライフサイクルプロトコルを選択します。このアダプターは、それらの選択を OMP 向けに変換するだけです。プレイブックを選択したり、プレイブックのインデックスを繰り返したり、プレイブックのゲートを変更したりすることはありません。

このスキルが有効な間は、そのロールマップが pstack 実行に関する固有の契約です。一般的な OMP の指示は、pstack の作業以外では引き続き有効です。

正規ロールマップ

以下の OMP エージェント名をそのまま使用してください。

正規ロール	OMP エージェント
explorer	scout
watcher	scout
planner	task
designer	task
reviewer	reviewer
researcher	librarian
synthesizer	reviewer
implementer	poteto-agent
owner	poteto-agent
mechanical	sonic

ロールの責務は skill://poteto-mode に記載されています。この表はエージェント名だけを定めます。

正規 OMP 名簿に含まれるエージェントは限定されています。

scout
reviewer
security-reviewer
librarian
task
sonic
poteto-agent
comment-sicko
seance

正規ルーティングされたタスク項目の agent 値には、同梱されている以下の名前のいずれかを指定する必要があります。正規ロールのラベルやモデルのエイリアスはエージェント名ではありません。task はデフォルトのワーカーなので、これを指定する場合は agent を省略してください。

poteto-agent は poteto のスタイルで implementer と owner の作業を行います。comment-sicko は、直接その名前を指定しているインポート済みスキルのコメントを監査します。

計画と設計

組み込みの計画サブエージェントに関するインポート済みの警告は、スキルの契約を迂回するソースホスト側の仕組みについて述べています。この OMP バージョンには、同梱された plan エージェントも designer エージェントもありません。正規ロールの planner と designer の作業には task を使用します。技術計画やビジュアルおよびインタラクション設計などの専門性はブリーフに記載し、ソースホストのサブエージェント用フィールドは指定しません。

セキュリティレビュー

独立したセキュリティレーンには security-reviewer を使用します。通常のコードレビューも必要な場合は、読み取り専用にし、通常のコードレビューとは分けてください。後続の reviewer セッションでは確定済みのレポートを統合できますが、主要なセキュリティレビューの代わりにはなりません。

タスクの契約

すべての task 呼び出しはルートが実行します。子は task を呼び出したり、別の子を開始したり、ユーザーに直接依頼したりしてはいけません。すべての子ブリーフの FORBIDDEN に Do not call task or start subagents を記載してください。task.maxRecursionDepth はネストを許可するため、ツリーをフラットに保つのはホストではなくブリーフです。

子は親との会話がない状態で開始します。すべてのプロンプトは単独で意味が通る必要があります。子には、設定済みのワークスペース、コンテキストファイル、スキル、OMP が提供する承認済みの計画リソースが渡されます。

呼び出し形式

1 回の task 呼び出しはバッチです。context は、すべての子のシステムプロンプトに展開される、共有の不変な背景情報です。参加者は tasks[] に記述します。単一のディスパッチも 1 項目のバッチであり、別のスキーマではありません。

{
  "context": "Repository root, base SHA, frozen artifacts, constraints, and verification context shared by every item.",
  "tasks": [
    {
      "name": "ParserOverflowFix",
      "solutionSpace": "one fix: bounds check in parse_header, call site given",
      "task": "GOAL\n...\n\nROLE\n...\n\nSCOPE\n...\n\nCONTEXT\n...\n\nACCEPTANCE\n...\n\nVERIFY\n...\n\nTIMEBOX\n...\n\nFORBIDDEN\n...\n\nREPORT\n...\n\nSTANDING\n..."
    }
  ]
}

各項目には task と solutionSpace が必須です。solutionSpace では、子の問題がどの程度オープンエンドかを述べます。作業量ではなく、修正方法が決まっているか、原因や設計にどの程度の未確定事項があるかを記述します。兄弟項目や調整については触れません。

name は CamelCase で最大 32 文字とし、呼び出し内で一意にします。これは子の agent:// 識別子になるため、1 時間後でもルートが認識できる名前を選んでください。

任意フィールドは、対応する設定が有効な場合にのみ使用できます。記述する前に設定を確認してください。

• isolated を使用するには task.isolation.enabled が有効であり、かつプランモードではないことが必要です。専用のワークツリーを必要とする作業者にはこれを使用し、その後、OMP が報告したパッチ、ブランチ、または適用済みの変更を検証してください。同じワークスペースで後続の依頼を受ける必要がある長期稼働のオーナーは、非分離のままにしてください。
• effort（lo、med、hi）を使用するには task.enableEffort が有効である必要があります。無効の場合、推論の深さは呼び出しではなく、エージェントに設定されたモデルのロールによって決まります。
• outputSchema と schemaMode を使用するには task.structured が有効である必要があります。
• tools を指定すると、eval で定義されたツールを子に公開できます。

タスク項目に model フィールドを指定してはいけません。OMP にそのようなフィールドはありません。

ブリーフは短くまとめ、まとまった内容は親と子が共有する local://<name>.md 経由で渡してください。大きなペイロードをインラインで貼り付けないでください。

バッチ処理パネル

独立した参加者には、1 回のバッチ呼び出しを使用します。

{
  "context": "Shared immutable repository, base SHA, artifacts, constraints, and verification context.",
  "tasks": [
    {
      "name": "CandidateA",
      "solutionSpace": "architecture open; candidate A explores the event-sourced shape",
      "task": "Standalone brief for architecture candidate A."
    },
    {
      "name": "CandidateB",
      "solutionSpace": "architecture open; candidate B explores the state-machine shape",
      "task": "Standalone brief for architecture candidate B."
    }
  ]
}

各 name は一意です。context には、共通で変更不可の資料を含めます。各項目には、正確な役割、対象範囲、受け入れ基準、検証方法、禁止事項、報告形式を引き続き明記します。

すべての参加者を 1 回のバッチで開始してから、いずれかの判定を確認します。作業者は、分離されたワークスペースまたは重複しない出力パスを使用します。レビュー担当者の作業を開始する前に候補成果物を確定します。別の統合担当セッションを開始する前に、レビュー報告を確定します。

task.maxConcurrency は、同時に実行できる子タスクの上限をデフォルトで 32 に設定します。これを超えるバッチは失敗せず、キューに入ります。

バックグラウンドでの完了と追加対応

起動したタスクはバックグラウンドジョブとして実行され、結果は自動的に届きます。返されたジョブ ID とエージェント ID を記録してください。届いたプレビューは途中で切り詰められている場合があります。

• 完全な結果は agent://<id> から読み取ります。子階層にあるタスクの識別子は agent://<parent>.<child> です。
• 報告が不完全、曖昧、または不審な場合は、history://<id> からセッションのトランスクリプトを読み取ります。
• read proc:// は実行中のジョブを一覧表示し、read proc://<id> は結果の受け取りを消費せずにジョブを調べます。
• write agent://<id> は、範囲内の修正、回答、承認、または次の連続したフェーズを 1 回送信します。これにより、待機中のセッションが再開します。agent://all は全員にブロードキャストする書き込み専用の宛先です。
• write proc://<id>/kill は、古くなった作業、置き換えられた作業、または範囲を逸脱した作業をキャンセルします。
• ルートが何もできずにブロックされている場合に限り、wait を呼び出します。ポーリングはしないでください。
• レビュー担当者を、望ましい結論へ誘導してはいけません。
• 重複した終了通知は無視し、古い成果物の世代は受け入れないでください。

タスクの結果は証拠であり、完了を意味するものではありません。ルートは成果物を確認し、検証を実行します。

ブリーフの形式

ブリーフに次の内容が含まれるまで、タスクを割り当ててはいけません。

GOAL
見知らぬ人でも実行できる、一文で表した成果。

ROLE
正式な役割、対応する OMP エージェント、権限、期待される姿勢。

SCOPE
書き込み可能なパスと書き込み不可のパス、正確な対象範囲または競合時の担当範囲、該当する場合はワークツリーとブランチ、すべての出力先。書き込み担当を 1 名に限定することを明記します。

CONTEXT
リポジトリのルート、関連するソースパス、ベース SHA、確定済みの成果物、有効なスキルとプレイブックのパス、確定した前提、既知の注意点。

ACCEPTANCE
確認可能な結果を 1 行に 1 つずつ記載します。

VERIFY
正確なコマンド、フィクスチャ、実行時のプローブ、比較対象のベースライン、環境要件、既知の偽陽性・偽陰性のリスク。

TIMEBOX
おおよその上限時間。上限に達したら、対象範囲を広げずに部分的な証拠を返して停止します。

FORBIDDEN
最低限、子タスクの呼び出し、サブエージェントの起動、対象範囲外の修正、依頼されていない移行、担当範囲外の共有パスの編集、マージ、ユーザーへの直接質問、検証を実行していない状態での完了宣言を禁止します。

REPORT
PASS | ISSUES | BLOCKED、意味のあるセッション名、該当する場合はブランチと正確な SHA、判定と証拠、変更したファイルまたは成果物、実際に実行した検証コマンドと結果、逸脱、未解決のリスク、親タスク側で必要な対応を必ず含めます。

STANDING
有効なプレイブックに常設ポリシーの記述がある場合は、その文面を一字一句そのまま記載します。

標準プロトコル

範囲を限定したセッション

1. 独立したブリーフを 1 つ作成します。
2. 対応するエージェントでタスクを 1 つ開始します。
3. 意味のある名前、エージェント ID、ジョブ ID、役割、対象範囲、分離方式、ベース SHA、想定する成果物を記録します。
4. 非同期の結果が届いたら受け取ります。
5. agent://<id> を読み取り、必要に応じて history://<id> を調べます。
6. 同じ作業単位の範囲内に限り、write agent://<id> で修正を 1 回だけ送信します。
7. 成果物を確認し、約束された検証を独立して実行します。
8. 報告された出力を親タスクが検証した後にのみ、その作業単位を受け入れます。

役割または作業単位を変更する場合は、新しいタスクが必要です。

パネル

1. 独立した作業範囲または競合する選択肢に分割し、参加者ごとにタスク項目を1つ割り当てます。
2. 結果を受け取る前に、すべての参加者を1つのバッチで開始します。
3. 到着順ではなく、意味のある名前と識別子で参加者を追跡します。
4. 結果は自動配信させます。他に進められる作業がない場合に限りwaitし、放棄した選択肢はwrite proc://<id>/killで明示的にキャンセルします。
5. 重複した終了通知は無視します。
6. 実装成果物、ブランチ、head SHA、レポート、ハッシュを凍結します。
7. 候補を凍結した後に限り、独立した各レビュアーを新しいバッチで開始します。
8. 統合が必要な場合は、別のreviewerを開始する前に判定を凍結します。
9. 統合結果は助言として扱います。選択と検証はルートが行います。

同じセッションに実装担当者、レビュアー、統合担当者を混在させないでください。レビュアーに更新中のheadを追わせないでください。

長期担当オーナー

1. 完全なオーナー向けブリーフを渡し、隔離されていないpoteto-agentセッションを1つ開始します。
2. そのエージェントIDを記録して再利用します。同じ作業単位に対して同じ立場のオーナーを追加で開始しないでください。
3. オーナーは割り当てられたブランチとパスだけで作業し、子エージェントを開始しません。
4. write agent://<id>でのフォローアップは、次の連動するフェーズ、担当範囲内の修正、証拠に基づいて解決した回答、または明示的な許可に限ります。
5. 検証の境界ごとに、終了レポートを求めます。
6. 次のフェーズを許可する前に、その境界を独立して検証します。
7. 所有権の違反、古い世代、または担当範囲の逸脱を伴う終了があった場合は、作業を停止します。

ワンショット監視役

1. バックグラウンドでscoutタスクを1つ開始します。
2. ブリーフには、対象のブランチ、head SHA、世代、監視対象の述語、停止条件、制限時間を正確に記載します。
3. 意味のあるイベントを1つと、終了レポートを求めます。
4. 世代が一致しなくなったレポートは破棄します。
5. 世代が変わるたびに、新しい監視役を開始します。
6. 停止条件を満たしたとき、または作業が別のものに置き換えられたときは、監視を停止します。

監視役は状況を観察します。修正、マージ、許可、変更されたheadへの無言の追従は行いません。

やり取りと判断

子エージェントは、ソース、既定のポリシー、凍結済みの証拠、またはブリーフに基づいて不確実性を解消します。それらで解決できない場合は、最も安全で取り消し可能な解釈を採用して、その前提を報告するか、収集した証拠と不足している判断事項を正確に示してBLOCKEDを返します。

ルートは子エージェントからの質問を解決し、その回答をwrite agent://<id>で既存のエージェントに送ります。ユーザーへの確認は、実際の製品上の好み、利用できない権限、または既定の指示で認められていない取り消し不能な操作についてのみ行います。

所有権と検証

• ブランチ、ワークツリー、可変状態、出力パスごとに書き込み担当者を1人にします。
• 実装、レビュー、判断、統合は別々のセッションが担当します。
• タスクは割り当てられた作業単位と役割の範囲内にとどめます。
• 出力が構造的に分離されていない場合、並行して書き込む担当者は隔離します。
• 作業者自身のレポートは、その作業の検証にはなりません。
• ブランチ、ベースSHA、正確なhead SHAまたは成果物の世代を記録します。
• 型チェックだけの証拠より、動作の証明を優先します。
• 新しいコミット、リスタック、競合解消、パッチの適用によって新しい世代が生まれた場合、以前の判定は無効になります。
• 判定者と統合担当者は助言を行います。選択、ユーザーとのやり取り、外部への書き込み、マージ、削除、最終的な判断はルートが担います。
• モデルの独立性を主張できるのは、返された解決済みモデルとフォールバックのメタデータに基づく場合に限ります。

モデルのルーティング

OMP は、現在の設定（modelRoles、task.agentModelOverrides、エージェント定義、通常のフォールバックを含む）に基づいてタスクエージェントを解決します。エージェントの選択とモデルの選択は別々の判断です。

タスク項目に model フィールドを追加しないでください。モデルのエイリアスを agent の値として使用しないでください。ルーティングは /skill:setup-pstack で設定してください。このコマンドは、検出されたカタログに対してすべてのセレクターを検証した後、アクティブなプロファイルの config.yml に両方のレコードを書き込みます。

/skill:setup-pstack --show は、現在有効なエージェントとロールの対応を表示します。これらは設定であり、タスクのペイロードフィールドではありません。プレイブックでモデルの独立性が必要な場合は、各子エージェントが報告する解決済みのモデルを確認してください。2 つのパネルエージェントが同じモデルに解決された場合は、セカンドオピニオンだと主張せず、その旨を明記してください。

執筆

すべての返信、概要、レポート、レビュー、タスクの割り当て、コミットメッセージ、およびエージェント向けの編集に unslop（skill://unslop）を適用してください。