sidekick

name	sidekick
description	user invoke only
summary	外部プロセス(codex または claude または gemini)に、コード diff に限らず設計方針・技術選定・文章・意思決定など任意のテーマについてセカンドオピニオンを求めます。意見聴取専用で、外部ツールによる修正の自動適用はさせません。
argument-hint	[--claude|--codex|--gemini] [-a|--adversarial] <相談したい内容>

以下の手順に従って、外部プロセスにセカンドオピニオンを求めてください。

【重要】 外部プロセスを起動する前に external-agent-invocation スキルを読み、オプションの解釈・コマンドの形・落とし穴・重大度の書かせ方はそちらに従ってください。このスキルには、セカンドオピニオンに固有の部分だけを書いています。

• 重要度のラベル: 「重大な懸念」（対応を強く検討すべき問題）/「参考意見」（提案・アイデアレベル）
• このスキルは意見聴取専用です。外部プロセスに修正・編集作業をさせないでください。指摘は指摘として受け取り、実際に手を入れるかどうかはユーザーが判断します。claude を使う場合は編集を許可しない起動にしてください。

【手順】

1. 相談内容の特定:

   • {{args}} からオプションフラグを除いた残りを相談内容とします。
   • 除いた結果が空の場合は、何について意見を聞きたいかをユーザーに確認してください。

2. 相談内容の解釈とコンテキストの用意: 相談内容の性質によって、外部プロセスに渡すべき情報の形が変わります。何についての相談かを見極めてください。

   • コードの変更を指している場合（例: 「この diff について」「未コミットの変更について」）: コミット済みである必要はありません。git diff や git log -p <範囲> を外部プロセス自身に実行させる指示にし、対象範囲（コミットハッシュ範囲やブランチ名）を明確に伝えてください。
   • 既存ファイルを指している場合（設計書・草稿・既存コードなど）: ファイルパスを特定し、存在を確認してください。内容は stdin 経由で渡すか、外部プロセスに直接読ませる指示にします。
   • 抽象的な問い・意思決定・アイデアの場合（コードでもファイルでもない相談）: 相談内容と、判断に必要な背景（関連するファイルパス、制約、これまでの検討状況など）を自分で簡潔にまとめ、プロンプトに埋め込んでください。

3. 外部プロセスへの依頼:

   • プロンプトに含める指示内容:

     以下の内容について、[判定したモードに応じて "Adversarial Review（まず反証を試みてください）" または "セカンドオピニオン"] をお願いします。
     
     【相談内容】
     [相談内容、および必要な背景・対象の参照方法]
     
     【相談の位置づけ】
     [探索段階のアイデアなのか、採用直前の最終確認なのかを1行で記載]
     
     【指示】
     1. 相談内容に応じて必要な観点（技術的妥当性、リスク、代替案、可読性、設計の一貫性など）から意見を述べてください。
     2. これは意見聴取のみが目的です。ファイルの編集や修正作業は一切行わないでください。問題に気づいても、指摘に留め、自分で直そうとしないでください。
     3. 各指摘には重要度として「重大な懸念」か「参考意見」かを必ず明記してください。重大な懸念に該当する指摘が一つも無い場合は「重大な懸念なし」と明記してください。
     

4. 結果の報告:

   • 外部プロセスの意見を要約し、ユーザーに報告してください。報告冒頭での重大な懸念の明示は共通手順のとおりです。
   • 意見聴取専用のため、通常はワークツリーに変更は発生しません。念のため git status を実行し、意図しない変更が発生していないか確認してください。万一発生していた場合は、内容をユーザーに報告した上で元に戻してください。

【同じ対象で複数ラウンド回す場合】

指摘を反映しては再依頼する収束ラウンドでは、次を守ってください。

• 終端は指摘の性質で判断します。「設計の選択肢」に対する指摘（成果物の中身が変わる）から、「表現の精度」に対する指摘（書いた文章の言い回しへの指摘）へ移った時点を終端とみなしてください。後者に入ると、1ラウンドごとに追記した文言が新しい指摘を生むため収束しません。ラウンド数ではなく指摘の性質で判断してください。
• 終端と判断したら、残る指摘は「実装時にテストで固定する契約」等として成果物へ記録し、ラウンドを打ち切ってユーザーへ判断を仰いでください。
• 予防として、レビューへ出す文書に絶対量化子（「いかなる」「一切」「必ず」）を使わず、対象を列挙して書いてください。「一切ブロックしない」のような表現は下位機構（内部ロック、ライブラリの同期処理等）が必ず反例になります。「次を行わない: A / B / C」の列挙型で書けば、この種の精度指摘を先回りできます。
• 2ラウンド目以降は、依頼文に判定対象を絞る指示（「新規の網羅的レビューは不要」「前回の指摘が解消したかの判定だけ」「既に解消と判定された論点の再検討は不要」）を明記してください。指示が無いと毎回スコープが広がり直します。