wren-enrich-context

Wren Enrich Context — ビジネスコンテキストの不足を補う

このスキルは、ビジネスコンテキストの大半が DB スキーマには存在せず、ハンドブック、用語集、財務レポート、サポート手順書、コードコメント、Slack の経験則などに記載されているために作成されました。エージェントはこうした未加工の資料を読み、Wren プロジェクトに不足している情報を見つけたうえで、書き戻す前にユーザーに一度に1つずつ質問する（グリルモード）か、最善の推論を直接適用して監査レポートを引き継ぎます（自動操縦モード）。出力先は、各プロジェクトにすでにある3つ（または4つ）の場所です。新しい成果物や新しいツールは必要ありません。

バージョンの確認

https://raw.githubusercontent.com/Canner/WrenAI/main/skills/versions.json を通知せずに取得します。 wren-enrich-context キーと、このスキルのバージョン（上記のフロントマターから取得）を比較します。 リモートのバージョンのほうが新しい場合は、続行する前にユーザーに通知します。

wren-enrich-context スキルの新しいバージョンが利用可能です。 次のコマンドで更新してください：

npx skills add Canner/WrenAI --skill wren-enrich-context

CLI はインストール済みのエージェントを自動検出します。特定のエージェントを指定するには、--agent <name> を追加します（例：claude-code、cursor、windsurf、cline）。

更新の状態にかかわらず、続行してください。

---

厳守事項 — 最初に読むこと

共通（どちらのモードにも適用）

1. 追加のみ。既存のものは変更しない。 既存の MDL の説明／リレーションシップ／ルールに誤りがあると思われる場合でも、編集しないでください。ステップ9に記載する「手動で修正してください」リストに挙げてください。
2. MDL の編集はすべて検証する。 MDL の YAML を変更したら、すぐに wren context validate を実行してください。失敗した場合は、その変更だけを元に戻し、エラーをユーザーに伝えてください。プロジェクトを無効な状態のままにしてはいけません。
3. 提案はすべて事前に下書きする。 ユーザーに下書きを見せる場合（グリルモード）も、提案を直接適用する場合（自動操縦モード）も、具体的な内容を作成してください。「説明には何と書けばよいですか？」のように安易に質問してはいけません。
4. 確信度を明示する。 グリルモードでは、レーン3の推論に関する質問を「推測ですが — 」で始めてください。自動操縦モードでは、ステップ9の監査レポートで、レーン3の推論と部分的に一致するレーン2の照合結果すべてに、確信度（高／中／低）と情報源を付記してください。

グリルモードのみ

5. 質問は一度に1つ。徹底的に質問する。 すべての不足点を上から順に確認し、次に進む前に1つの判断を確定してください。質問ごとに推奨回答を示してください。
6. スキップしたら、このセッションでは終了です。 保留キューを作ったり、次のラウンドで再度促したりしてはいけません。再検討したい場合は、ユーザーがスキルを再実行します。

自動操縦モードのみ

7. 次の3つのケースではグリルモードに切り替える。 次の場合は必ず自動操縦を中断し、ユーザーに質問してください。

   • (a) レーン2の競合 — 未加工の情報と現在の MDL が一致しない場合。
   • (b) 影響範囲が大きい提案（どのレーンでも） — 新しいキューブ、新しいビュー、新しいリレーションシップ、または新しい MDL メトリック／計算列。これらは将来のすべてのエージェントセッションから見える公開成果物となるため、影響範囲の大きさは、きっかけが未加工の証拠（レーン2）か推論（レーン3）かには左右されません。
   • (c) レーン2の出力先が曖昧 — 出力先（MDL／instructions.md／queries.yml／cubes/）を確信を持って選べない場合。

   それ以外は、直接適用して監査リストに記録してください。

---

ステップ 0 — モードの選択（何よりも先に）

プロジェクトに触れたり、ファイルを読んだりする前に、実行するモードをユーザーに尋ねます。セッション全体を通して選択を固定し、セッション途中で切り替えることはできません。変更する場合は、もう一度実行してください。

このセッションで利用できるモードは 2 つです。

a) グリルモード — すべての不足点について、一度に 1 つずつ質問し、ドラフトを提案して、承認／編集／スキップの返答を待ちます。主導権はユーザーにあります。元資料に機密情報が含まれる場合、このプロジェクトについて私が知らないことを把握したい場合、またはやり直すよりレビューしたい場合に最適です。

b) オートパイロットモード — 元資料と現在のコンテキストを読み、最善の推測をして適用します。質問のために止まるのは、（1）元資料と既存の MDL の間に矛盾がある場合、（2）新しいメトリクス、ビュー、リレーションシップなど、影響範囲が大きい追加を行う場合に限ります。セッションの最後に、完全な差分と、確信度を付けた推測の一覧を提示するので、確認してください。

どちらにしますか？（a / b）

選択を MODE = grill | autopilot として記憶し、ステップ 6 と 9 の分岐に使用します。

---

事前確認

ステップ 1 — Wren プロジェクトを選択する

何よりも先に、どのプロジェクトを拡充するかを必ずユーザーに尋ねてください。現在の作業ディレクトリを前提にしてはいけません。ユーザーは複数の Wren プロジェクトを持っている場合があり、現在の ~/.wren プロファイルが拡充したいプロジェクトと一致するとは限りません。

一度のやり取りで回答できるよう、質問には具体的なヒントを含めてください。

# Hint 1 — does cwd look like a project?
test -f wren_project.yml && pwd

# Hint 2 — does ~/.wren/config.yml point at a default project?
grep -E '^project_path:' ~/.wren/config.yml 2>/dev/null

続けて、次のように尋ねます。

どの Wren プロジェクトを拡充しますか？ a) $PWD（現在のディレクトリ） ← ヒント 1 が該当する場合 b) <path from ~/.wren/config.yml> ← ヒント 2 が該当する場合 c) その他 — 絶対パスを貼り付けてください

ユーザーの回答後、セッション全体を通してパスを固定します。

cd <chosen-path>
test -f wren_project.yml || {
  echo "Error: <chosen-path> is not a Wren project (no wren_project.yml)."
  exit 1
}
wren context show >/dev/null 2>&1 || {
  echo "Error: wren context show failed — manifest may be invalid."
  exit 1
}

いずれかの確認に失敗した場合は停止し、ユーザーに伝えてください。プロジェクトでない場合は wren-onboarding を、マニフェストに問題がある場合は wren context validate を提案します。

この時点以降、このスキル内のすべてのコマンドとファイルパスは、選択したプロジェクトのルートからの相対パスです。セッション中にプロジェクトを切り替えてはいけません。ユーザーが別のプロジェクトで作業したい場合は、このセッションを終了して再実行します。

ステップ 2 — メモリが利用可能か確認する

wren memory --help >/dev/null 2>&1

• 終了コード 0 → MEMORY_AVAILABLE = true に設定します。4 つ目の出力先（直接の wren memory store）が利用可能になります。
• 0 以外の終了コード → MEMORY_AVAILABLE = false に設定します。以下のメモリ専用の経路はスキップします。

ステップ 3 — raw/ フォルダーがあることを確認する

プロジェクトのルートで実行します（ステップ 1 で、現在の作業ディレクトリはすでにそこに移動しています）。

mkdir -p raw

新しく作成した場合（ディレクトリが空だった、または存在しなかった場合）：

プロジェクトのルートに raw/ を作成しました。このプロジェクトのビジネスコンテキストを説明するのに役立ちそうなものを何でも入れてください。PDF、用語集、ハンドブック、財務報告書、データ辞書、サンプルクエリ、コメント付きコード、ダッシュボードのスクリーンショットなど、何でも構いません。

ご注意ください： 内容には機密情報が含まれる可能性があります。raw/ を git にコミットするかどうかは、ご自身で判断してください。.gitignore には手を加えません。

ファイルを追加したら知らせてください。読み始めます。

続行する前に、ユーザーの確認を待ちます。

---

ステップ 4 — すべてを読む

意見をまとめる前に、元資料と現在の Wren コンテキストの両方を読みます。

元資料

raw/ 内のすべてのファイルを読みます。エージェントが標準で利用できる機能（テキスト、Markdown、コード、PDF など）を使ってください。特定のファイルを本当に読めない場合は、そのファイルを一度だけユーザーに伝え、テキストに変換するか、関連箇所を貼り付けるよう提案してから、残りのファイルに進みます。追加の Python パッケージをインストールしてはいけません。また、新しい CLI サブコマンドを使ってはいけません。

現在の Wren コンテキスト

ソース	コマンド
MDL（全体）	wren context show --output json
プロジェクトの指示	wren context instructions
既存のキューブ（名前）	wren cube list
既存のキューブ（メジャーとディメンション）	上記の各名前に対して wren cube describe <cube>
キュレーション済み NL-SQL ペア	queries.yml を直接読み取る
（メモリ）保存済みペア	wren memory list -n 200 --output json
（メモリ）テキスト形式のスキーマ	wren memory describe

メモリの行が重要なのは、MEMORY_AVAILABLE = true の場合のみです。Lane 3 のメトリクス提案を行う前に、キューブを読み取ることが不可欠です。重複防止については references/cube_proposals.md を参照してください。

---

ステップ 4.5 — グラウンドトゥルースの調査（グリルモードではデフォルト、自動操縦モードではオプトアウト）

raw に列の列挙値／単位／NULL／マジック値／時刻の意味について記載がない場合、カタログの列単位のカテゴリ（references/gap_catalog.md の #1、#2、#3、#5、#7）は、ライブ DB から異なる値をサンプリングすることで直接判断できることがよくあります。このステップの前に references/gap_catalog.md を読み込んでください。トリガー列で、調査候補となる列がわかります。

モード別のデフォルトポリシー：

モード	デフォルト	上書き方法
グリル	調査オン。最初のクエリの前に、ユーザーに一度だけ次のように確認します。「列挙値／センチネル値／時間粒度の値を見つけるため、各列に LIMIT 30 を指定して N 列をサンプリングしたいのですが、よろしいですか？」回答はセッション中固定します。	ユーザーが拒否した場合 → ステップ 4.5 全体をスキップし、代わりに Lane 2 と Lane 3 に依拠します。
自動操縦	調査オフ。このスキルは自動操縦モードではライブ DB にクエリしません。	なし — 調査によって高信頼度の推論が可能になる場合、ユーザーはグリルモードで再実行する必要があります。

候補の選定（DB 呼び出し前）：

次の条件をすべて満たす列は調査候補です。

• 説明が空である、または関連する [tag]（カタログの記述形式）がまだ含まれていない。
• 列の型／名前のパターンが、カタログの #1（列挙値）、#3（NULL）、#5（マジック値）、または #7（時間粒度）に一致する。
• #3 と #7 では、説明にもイベントとレコードの区別、または TZ に関する記述がない。

カテゴリ #2（単位）、#4、#6、#8、#9、#10 は調査対象になりません。SELECT DISTINCT では、単位、デフォルトフィルター、同義語、外部マッピング、通貨の慣例、正規テーブルの優先設定は明らかにならないためです。これらには raw の根拠、または人間による判断が必要です。

調査クエリ：

wren --sql "SELECT DISTINCT <col> FROM <model> LIMIT 30" --output json
# For magic sentinels (catalog #5), also fetch min/max:
wren --sql "SELECT MIN(<col>) AS lo, MAX(<col>) AS hi FROM <model>" --output json

• 異なる値が 30 件以下返された場合 → 列挙値／センチネル値／粒度の候補です。[tag] の行を下書きし、信頼度を「中 — 値は調査済み、意味はまだ推論」としてユーザーに提示します（グリル）。
• 30 件返された場合（LIMIT 到達） → カーディナリティが高すぎます。列挙値／センチネル値の候補ではないため、スキップします。
• クエリが失敗した場合（権限、接続、大規模テーブルのタイムアウト） → 再試行しないでください。失敗を監査リストに記録し、ステップ 9 で提示して、Lane 2 と Lane 3 のみで続行します。

安全策：

• セッションごとに、各（モデル、列）を調査するのは最大 1 回までです。
• すでに一致する [tag] の行がある列は調査しないでください — Universal Rule 1。
• 調査結果は作業メモリに保持し、ディスクには書き込みません。

---

ステップ 5 — 3 つのギャップ検出レーン（頭の中で処理し、成果物は作成しない）

3 つのレーンすべてを作業メモリに保持してください。gaps.yml は作成しないでください。

調査を始める前に、スキーマでは保持できない 10 個のビジネス意味カテゴリを記載した references/gap_catalog.md を読み込みます。各レーンでカタログの使い方は異なります。Lane 1 は型を考慮した機械的なトリガーとしてカタログを順に確認し、Lane 2 は各 raw の主張を 10 個のカテゴリのいずれかに分類してから振り分け、Lane 3 はトリガーが発生しても raw に記載がない場合に推論プロンプトの種として使います。

レーン 1 — 構造的な網羅性（機械的チェック）

現在の MDL をスキャンして、以下を確認します。

• すべてのモデルに空ではない properties.description があるか？
• すべてのカラムに説明があるか（少なくとも PK でも FK でもないカラムについて）？
• すべてのモデルに primary_key があるか？
• すべてのモデルに少なくとも 1 つのリレーションシップがあるか（どのモデルにも紐づいていないモデルは要注意）？
• instructions.md はスキャフォールドのデフォルトを超える内容になっているか？
• queries.yml には、代表的なペアが少なくともいくつかあるか？

さらに、すべてのカラム／モデルについて、references/gap_catalog.md のトリガーに照らして確認します。

• カタログの #1 / #2 / #3 / #5 / #7 のトリガーに該当するカラムごとに、対応する [tag] 行が properties.description にあるか？
• ソフト削除カラム（deleted_at、is_active、archived_at など）を持つモデルごとに、それを対象とする ## Default filters ルールが instructions.md にあるか（カタログ #4）？
• 似た名前のテーブルの組（例：users / users_v3）ごとに、## Canonical tables ルールがあるか（カタログ #10）？
• *_currency / fx_rate / 外部システム ID のカラムごとに、一致する ## Currency（#9）または ## External identifiers（#8）セクションがあるか？
• instructions.md または raw 内にある、モデル名／カラム名とそのまま一致しないビジネス用語について、カタログ #6 の ## Naming conventions ルールが不足していないか？

満たされていないチェック項目は、それぞれ候補になります。レーン 2 に進む前に、Step 4.5 のプローブ結果（利用可能な場合）と組み合わせます。

レーン 2 — 主張の差分（raw と現在のコンテキスト）

各 raw ファイルについて、内部で 5～15 件の原子的な主張を抽出します。原子的な主張とは、「注文には顧客がちょうど 1 人いる」「デフォルトでは user は type=default を意味する」「ARR は MRR × 12 から返金額を引いた値に等しい」のように、真偽を判定できる単一の記述です。次に、各主張を現在の Wren コンテキストに照らして分類します。

分類	意味	解決結果
covered	すでに MDL / instructions / pairs に反映されている	スキップ
partial	トピックは存在するが、表現または対象範囲が異なる	明確化を提案
new	現在のコンテキストに一致するものがない	適切な保存先に振り分ける
conflict	raw では A、現在のコンテキストでは B とされている	ユーザーに詳しく確認する（どちらのモードでも）。ただし既存のものは編集しない — 手動修正が必要な項目として提示する

レーン 3 — 推論（独自の推測）

raw と現在の MDL を読み終えたら、ユーザーが raw で明示していないものの、後でエージェントに役立つと考えられる追加案を提案します。例：

• 「finance.pdf で quarterly_churn が 5 回参照されています。既存のキューブでは対応していません。measure = COUNT(*) FILTER (WHERE churned_at IS NOT NULL) / NULLIF(COUNT(*), 0) として cubes/quarterly_churn/metadata.yml を追加しますか？」— YAML テンプレートと重複チェックについては references/cube_proposals.md を参照してください。
• 「サポートハンドブックで core users という言葉が定義なしに繰り返し使われています。これは users WHERE tier = 'premium' のことでしょうか？ビューを作成しますか？」
• 「データディクショナリには events.payload が JSON と記載されていますが、このカラムには説明がありません。説明の下書きを作成しましょうか？」

集計形式の提案（SUM、COUNT、AVG、「月別／ステータス別／顧客ごと」などのパターン）では、デフォルトでキューブを選びます。まず wren cube list + wren cube describe を実行し、測定式をすでにカバーするキューブがないことを確認します。該当するキューブがある場合は、提案をスキップし、代わりに既存のキューブを参照する queries.yml の例を追加します。判断フロー全体、命名規則、検証フローについては references/cube_proposals.md を参照してください。

グリルモードでは、レーン 3 の質問はすべて「I'm guessing — 」で始めてください。 オートパイロットでは、ユーザーが推論による追加だとわかるよう、監査エントリーに agent inference のタグを付けてください。

---

Step 6 — ギャップを解消する

Step 0 で確定した MODE に応じて分岐します。

グリルモード

レーン 1～3 で見つかったすべての不足点について、次の会話パターンを使用します。

共通認識に至るまで、不足点についてユーザーに徹底的に質問します。意思決定ツリーの各分岐をたどり、意思決定間の依存関係を一つずつ解決します。質問ごとに、推奨する回答を提示します。

質問は一度に一つずつ行います。

コードベースまたは生ファイルを調べれば回答できる質問は、ユーザーに尋ねるのではなく、調査してください。

グリルの各ターンでは、次の手順を実行します。

1. 不足点と、その出所（レーン 1／2／3。レーン 2 の場合は、生ファイルの引用と短い抜粋も含む）を示します。
2. 具体的な回答案を提示します。説明、ルール、SQL の組み合わせ、関係性の案を作成します。
3. 反映先を提案します（「これをルールとして instructions.md に追加します」／「これを MDL の users モデルの説明に追加します」）。
4. ユーザーが承認、編集、スキップできるようにします。
5. 承認された場合：書き戻します（ステップ 7）。
6. 編集された場合：ユーザーの文言を反映してから、書き戻します。
7. スキップされた場合：その項目を破棄し、次の不足点に進みます。再び提示しないでください。

ユーザーが想定外の回答（「実際にはそれを追跡していません」など）をした場合は、方針を切り替えます。目標は共通認識に至ることであり、事前に用意した項目を押し通すことではありません。

自動操縦モード

ユニバーサルルール 7 の次の 3 つのエスカレーションケースを除き、レーン 1～3 のすべての調査結果を直接処理します。

• レーン 2 の矛盾 — この質問だけについてグリルに切り替え、自動で解決しないでください。
• レーン 3 で新しいメトリクス／ビュー／関係性を提案する場合 — 適用する前にグリルに切り替えてください。
• レーン 2 で反映先が曖昧な場合 — 反映先を決める部分だけグリルに切り替え、その後は自動で適用してください。

それ以外（レーン 1 の機械的な修正、レーン 2 の曖昧さのない新しい主張、レーン 3 の影響が小さい説明の調整）については、次の手順を実行します。

1. 最適な推論を用いて、具体的な提案（説明／ルール／SQL の組み合わせ）をまとめます。
2. ルーティング表（ステップ 7）を使用して反映先を決定します。
3. 書き戻します。
4. MDL を編集した場合は、直後に wren context validate を実行します。失敗した場合は、その変更だけを元に戻し、エラーとともに取り消しを記録します。
5. 監査リストに、調査結果、反映先、信頼度タグ（high／med／low）、出所（レーン 2 の場合は生ファイルと抜粋、レーン 3 の場合は agent inference、レーン 1 の場合は structural）を追記します。

自動操縦では、項目ごとの確認のために処理を一時停止しません。ユーザーはステップ 9 で差分全体と監査リストを確認します。ユーザーはレビュー担当者であり、各項目を承認する役割ではありません。

---

ステップ 7 — ルーティングと書き戻し

提案の一部として書き込み先を決定します（グリルモードではステップ 6.3、自動操縦モードではステップ 6.2）。これにより、ユーザーはグリルモードでルーティングを修正でき、自動操縦モードで監査できます。

発見の種類	書き込み先	書き込み方法
スキーマ構造／リレーションシップ／ビュー／モデルまたはカラムの説明	models/、views/、relationships.yml 配下の MDL YAML	YAML ファイルを直接編集します。カタログ #1／#2／#3／#5／#7／PII の場合は、properties.description に [tag] 行を追加します（説明文を先に記載し、その後にカテゴリごとにタグを 1 つずつ記載します）。正確なタグ形式と適用条件については、references/gap_catalog.md を参照してください。
集計指標／名前付きメジャー（メジャーとディメンションを含む）	cubes/<name>/metadata.yml	キューブごとに新しいファイルを作成します。SUM／COUNT／AVG／比率指標の生の定義、またはレーン 3 で推定した指標のデフォルトの書き込み先です。YAML テンプレート、命名ポリシー、重複チェック、検証フローについては、references/cube_proposals.md を参照してください。書き込み後に wren context validate と wren cube query --cube <name> --sql-only を実行し、どちらかが失敗した場合は変更を元に戻します。自動操縦モードでは必ずグリルモードにエスカレーションします（ユニバーサルルール 7b）。
デフォルトフィルター／暗黙のルール／ビジネス上の慣例／命名規則／外部マッピング／通貨／標準テーブル	instructions.md	カタログで指定された ## セクション見出し（#4 → ## Default filters、#6 → ## Naming conventions、#8 → ## External identifiers、#9 → ## Currency、#10 → ## Canonical tables）の下に追記します。見出しがない場合は作成し、既存のテキストは変更しないでください。
チームで共有する正規の NL→SQL 例	queries.yml	pairs: の下に新しいエントリーを追加します
アドホックな NL→SQL ペア（ユーザーのローカル用で、リポジトリには追加しないもの）— MEMORY_AVAILABLE = true の場合のみ	wren memory store	wren memory store --nl "..." --sql "..." --tags "source:enrich"

カタログに基づくルーティングでは、カラム単位の提案はすべて、そのカラムの properties.description に [tag] 行を追加し、モデル間のルールはすべて、固定見出しの下にある instructions.md に書き込みます。これにより、再エンリッチメントが決定論的（grep 可能）になり、新たな書き込み先を勝手に設けることを防げます。

MDL を編集するたびに実行

wren context validate

失敗した場合：

1. 直前に行った変更を 1 つ元に戻します。
2. 検証エラーをユーザーに提示します（グリルモード）、または監査ログに記録します（自動操縦モード）。
3. グリルモードでは、エラーを新しいコンテキストとして、その特定のギャップについて再度グリルします。
4. 自動操縦モードでは、発見事項に「revert: validation failed」と記録して次に進みます。

形式に関する注意

• queries.yml のスキーマは wren memory dump の出力に従います：version: 1、{nl, sql, source} のリストである pairs:（source: enrich を使用）。
• MDL YAML ではスネークケースのキー（例：primary_key、is_calculated、not_null）を使用します。wren context build は target/mdl.json 用にキャメルケースへ変換します。
• instructions.md は自由形式の Markdown です。見出しを使って、ルールをトピック別にまとめます。

---

ステップ 8 — セッションの完了

ステップ 6 の終了後（グリルモードでユーザーが停止を指示した場合、または自動操縦モードですべての発見事項を処理した場合）：

wren context build

これにより、YAML の編集内容から target/mdl.json を再コンパイルします。

MEMORY_AVAILABLE = true の場合：

wren memory index

これにより、新しいスキーマ項目、更新された instructions.md、新しい queries.yml エントリーが再度埋め込みされます。

---

ステップ 9 — 要約

両モード共通のセクション

簡潔なセッションレポートを出力します：

Wren Enrich Context — session summary  (mode: <grill|autopilot>)

Added:
  MDL              : N model descriptions, N column descriptions, N relationships, N views
                     by tag: [enum]=N [unit]=N [null]=N [magic]=N [time]=N [pii]=N
  cubes            : N new (names: <list>)                                    via cubes/<name>/metadata.yml
  instructions.md  : N new rules across sections
                     by section: Default filters=N | Naming conventions=N | External identifiers=N | Currency=N | Canonical tables=N
  queries.yml      : N new NL→SQL pairs
  memory store     : N ad-hoc pairs                                          (only if MEMORY_AVAILABLE)
  Probe            : N columns sampled, M failed                             (grill mode only)

Please fix manually (we don't edit existing fields):
  - models/orders/metadata.yml: existing description seems to contradict raw/glossary.pdf p.3
  - relationships.yml: existing orders↔customers is MANY_TO_ONE but raw/data_dict.md p.7 says MANY_TO_MANY
  - …

グリルモードの追加項目

以下を追記します：

Skipped this session: N gaps (re-run /wren-enrich-context to revisit)

自動操縦モードの追加項目

推論内容をユーザーが妥当性確認できるよう、詳細な監査記録を追記します：

Inferred items (please review):
  high   | MDL model:orders.description           | from raw/glossary.pdf p.2 — "Order = ..."
  high   | instructions.md rule                    | from raw/handbook.md §4 — "default tier ..."
  med    | MDL column:users.signup_source.desc    | agent inference from raw/onboarding.md
  low    | queries.yml: "weekly active customers"  | agent inference, no direct raw evidence

Validation:
  K successful applies, M reverted after wren context validate failed:
    - relationships.yml: <error> → reverted

Escalated to grill (raw vs MDL conflicts / high-impact additions):
  - <count> items — see grill transcript above

ユーザーには監査記録を確認し、そのまま承認するか、信頼度の低い行を手動で調整するか、対話形式で再検討したい場合はグリルモードで再実行するよう促してください。

---

避けること

• gaps.yml、state.yml、その他の追跡用ファイルは作成しないでください。セッションは会話内だけで完結します。
• 既存の MDL フィールド、指示ルール、queries.yml の項目は変更せず、追記・追加のみ行ってください。不一致は手動修正リストに記載してください。
• raw を読むために新しい Python パッケージ（pypdf、docling、…）をインストールしないでください。エージェントがすでに利用できるものを使い、開けないファイルはユーザーに変換を依頼してください。
• raw と現在の MDL の矛盾を自動で解決しないでください。どちらのモードでも、必ずユーザーに詳しく確認してください。
• Lane 3 の推論を raw からの引用のように示さないでください。冒頭に「I'm guessing — 」と記載する（grill モード）か、agent inference のタグを付けてください（auto-pilot）。
• MEMORY_AVAILABLE = false の場合は wren memory store を呼び出さず、代わりに queries.yml に記録してください。これにより、将来の wren memory index 後もペアが保持されます。
• Git にコミットしないでください。コミットするかどうかはユーザーが決めます。
• スキップされた質問について催促しないでください。スキップは今回のセッションではスキップのままです（grill モードのみ。auto-pilot にはスキップの概念はありません）。
• MDL を編集するたびに wren context build を実行しないでください。最後に一度実行すれば十分です。編集のたびに wren context validate は実行してください。
• raw/ が wren context init によって作成されたと想定しないでください。これは作成されません。このスキルが作成します。
• セッション中にモードを切り替えないでください。モードを変更するには、ユーザーが再実行します。
• 同じカテゴリのタグがその列にすでに存在する場合、[tag] の行を追記しないでください。これは Universal Rule 1 です。矛盾は手動修正リストに記載してください。
• 新しい instructions.md のセクション見出しを作らないでください。カタログで定義された5つの見出し（## Default filters、## Naming conventions、## External identifiers、## Currency、## Canonical tables）に従ってください。該当する項目がない場合は、手動修正リストに記載してください。
• auto-pilot モードではライブ DB を調査しないでください。ステップ 4.5 はデフォルトで grill モードのみです。
• 同じ base_object 上の別のキューブにすでに存在するメジャー式を持つキューブを提案しないでください。代わりに、既存のキューブを参照する queries.yml の例を記述してください。重複防止については references/cube_proposals.md を参照してください。
• raw と矛盾する場合でも、既存のキューブ YAML を変更しないでください。これは Universal Rule 1 です。手動修正リストに記載してください。
• 同じロジックをすでにカバーする MDL の metrics: 項目と並べて新しいキューブを作成しないでください。「consider migrating to cube」として手動修正リストに記載してください。
• キューブ作成後に wren cube query --cube <name> --sql-only を実行しないままにしないでください。構造に関する wren context validate では、解決できないメジャー式やディメンション式を検出できません。
• auto-pilot では、Lane 2 の矛盾や、新しいメトリクス／ビュー／リレーションシップの推論を自動適用しないでください。それらの場合は必ず grill モードに切り替えてください。

---

関連項目

• references/gap_catalog.md — 10種類の業務セマンティクス上のギャップカテゴリと、そのトリガー、デフォルトの保存先、記述形式を説明しています。ステップ 4.5 およびステップ 5 の前に読んでください。
• references/cube_proposals.md — キューブ、ビュー、計算列のどれを提案するかを判断するフローチャート、キューブ YAML のテンプレート、命名規則、重複防止、検証フローを説明しています。集計に関する Lane 3 の提案を行う前に読んでください。