meta-prompting

メタプロンプティング

/commands または自然言語で意思決定をストレステストします。コマンドは左から右に組み合わせます：/verify /adversarial。状況に応じて自動的にトリガーし、適用したパターンを記載します。結論、決定的な証拠、代替案、不確実性、および該当するマーカー（例：VERIFIED ANSWER:、REVISED ANSWER:、信頼度レベル）を含む意思決定記録を出力します。

パターン

/think | /show：簡潔な意思決定記録を提示します。結論、決定的な根拠、検討した代替案、却下理由、重要な不確実性を含めます。/think doubt を指定すると、重要な各結論を覆し得る根拠を示します。

/adversarial | /argue：回答の後に、反対意見を最も強い形で提示します。影響の大きい順に、最も強力な反論を3つ挙げます。盲点と明示されていない前提を特定します。

/constrain | /strict：厳しい制約を適用します。最大3文、出典を引用し、曖昧な表現は使いません。インラインで上書きするには、/constrain 5 sentences と指定します。

/json | /format：有効な JSON コードブロックで回答し、求められない限り前後に文章を付けません。既定のスキーマ：

{"analysis": "string", "confidence_score": 85, "methodology": "string", "limitations": ["string"]}

任意のキー：/json {keys: summary, risks, recommendation}

/budget | /deep：根拠、最も強力な反論、代替案、トレードオフ、不確実性を含む、約500語の詳細な意思決定記録を作成し、その後に最終回答を明確に分けて記載します。

/compare | /vs：選択肢を表で比較します。既定の比較項目は、速度、精度、コスト、複雑さ、保守性です。任意の項目を指定するには、/compare [dim1, dim2] と入力します。

/confidence | /conf：各主張の確信度を0～100で評価します。70未満は SPECULATIVE として示します。HIGH（85以上）、MEDIUM（70～84）、LOW（70未満）の段階に分けます。置いた前提を記載し、それぞれの確信度を1～10で評価します。

/edge | /break：アプローチが破綻する入力やシナリオを5つ以上挙げます。コードの場合：null／空、並行処理、オーバーフロー、エンコーディング、認証の回避。戦略の場合：市場環境、タイミング、依存関係。 自動的に適用される状況：セキュリティ、検証、解析のコンテキスト。

/verify-think | /check：次の3段階で進めます。（1）回答：直接回答する。（2）疑問を提示：誤りである可能性を3つ挙げる。（3）検証：それぞれを調べ、必要に応じて修正する。最終回答には VERIFIED ANSWER: または REVISED ANSWER: と明記します。Claude Code のスラッシュコマンド /ia-verify が実行する PR 前の完全な検証パイプラインとは異なります。 自動的に適用される状況：アーキテクチャ上の意思決定、重大な選択、「自分は正しいか？」という問い。

/flip | /alt：既定のアプローチを特定して説明します。次に、異なる仕組み（異なるデータ構造、レイヤー、抽象化）を使う代替案を提案します。代替案が既定のアプローチより優れる条件を説明します。上書きするには、/flip 3 と指定して上位3つの代替案を求めます。 自動的に適用される状況：「簡単な」答えが大規模な利用で破綻する可能性があるアーキテクチャ上の意思決定。

/assumptions | /presume：回答の前に、質問やタスクに含まれる暗黙の前提をすべて列挙します。その後、前提を明示したうえで回答します。前提の一覧は、回答そのものより価値があることも少なくありません。 自動的に適用される状況：アーキテクチャレビュー、要件が曖昧な場合。

/premortem | /postmortem：意思決定やプロジェクトがすでに失敗したと仮定します。原因をさかのぼって考え、可能性の高い順に3～5個の失敗要因を挙げます。エッジケースではなく、システム上のリスクに焦点を当てます。

/blindspot | /unknowns：不慣れな領域（新しいコードベースの領域、新しい分野、不慣れな技術）に使います。ユーザー自身が気づいていない未知の事柄、つまり適切なプロンプトを書くために知っておく必要があるのに、質問することすら思いつかない事柄を明らかにします。まずコードベースやドキュメントを調べ、その後、（1）ユーザーが尋ねるべき質問、（2）この領域の先行事例、慣習、落とし穴、（3）ここでの「良い状態」とは何かを報告します。目標はタスクを解決することではなく、より良いプロンプトを書けるよう、必要な知識を教えることです。提案された回答を攻撃する /adversarial や、計画が失敗したと仮定する /premortem とは異なり、これは回答が存在する前に実行し、解決策ではなくユーザーの知識の不足に焦点を当てます。 自動的に適用される状況：「Xについて何も知らない」「盲点を確認して」「未知の未知」「不慣れな領域に入る」。

/tensions | /perspectives：名前を付けた対立する2つの視点（例：セキュリティエンジニアとリリース担当のプロダクトマネージャー）から回答します。出力では、両者が意見を異にする点に焦点を当てます。そこにこそ、本質的な洞察があります。役割を指定するには、/tensions [devops, security] と入力します。

組み合わせ

/analyze = /think + /edge + /verify-think：コードレビュー、アーキテクチャ、セキュリティに関わる作業。調査結果を統合して、一貫性のある推奨事項にまとめます。各パターンの出力をただ連結するだけではありません。 自動的に適用：コードレビューの依頼時。

/trade = /confidence + /adversarial + /edge：トレードのアイデア、ポジション分析、市場の見通し。 自動的に適用：トレードやポジションについての議論時。

規約

• 組み合わせたパターンの出力は --- で区切ります
• 核となる回答を目立たせます。パターンは回答を強化するものであり、埋もれさせるものではありません
• 意思決定に関係する根拠と証拠を提示します。非公開の段階的な推論や行き詰まりを逐一説明しないでください。
• 会話の途中で新しいパターン定義（「/eli5 を追加して、5歳児にもわかるように説明する」など）を受け入れ、セッション中はそれを適用します

検証

• 出力にパターンマーカーが含まれていること（例：/verify の VERIFIED ANSWER:）
• 核となる回答が、パターン出力の区切り（---）より前にあること
• 意思決定の記録で、観察された証拠、推論、前提、不確実性を区別すること