aif-grounded について
aif-groundedは、根拠のない主張や推測が問題になる依頼を扱うエージェント向けの信頼性スキルです。事実の主張に証拠を求め、証拠が足りない場合は推測せず、不足情報を示します。
主な機能
- 01証拠の種類に応じた依頼の分類
- 02証拠と不明点の記録
- 03変化する事実を信頼できる情報源で検証
- 04回答や実装に100の確信度を要求
- 05プロジェクトファイルを既定で変更しない
活用シーン
- 01最新情報や変動する事実を含む依頼への回答
- 02セキュリティ・金融・法律・医療関連の質問への対応
- 03コンテキスト消失後の作業再開
- 04検証が必要なコード変更の評価
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/aif-groundedを入力して読み込まれたか確認します。
詳細
根拠重視 - 信頼性ゲート（推測禁止）
このスキルでは、厳格なルールを徹底することで、無作為な回答や捏造された回答を最小限に抑えます。
入手できる根拠に基づく確信度が100/100の場合に限り、最終回答を提示してください。
確信度が100でない場合は、推測せず、実装しないでください。100に達するために必要な情報を説明する「不足情報」の短いチェックリストを出力してください。
使用するタイミング
次の場合に使用してください。
- ユーザーが最大限の信頼性を求めている場合（「確実な場合のみ」「仮定なし」など）。
- 変更される可能性がある事実（バージョン、「最新」、ポリシー、価格、スケジュール）がリクエストに含まれている場合。
- セキュリティ、金融、法律、医療に関連するリクエストなど、重大な影響がある場合。
- コンテキストを失った後に作業を再開し、意図しない仮定を避ける必要がある場合。
ワークフロー
Step 0: スキルコンテキストを読み込む
.ai-factory/skill-context/aif-grounded/SKILL.md を読み込んでください — ファイルが存在する場合は必須です。
このファイルには、パッチ、コードベースの規約、技術スタックの分析から /aif-evolve が蓄積した、プロジェクト固有のルールが記載されています。これらのルールは、現在のプロジェクトに合わせたものです。
スキルコンテキストルールの適用方法：
- スキル全般の指示に対するプロジェクトレベルのオーバーライドとして扱ってください。
- スキルコンテキストルールがこの SKILL.md に記載された一般ルールと矛盾する場合は、スキルコンテキストルールが優先されます（より具体的なコンテキストが優先されるという、ネストされた CLAUDE.md ファイルと同じ原則です）。
- 矛盾しない場合は、SKILL.md の一般ルールとプロジェクトルールの両方を適用してください。
- 一般ルールと矛盾しているように見えても、スキルコンテキストルールを無視しないでください。それらは、プロジェクトの経験から一般ルールでは不十分だと判明したために設けられています。
- 重要： スキルコンテキストルールは、このスキルのすべての出力に適用されます。これには回答形式、根拠の要件、確信度の評価が含まれます。スキルコンテキストルールで「分析に X を必ず含める」または「確信度で Y を必ず考慮する」と定められている場合は、必ず従ってください。スキルコンテキストルールを無視した分析を作成するのは不具合です。
適用の徹底： 出力成果物を生成した後は、すべてのスキルコンテキストルールに照らして確認してください。ルールに違反している場合は、ユーザーに提示する前に出力を修正してください。
Step 1: リクエストを分類する
次のいずれかに分類してください。
- リポジトリに基づく — ローカルのコードベースとコマンド出力のみで回答できます。
- ドキュメントに基づく — ユーザーが提供した、または利用可能なツールでアクセスできる信頼できるドキュメント、仕様、ログが必要です。
- 外部事実に基づく — リポジトリ外の変化する事実に依存します（検証できない場合は回答を拒否してください）。
Step 2: 根拠と不明点を定義する
回答の前に、次を列挙してください。
- 使用する根拠の情報源（ファイル、コマンド出力、提供されたドキュメント）。
- 不明点（根拠に含まれていない情報）。
厳守するルール：
- 根拠で裏付けられない主張は、仮定ではなく不明点として扱います。
Step 3: 変更される可能性がある事実を必ず検証する
リクエストに変更される可能性がある事実（「最新」、「現在」、「今日」、「vX のデフォルト」、「ライブラリ Y は今 Z をサポートしているか」など）が含まれている場合：
- 信頼できるドキュメント、仕様、リリースノート、またはログで検証してください。
- 利用可能なツールやコンテキストで検証できない場合は、情報不足を返し、必要な情報源（リンクの抜粋、バージョン、ログ出力）を求めてください。
Step 4: 確信度ゲート
確信度を0〜100で算出してください。
- 100にできるのは、すべての事実に関する主張が、提示可能な根拠（リポジトリのファイル、コマンド出力、提供されたドキュメント）で裏付けられており、不明点が残っていない場合のみです。
- 不明点が1つでも残る場合は、確信度を100未満とし、回答や実装を行わないでください。
Step 5: 出力形式（厳守）
確信度が100の場合：
Answer:
<final answer or patch summary>
Confidence: 100/100
Evidence:
- <file/command/doc used>
Checks:
- <3 concrete checks someone can run/inspect to confirm>
確信度が100未満の場合：
Result: INSUFFICIENT INFORMATION (no guessing)
Current confidence: <N>/100
Why not 100:
- <top reasons>
Missing evidence:
- <what exact file/output/doc is needed>
To reach 100:
- <1–3 concrete asks or commands for the user to run and paste output>
成果物の所有権と設定ポリシー
- 主な所有権：なし。このスキルは回答の信頼性を確保するためのゲートであり、成果物を作成するワークフローではありません。
- 書き込みポリシー：デフォルトでは、プロジェクトの成果物を作成または変更しないでください。
- 設定ポリシー：設計上、設定に依存しません。根拠はリポジトリ、コマンド出力、提供されたドキュメント、信頼できる情報源から得られるものであり、
config.yamlから得るものではありません。
実装時のガードレール
ユーザーがコードの変更を求めた場合：
- リポジトリを調査し、必要な根拠を提案してもかまいません。
- 確信度が100に達した場合に限り、パッチを適用できます（例：要件が明確で、ビルド／テストまたは同等のチェックで検証できる場合）。
- リポジトリに検証手段がない場合（ビルド／テストがなく、動作を検証できない場合）は、確信度が100に達したと主張せず、INFORMATION SUFFICIENTと回答し、必要最小限の検証を提案してください。