ce-pov

見解を形成する

対象に即した形で、明確な見解を示します。外部採用に関する段階評価付きの判定、文書に対する包括的な見解、または提示されたアプローチ群に対する立場を示します。対象とは、プロンプトまたは会話の中でこのスキルが呼び出されたものです。見解の形成と調整は、読み取り専用で行ってください。帰属と必要な開示を添えて見解を提示するか、明示的な阻害要因を返した時点で完了です。競合する解決策の検討には ce-bakeoff、機会の探索には ce-ideate、目標の設定には ce-brainstorm を使用してください。情報源の鮮度を考慮し、現在は2026年です。

根拠の確認は必須です

プロジェクト固有の状況を踏まえて十分な根拠を得ていない見解を、決して提示しないでください。 すべての対象で、references/method.md に定められた最低限のプロジェクト根拠（プロジェクト最低基準）を満たす必要があります。外部採用の判定では、さらに同ファイルに定められた外部根拠の基準をすべて満たす必要があります。会話中の主張は、根拠の代わりにはなりません。

利用者とやり取り

想定される利用者が活用できる形式で、根拠に裏付けられた立場を提示してください。結論から始め、根拠、重要なトレードオフ、不確実性、判断を左右する条件を明示してください。対象を再確認しなくても識別内容を理解できるようにしてください。進捗を伝える際は、何を確認しているのか、どのモデルまたはヘルパーが確認しているのかを平易な言葉で述べてください。その際、このスキルの内部的な仕組み（ペイロード、スカウト、ドシエ、ティア、ラウンド番号、一時ファイル）は決して名指ししないでください。

進行中のワークフローに参加する場合は、結果を返し、その後の処理は呼び出し元のワークフローに委ねてください。その返答に、追加対応やパネルの提案を加えないでください。ただし、明示的なオラクルまたは指名されたピアの依頼がある場合は、呼び出し元のワークフローからの依頼であってもパネルを実施してください。

問いを特定して結果を返す

依頼と会話から問いを特定し、確認可能な事実を調べてください。評価対象を特定するためにユーザーへ質問してはいけません。情報が欠けていることで推奨内容が変わり、その情報を見つけられない場合は、ブロック — コンテキスト不足を返してください。不足している情報、その情報が重要な理由、解決に必要な内容を説明してください。確認を求めるか、別の対応を取るかは呼び出し元のエージェントが決定します。ユーザーが ce-pov を直接呼び出した場合でも、別のエージェントが呼び出した場合でも、この方針を適用します。別途、非対話モードを設ける必要はありません。

成果物ルート

<root>/ で始まるパスを初めて組み立てる際に、<root> を解決してください。<root>/solutions/ を読み込む場合も、パスの組み立てに該当します。解決したパスをスカウトに渡し、設定値そのものは渡さないでください。Git 管理されていないプロジェクトには <root> がないため、過去の意思決定の調査ではローカルの ADR と設計文書を使用します。

成果物のパスを組み立てる前に、CE 成果物ルート <root> を解決してください。

• <repo-root>/.compound-engineering/config.yaml の docs_root のみを読み取ってください（<repo-root> は git rev-parse --show-toplevel の結果です）。config.local.yaml からは読み取らないでください。設定がなければ、従来どおり <root> は docs です。
• 設定値がある場合は検証してください。リポジトリ相対のディレクトリであり、シンボリックリンクを解決した実パスがリポジトリ内にとどまり、リポジトリのルートでも .git/ 配下でもない必要があります。条件を満たさない場合は、docs_root とその値を明示してエラーを返してください。決して docs にフォールバックしてはいけません。
• <root> を唯一の成果物保存場所として使用してください。存在しない場合は作成し、パスはそれぞれ <root>/<subdir> の形式で組み立て、このスキル固有のサブディレクトリを使用してください。docs を併せて読み込むことも、読み込む場所として使用することも禁止です。

フェーズ 0：枠組みを定めて分類する

根拠を確認する前に、今すぐ references/intake.md を読んでください。 出力モード、呼び出し元のワークフローから渡される内容、方向性と枠組み、規模の決め方、質問に明確な答えがない場合の対応が定義されています。対象と POV の意図（採用／移行／比較／これは自分たちの問題か／ドキュメントの評価／アプローチの選定／解説）をここで確定してください。別のスキルに属する意図はインテークの段階で終了し、続行する意図については、判断をどの程度元に戻せるかを記録します。このスキルが適切かどうかに疑問がある場合は、references/boundaries.md を読んでください。

フェーズ 1：根拠を確認する

いずれかの方法で根拠を確認する前に、今すぐ references/grounding.md を読んでください。 モデルの階層（POV の推論そのものは委任しません）、一時ファイルの保存先、調査担当に渡す情報と実行数、各ステップで必要となる機能、確認済みの事実と未確認の事実を分けて扱う方法が定義されています。

調査担当には、汎用的なリポジトリの概要ではなく、候補に固有の最新の根拠を直接調べさせてください。調査担当はそれぞれのコンテキスト内で調査し、資料のパスと要旨を返します。必要に応じてその資料を読みます。判断の根拠となる事実の所在がすでに特定されている場合は、調査担当を派遣するのではなく、権威ある情報源を対象を絞って読み、確認してください。対象が曖昧な場合やノイズが多い場合は、調査担当を派遣します。会話で示された主張は確認すべき手がかりであり、それ自体で検証済みとは見なしません。過去の判断の確認（<root>/solutions/、ADR、設計ドキュメント）は、どちらの方法でも必須です。

判断に未解決の挙動や設計上の根拠の説明が必要な場合は、ce-explain を呼び出してください。質問、その範囲、そしてその説明が役立つ判断を渡します。調査を繰り返すのではなく、十分で最新の根拠を使ってください。引用された調査結果は推奨の権威ではなく、同じ根拠基準に照らして評価すべき証拠として扱います。判断の責任はここで担ってください。ce-explain が利用できない場合は、根拠を直接集めるか、何が不足しているかを報告してください。

フェーズ 2：根拠を検証する

POV について推論する前に、今すぐ references/method.md を読んでください。 Verify と POV の手順、懐疑的な姿勢、階層分け、根拠の確認方法が定義されています。確認済みの根拠に対して、その確認を適用してください。根拠が不十分な場合、どの対象の形状でも確信を持った結論を返してはなりません。その場合に各形状が返すべき結果は、同じリファレンスに記載されています。

フェーズ 3：見解

まず、references/method.md の有効な対象形状の契約に従って、ce-pov 独自の POV を形成します。ただし、これは出力しないでください。その立場を固定します。独立したピアの初期コンテキストには含めず、その立場への批評が依頼された場合、または後の調整ラウンドでのみ開示してください。

パネルの依頼とは、呼び出しコンテキストのどこかで、パネル、クロスチェック、または oracle など、他のモデルへの相談や調整を明示的に求めることです。それを断る場合や、単に言及するだけの場合は依頼に当たりません。パネルが依頼された場合、またはパネルなしで形成した POV について先回りして提案できる可能性がある場合は、参加するかどうか、または提案するかどうかを決める前に references/cross-model-panel.md を読んでください。結果をまとめる前に、パネルの分岐を完了してください。パネルが依頼された場合の POV では、参加したピア、または参加者がいなかった場合はその理由を記載します。パネルの依頼がない POV には、パネルについての注記を付けません。

その後に限り、references/method.md が求める内容で見解を提示してください。想定される用途に合わせて提示方法を調整し、資料一式やピアの生の出力を再掲するのではなく、根拠を引用してください。

フェーズ 4：提示して引き継ぐ

成果物は判断であり、実装ではありません。呼び出し元のワークフローには、結果と制御を返します。文書の作成や続行を依頼された場合は、references/followup.md を読んでください。成果物の提示方法と、後続のアクションに必要な権限が定義されています。POV を完了するために、次のステップを選ばせる必要はありません。