対話または既存トークンファイル(W3C DTCG / CSS variables など)をもとに、プロダクトに合った DESIGN.md を生成する。AIがつくるUIに一貫性を。
ask
別系統のモデル(Claude Code なら Codex、Codex なら Claude Code)に問題だけを渡して 独立に解かせ、自分の案と突き合わせる。実装前の設計判断や、同じ箇所で修正が 2 回続いて抜けられないときに使う。「セカンドオピニオン」「別のモデルに聞いて」 「他の見方」「行き詰まった」等で使用。
コードレビューには使わない(/codex:review 等を使う)。
含まれるファイル(6)
- SKILL.md8.4 KB
- references/brief-format.md3.8 KB
- references/output-format.md4.1 KB
- references/trigger-rules.md1.8 KB
- scripts/ask.sh14.2 KB
- scripts/ask.test.sh28.7 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Second Opinion — 別モデルの独立した見解
設計原則
- 問題は渡す、答えは渡さない。 相手に自分の案を見せると相手も追従する。自分の案は送らず、相手の呼び出し中は
.context/second-opinion/配下(ブリーフ本体を除く)もリポジトリから見えない場所へ退避する - 一致は検証済みではない。 別モデルでも誤りは相関する。一致点も根拠を事実に遡れるかで見る
- 決めるのは人間。 表を出して終わる。どちらを採るかをこのスキルは決めない。批判ラウンドを含め、相手の指摘に「採用」「却下」をこのスキルが書くことはない
- 実行は手動。 文脈検知で提案はするが、勝手に外部モデルを呼ばない
いつ使うか
- 方針・アプローチ・トレードオフを決めようとしているとき(実装前)
- 同じ箇所への修正が 2 回続いて解決しないとき(問題の見立てを疑う)
- 実装後に「なぜこう作ったか」の妥当性を別の頭で見たいとき(たまに)
いつ使わないか
- コード差分のレビュー(
/codex:review、/code-review) - 答えが 1 つに定まる事実確認(検索や公式ドキュメントで済む)
- typo 修正・lint 修正など判断を含まない作業
実行フロー
Phase 0: ブリーフ作成
-
会話から「問い・利用者が決めた条件・確認済みの事実・未確認の前提・関連ファイル」を抜き出す(節の書式は brief-format.md)
-
brief-format.md のテンプレートで
.context/second-opinion/brief-<YYYYMMDD-HHMMSS>.mdに書く -
自分の現時点の案と理由を
.context/second-opinion/own-<同じ timestamp>.mdに書く。相手には渡さない。案が無い場合は「未定」と書く -
brief-format.md の自己検証を行う。自分の案・仮説・解釈が混ざっていたら書き直す
-
ユーザーに見せて承認を取る:
別モデルに以下を聞きます。自分の案は渡していません。 - 問い: 〜 - あなたが決めた条件: 〜 - 未確認の前提: 〜(私が置いた仮定です。違っていたら教えてください) - 渡すファイル: 〜 ブリーフ全文: .context/second-opinion/brief-<timestamp>.md よいですか?
Phase 1: 独立回答
scripts/ask.sh --brief <ブリーフのパス>(SKILL.md のあるディレクトリ基準。プラグインとしてインストールされている場合はプラグインの skills/ask/scripts/ask.sh)を実行する。stdout が相手の回答、stderr の answer: 行が保存先。
実行時は呼び出し元を常に明示する。Claude Code から使っているなら --from claude、Codex から使っているなら --from codex。環境変数による自動判定は補助であり、頼り切らない。
呼び出し中は .context/second-opinion/ 配下のうちブリーフ本体以外がリポジトリ外へ一時退避され、終了後に元の場所へ復元される(stderr に hidden: / restored: の行が出る)。stderr に 復元に失敗しました の行が出たら、回答は保存・出力済みでも終了コードは 1 になる。他の何より先に、そこに書かれた保持先のパスをそのままユーザーに見せる。
終了コードごとの対応:
| コード | ユーザーに返す文 |
|---|---|
| 0 | (Phase 2 へ) |
| 2 | 「実行環境を判定できませんでした。--from claude(Claude Code から実行中)か --from codex(Codex から実行中)を付けて再実行します」と言い、確認して再実行 |
| 3 | 「回答は保存されましたが、相手の実行中に作業ツリーが変わりました。git status を確認してください」。Phase 2 は続ける |
| 4 | 「相手の CLI が見つかりません。Codex CLI は https://developers.openai.com/codex/cli 、Claude Code は https://code.claude.com/docs を参照してインストールしてください」 |
| 5 | 「相手の CLI の認証が切れています。codex login または claude でログインしてから再実行してください」 |
| 6 | 「相手が時間内に応答しませんでした。ブリーフの関連ファイルを減らすか、--timeout を延ばして再実行します」 |
| 1 | stderr の内容をそのまま見せる |
Phase 2: 突き合わせ
output-format.md の表を .context/second-opinion/result-<ブリーフと同じ timestamp>.md に保存し、同じ内容をユーザーに見せる。列は | 論点 | 自分 | 相手 | 比較 | 根拠を事実に遡れるか |。比較 は 一致 / 条件付き一致 / 相違 / 片方のみ / 情報不足 の 5 値のみ(使い分けは output-format.md)。
- 「自分」列は own ファイルから転記する。相手の回答を見て書き換えない
- 相手の原文は全文併記。要約しない
- 相違点で自分の側に寄せる表現をしない
表の後にこの順で書く:
### 相違点の理由— 各項目で「相手が明言した理由」と「元のモデルの推測」を区別する### 判断を左右する未確認事項— 最大 3 件。各件に「何を確認すれば決められるか」と「どちらの結論に効くか」を添える。無ければ「なし」### 相手が参照した資料— 相手の回答末尾の申告を転記。申告が無ければ「申告なし」。自分の案(own ファイルや過去の結果)を読んだ形跡があれば、その旨を書き「独立回答として扱わない」と明記する### 相手の原文— 全文- 定型 2 行(必ず付ける):
どちらを採るかは人間が決める。一致は「両者が同じ結論」であって「検証済み」ではない。
Phase 3: 批判ラウンドの提案
次のいずれかのときだけ、1 行で提案する。それ以外は提案しない:
### 判断を左右する未確認事項に、自分の案を見せて検討させれば進む項目がある- 議題が事業全体・セキュリティ・後戻りしにくい構造に触れる
「「<確かめたいこと>」を確かめるために、自分の案を見せて検討させますか?(往復がもう 1 回増えます)」
承認されたら:
- ブリーフに「私たちの案」節を足した第 2 ブリーフを
.context/second-opinion/brief-<timestamp>-critique.mdに書く scripts/ask.sh --brief <第 2 ブリーフ> --round critiqueを実行する- output-format.md の「批判ラウンド」を Phase 2 で保存した result ファイル(
.context/second-opinion/result-<timestamp>.md)に追記する。列は| 相手の指摘 | 元のモデルの見解 | 未解決事項 | 利用者の決定 |で、利用者の決定列は必ず空欄にする。元のモデルは「妥当」「一部妥当」「前提が違う」等の見解のみを書き、採用・却下は書かない。相手の原文も全文併記する
文脈検知(提案のみ)
trigger-rules.md の 2 パターンを検知したら 1 行で提案する。実行はしない。それ以外は沈黙する。
参照ファイル
| ファイル | 内容 |
|---|---|
| brief-format.md | ブリーフの書式、渡す/渡さないの線引き、自己検証 |
| output-format.md | 突き合わせ表と批判ラウンドの書式 |
| trigger-rules.md | 文脈検知で提案する条件と、しない条件 |
scripts/ask.sh --help | 呼び出しスクリプトの引数と終了コード |
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
セッション間のコンテキストを構造化して保存する。 「引き継ぎ」「セッション保存」「handoff」「コンテキスト保存」等で使用。 通常は自動保存(L1/L2)で十分。明示的に高品質な保存をしたいときに呼ぶ。
世の中のベストプラクティスをWeb検索・SNS検索・ツール検索で調査し、鮮度・信頼性・多角的視点を 考慮して構造化レポートにまとめる。「ベストプラクティスを調べて」「best practice」「最適な方法」 「推奨される方法」「どうするのが正解か調べて」「世の中ではどうやっているか」等で使用。 技術・ビジネス・教育・デザイン等あらゆるドメインに対応。
多分野の専門家を動的に選定し、構造化された議論で多角的な評価・提言をまとめる。 「専門家に聞きたい」「レビューして」「多角的に評価して」「議論して」等で使用。 Webサイト、コード、事業戦略、デザイン、組織設計等あらゆるドメインに対応。