intent-planner 0.13.1

package/templates/ja/codex/skills/intent-compass/SKILL.md

@@ -0,0 +1,52 @@
+---
+name: intent-compass
+description: Intent Tree から、今回の変更における判断基準（North Star / Anti-direction / Invariants / Decision Rules）を構築する。Claude が局所最適に逃げるのを防ぐ。実装はしない。
+---
+
+# intent-compass Skill
+
+## Core Mission
+- **Success Criteria**:
+  - North Star / Current Drift / Direction / Anti-direction / Invariants / Decision Rules / Evidence / Open Questions が揃っている
+  - Anti-direction に Claude がやりがちな局所最適が明示列挙されている
+  - Invariants はプロジェクト普遍のみが compass に保持され、packet 固有は packet ファイル（Safety / Invariants）を正本としている
+  - アプリケーションコードを一切変更していない
+
+## Execution Steps
+
+### Step 1: 前提を読む
+- `.intent/intent-tree.md` を読む。無ければ「先に `/intent-discover` を実行」を案内して停止する。
+- 読み取り時、compass / intent-tree の確定文体に紛れた未確定動詞（想定 / 流用 / 予定 / TBD / 暫定 等）を見たら、推測で確定させず Open Questions または未定スロット（理由・再訪条件（Revisit when）併記）への変換案として提示する。確定値への昇格は利用者の確認に委ねる。既に Open Questions / Deferred / 未定スロットへ記録済みの箇所は重複変換しない。
+- `.intent/mode.local.md`（無ければ旧 `.intent/mode.md`）の mode 状態を読む。無ければ standard を既定とし、Open Questions に「モード未確定・`/intent-discover` 推奨」を併記する（停止しない）。
+- 既存の `.intent/intent-compass.md` があれば読む。
+
+### Step 2: モード定義のアルゴリズムを適用する
+- `.intent/mode.local.md`（無ければ `.intent/mode.md`）の `definition` が指すモード定義を開き、Compass 構築フェーズに割り当てられた algo rule（`rules/algo-*.md`）を読み、適用する（現状どのモードも `rules/algo-qoc.md`）。例は網羅ではない。常にモード定義の表を正とする。
+
+### Step 3: Compass を構築する
+- 導出の前段で `rules/constraint-surfacing.md` を読み、適用する。同梱のドメイン定石カタログを read-only で照合し、Anti-direction / Invariants の叩き台候補を提示する（候補まで・自動転記しない。既存導出を置き換えない。カタログ不在なら沈黙）。
+- QOC に従い North Star を引き、Decision Rules を軽量 ADR として凝縮する（エントリの欄構成は `rules/algo-qoc.md` が正）。
+- Anti-direction に Claude がやりがちな局所最適・小手先リファクタを明示列挙する（最重要）。
+- Invariants を2層で解消する:
+  - **プロジェクト普遍 invariant**（全作業共通・少量）→ compass の Invariants に保持する。`/kiro-steering-custom` で `.kiro/steering/` に置くと全作業で効くことを推奨提示する（自動配置はしない。起動時コンテキスト増を避けるため少量に限る）。
+  - **packet 固有 invariant**（特定作業単位）→ packet ファイルの Safety / Invariants に直接起案する（compass には書かない。`/intent-packets` が packet 起案時に記入する）。
+- 節更新日の打刻（書き手の責務）: compass を書き込むとき、**実際に内容を更新した節の行だけ**を打刻する。Invariants 節を更新したらその時点を `Updated (Invariants):` に、Decision Rules 節を更新したらその時点を `Updated (Decision Rules):` に記録する（ISO 8601）。両方を常に打つのではなく、当該節を更新したときのみ該当行を打刻する。内容変更を伴わない節の行は変えない（冪等。無変更で打刻しない）。初期マーカー `—`（scaffold 既定）は、その節を実際に更新した時点で日時へ置き換える。日時はシェルの `date` で取得する。日時を取得できない場合は推測の日付を書かず、その旨を報告する。打刻は書き手（本スキル）の責務であり、read-only の検証層（intent-validate）には持たせない。
+
+### Step 4: 提示する
+- `.intent/intent-compass.md` の更新案を提示する。実装変更はしない。
+
+## Output Description
+
+**読み手**: これから実装に向かう人間開発者（と、実装を担う AI）。
+**この出力で最初に掴ませること**: 「**今回の変更で避けるべき局所最適（Anti-direction）はこれ**。判断基準が揃ったので次は `/intent-packets`」。このスキルの核心は Anti-direction の明示なので、それを筆頭に立てる。
+
+出力は結論を先頭に立てる。
+
+- **今回避けるべき局所最適（Anti-direction・先頭）**: Claude がやりがちな小手先リファクタ・局所最適を名指しで列挙（このスキルの最重要成果）。
+- **次の一手（1行）**: `/intent-packets`（作業単位への分割。cc-sdd に渡せる粒度の packet に切り出す）。
+- **詳細**: `.intent/intent-compass.md` の更新案（North Star / Direction / Invariants / Decision Rules）、steering 配置を推奨する普遍 invariant（あれば）、判断に必要な不明点（Open Questions）。
+
+## Safety & Fallback
+- Intent Tree が無ければ停止して `/intent-discover` を案内する。
+- mode.md 不在は停止せず standard 既定で続行し告知する。
+- アプリケーションコードは変更しない。

package/templates/ja/codex/skills/intent-compass/rules/algo-qoc.md

@@ -0,0 +1,62 @@
+# Algorithm: QOC (Questions-Options-Criteria)
+
+設計判断を「問い・選択肢・選択基準」で記録する技法。全モード共通の Intent Compass 構築フェーズで使う。判断の根拠を残すことで、後から（特に impl 段階で）局所最適に流れるのを防ぐ。
+
+## 手順
+
+1. **North Star を Intent Tree から引く**
+   - L0/L1 から「この変更で近づきたい最終状態」を1つに凝縮する。
+
+2. **判断点を QOC で展開する**
+   - **Question**: 迷いどころ（「Xをどう実現するか」）。
+   - **Options**: 取りうる選択肢を複数挙げる。
+   - **Criteria**: どの基準で選ぶか。Intent Tree の L1（成果）や invariant（壊してはいけない制約）に照らす。
+   - 採用した選択肢を `Decision Rules` に**軽量 ADR**（Architecture Decision Record、Nygard 形式）として凝縮する。1判断1エントリで、**Context**（問いと状況）/ **Decision**（採る選択肢）/ **Why**（選択基準）/ **Alternatives considered**（検討した代替案。QOC で比較して採用しなかった Options とその不採用理由の要約を転記する）/ **Consequences**（この決定が課す帰結。守らせる Invariants・避けさせる Anti-direction への接続を明記）/ **Revisit when**（この決定を見直すべき条件。条件が定まらない場合は明示的に「未定」と記録し、空欄のまま放置しない）を持つ。
+   - 役割分担: QOC は選択肢を**比較する探索の道具**、ADR 形式の Decision Rule は**将来の実装セッションを拘束する正本**。比較の過程は Evidence に残し、Decision Rules には採用した判断だけを昇格させる。
+
+3. **Anti-direction を明示列挙する**
+   - 避けるべき方向を書く。特に **Claude がやりがちな局所最適・小手先リファクタ**を具体的に列挙する。これは Compass の最重要セクション。
+   - 列挙には**プレモータム（pre-mortem）**を使う: 「この変更が実装され、結果として全体設計が崩れた・意図から外れたと**仮定**する。エージェントは何をしてしまったか？」と未来から振り返り（prospective hindsight）、出てきた失敗経路を Anti-direction として書き出す。思いつきの列挙より失敗要因の検出力が高い。
+   - 例: 「ついでに別の処理も直す」「テストなしの一括置換」「ドメインロジックを UI に寄せる」。
+
+4. **Invariants を2層で固定する**
+   - 壊してはいけない振る舞い / API / データ / UX / 運用制約。
+
+   - **推論で導出する前に、固定カテゴリ枠でユーザーへ確認する**。ユーザー由来の制約を canonical として先に確定し、推論で導出した制約は穴を埋める補完として後に足す（置換ではなく補完）。次のカテゴリを**重要度の高い順に**提示する（認知負荷の制御）:
+     1. データ / 個人情報（PII）— 絶対に消してはいけない・漏らしてはいけないデータは何か。
+     2. 外部依存・既存契約 — 落ちても・変えられても守るべき振る舞いは何か。
+     3. 運用・障害時挙動 — 障害・高負荷・部分故障のとき何を最優先で守るか。
+     4. セキュリティ / プライバシー / 法令 — 違反したら致命的になる規約・規制は何か。
+     5. 性能 / 可用性 — 下回ったら失敗とみなす水準はあるか。
+     6. 技術的制約 — 使わねばならない/使ってはいけない技術スタック・言語・FW・基盤・ライセンスはあるか。このカテゴリは損失逆算が不自然なため、否定形ではなく**直接形**で問う（「使わねばならない/使ってはいけない技術はあるか」）。挙がったものは**過剰昇格フィルタ**にかける: 好み・既定の選択（解 How）ではなく、破ると外的に問題になる制約（要求 How）か。後者だけを Invariant 化する。なお、この変更で導く設計判断（L3）とは別物であり、外的・変更非依存の境界のみをここに置く（L3 と二重化させない）。
+     7. 不変条件・禁止事項 — それ以外に「絶対にこうあってはならない」ことは何か。
+   - 各カテゴリの例示は、読み取ったプロジェクト文脈（技術スタック・ドメイン・既存コード・README）から**性質の異なる弱い手がかりを2〜3個、その場で生成して**添える（固定の例示文字列を埋め込まない）。例示には毎回「これは網羅ではない、他にあれば挙げてほしい」と非網羅を明示し、提示した例だけに思考を固定させない。
+   - 文脈から具体例を生成できない場合は、カテゴリの枠（見出し）のみを提示し、ユーザーが自身の文脈で埋められるようにする（fallback）。
+   - 問いは肯定形（「〜は必要か」）ではなく、**失敗前提・否定形**で立てる（例:「これを完全に無視したら最悪どうなるか」「外部依存が落ちても守るべきことは何か」「絶対に消してはいけないデータは何か」）。損失シナリオから真に守るべきものだけを Invariant 化し、過剰な前提を混入させない（技術制約カテゴリは直接形を採る。理由は当該カテゴリ参照）。
+   - 各カテゴリで「該当なし／不明／後で確認」を選べる形で提示し、回答を強制しない。ユーザーが保留・「後で確認」を選んだ項目は推測で埋めず、`Open Questions`（必要に応じて `[export まで]` タグ）へ逃がして compass 構築を止めない。
+
+   - 収集した制約は **Invariants の2層**へ振り分ける。**プロジェクト普遍 invariant**（全作業共通・少量）は compass の `## Invariants` に確定する。**packet 固有 invariant**（特定作業単位に限る制約）は、compass フェーズでは packet が未起票なのが常態なので、`## Open Questions` に「packet 固有制約（候補）」として保留する（後で `/intent-packets` が該当 packet の Safety/Invariants へ転記する）。非機能要件のうち**目標値**（性能・可用性の水準など）であるものは `Decision Rules` または Intent Tree の L1（計測基準）へ振り分ける。
+   - プロジェクト普遍のものは `/kiro-steering-custom` で `.kiro/steering/` に置くと全作業で効くことを推奨提示する（自動配置はしない。起動時コンテキスト増を避けるため少量に限る）。
+
+5. **Evidence と Open Questions を残す**
+   - 各判断を支える証拠（README/コード/テスト/ログ/課題）を `Evidence` に。
+   - 判断に必要だが未確定の問いを `Open Questions` に。
+   - export までに回答が必要な問いにのみ `[export まで]` タグを付す（タグなしの問いはいつでも回答可）。
+
+6. **omission recap で抜け・過剰を確認する**
+   - `intent-compass.md` の更新案を出す前に、収集・推論した制約・非機能要件・不変条件を短く要約して返し、「抜けているもの・逆に過剰な前提はないか」をユーザーに確認する（LLM の見落とし・ハルシネーションを人間が補正する材料として提示する）。
+   - ユーザーが**抜け**を指摘した場合は、その制約を種別に応じた記録先へ追記して再提示する: 普遍 Invariant → `## Invariants`／packet 固有 → `## Open Questions` の「packet 固有制約（候補）」として保留／目標値 → `Decision Rules` または L1。目的・成功の抜けは compass の範囲外（Intent Tree 側で扱う）であり、本ファイルでは compass の制約に限って補正する。
+   - ユーザーが**過剰**を指摘した場合は、確認のうえ当該エントリを canonical（`## Invariants` 等）から削除する。確信が持てない場合は削除せず `## Open Questions` へ降格する。削除前に必ずユーザーへ確認する。
+   - 再編集は最大1往復に留める（recap で延々と対話しない）。残る論点は `## Open Questions` へ逃がす。
+
+## 規律
+
+- Decision Rule は「なぜ」を必ず含める。結論だけ書かない。
+- 決定を覆すときは、古いエントリに superseded と明記して新しいエントリを足す。黙って矛盾する決定を並べない。
+- 6欄形式の導入前に記録された旧4欄エントリ（Alternatives considered / Revisit when を持たないもの）は有効として扱い、欄の不足をエラー・指摘・書き換えの対象にしない。
+- Anti-direction を空にしない。局所最適の具体例を最低数個挙げる。
+- コードを変更しない。
+
+## 出力
+
+`intent-compass.md` の `North Star / Current Drift / Direction / Anti-direction / Invariants / Decision Rules / Evidence / Open Questions` を更新（案として提示）する。

package/templates/ja/codex/skills/intent-compass/rules/constraint-surfacing.md

@@ -0,0 +1,41 @@
+# Constraint Surfacing（制約叩き台の候補提示）
+
+同梱のドメイン定石カタログ（`.intent/constraint-starters.md`）を read-only で照合し、Anti-direction / Invariants の**叩き台候補**を提示する手順。`/intent-compass` の Compass 構築フェーズで、Anti-direction / Invariant の**導出の前段**として使う。利用者が自分で育てた制約（`.intent/constraint-library.md`）があれば同様に候補へ加える。
+
+これは C2（局所最適の抑止＝Anti-direction/Invariant を compass に明示する器）の導出（影響リスト→Invariant 化・プレモータム→Anti-direction）を**置き換えない補助**である。既存の導出はそのまま行い、その前段に「文脈に合う定石の叩き台候補」を差し込むだけ。
+
+## 規律（守ること）
+
+- **提示は read-only の叩き台に留める。** 合致した定石を Anti-direction / Invariants へ**自動で書き込まない**。compass への転記は、利用者が採否を選んでから人の手で行う（利用者への確認は、このスキルが持つ確認手段で行う）。
+- **押し付けない。** 文脈に合わない定石を提示しない。候補は絞り、停止や強制を伴わない。当てはまりが弱ければ黙る（誤検知より黙る側に倒す＝叩き台機能の信頼を保つ）。
+- **照合は意味的に行う。** 定石の「適合する状況」を案件文脈に照らす読解で判断する。機械的な文字列スコアリング・正規表現一致に寄せない。
+- **既存導出を置き換えない・二重化しない。** 影響リスト→Invariant 化・プレモータム→Anti-direction の手順はそのまま。本手順は候補の供給を前段に足すだけ。
+- **カタログ不在なら沈黙する。** `.intent/constraint-starters.md` が不在のときは照合をスキップしてその旨を告げる（停止しない）。`.intent/constraint-library.md` も同様（不在ならスキップ）。
+- **どのログにも記録しない。** 提示は read-only の助言に留め、記録を持たない。
+
+## 手順
+
+1. **カタログを読む**
+   - `.intent/constraint-starters.md`（同梱の定石）と、あれば `.intent/constraint-library.md`（利用者が育てた制約）を read-only で読み、全定石（`## id:` 単位）を取得する。いずれも不在ならスキップして告げる（停止しない）。
+
+2. **各定石の「適合する状況」を案件文脈と照合する**
+   - 各定石の `適合する状況` を、いま書こうとしている compass の案件（題材・ドメイン・触る境界）に照らす。`適合する状況` は強い判定条件ではなく手がかりであり、当てはまりが弱ければその定石は出さない。
+   - 照合に使うのは案件の文脈のみ。コード差分・実行時メトリクスは読まない。
+
+3. **合致する定石を叩き台候補として提示する（書き込まない）**
+   - 合致した定石の `叩き台`（Anti-direction 候補・Invariant 候補）を、利用者に候補として提示する。例:「この案件は `<id>`（<name>）に当てはまるかもしれません — 叩き台として <Anti-direction 候補> / <Invariant 候補> はいかがですか（採否はお任せします）」。
+   - **compass へ自動で書き込まない。** 採用するかは利用者が判断し、採用したものだけを人の手で Anti-direction / Invariants へ取り込む。
+   - 非該当の定石は提示しない。候補が多すぎないよう絞る。
+
+4. **既存の導出へ進む**
+   - 候補提示の後、既存の Anti-direction / Invariant 導出（影響リスト→Invariant 化・プレモータム→Anti-direction）を通常どおり行う。提示した候補のうち利用者が採用したものは、その導出の中で人の手で取り込まれる。
+
+5. **採用した制約を個人台帳へ蓄積する（任意・人が手動/承認のもとで）**
+   - ③で提示した叩き台のうち、利用者が「これは自分の定番だ」と**採用した**制約があれば、それを個人台帳 `.intent/constraint-library.md` の確定スキーマ（`## id:` / name / 領域 / 適合する状況 / 制約 / 由来）で追記するよう案内する。次の案件で同梱カタログと並んで候補に出て、repo 内で再利用される。
+   - **自動で台帳に追記しない。** 追記は利用者が手動で行うか、利用者の明示承認のもとでのみ行う（自動的な蓄積は行わない＝read-only の堰）。**採用しなければ何も追記しない。** 既存の提示の挙動を変えない。
+   - **蓄積はこのプロジェクト内にのみ閉じる。** 追記先は当該プロジェクトの `.intent/` 配下の内側のみとし、プロジェクトをまたいで制約を共有・永続する仕組みは提供しない（横断蓄積は案内しない）。
+   - 個人台帳 `.intent/constraint-library.md` が不在のときは、蓄積をスキップしてその旨を告げる（停止しない＝後方互換）。
+
+## discover との関係
+
+- discover の地形診断レーン（`drift-terrain.md`）でも、`drift-watch: on` のとき同じカタログを薄く照合して早期に気づかせる。本手順（compass）が主接点であり、discover は補助。

package/templates/ja/codex/skills/intent-discover/SKILL.md

@@ -0,0 +1,60 @@
+---
+name: intent-discover
+description: Intent Planning の入口。リポジトリの課題感・README・既存コード概要から Intent Tree (L0-L4) を構築し、Intent の詰め方モードを推奨・確定する。実装はしない。
+---
+
+# intent-discover Skill
+
+## Core Mission
+- **Success Criteria**:
+  - L0–L4 の Intent Tree が構造化され、canonical（確定）と inferred（推測）が分離されている
+  - Intent の詰め方モードが推奨・確認され、`.intent/mode.local.md`（mode 状態のローカル正本）に記録されている
+  - 問いの代行（designer-questions）の要否が確認され `.intent/mode.local.md` に記録されている（on の場合は purpose も。保留時は Open Questions に告知）
+  - 人間が確認すべき Open Questions が明示されている
+  - drift-watch が on のとき、地形診断を行い該当型を名指しして drift-log に記録している（off のときは何もしない）
+  - drift-watch が on のとき、context-cost-cues を照合してコンテキストを食う進め方を気づき口調で名指している（どのログにも記録しない・off のときは何もしない）
+  - アプリケーションコードを一切変更していない
+
+## Execution Steps
+
+### Step 1: モードを選定する
+- `rules/mode-selection.md` を読み、適用する。
+- 利用可能なモード（`.intent/modes/*.md`）を確認し、リポジトリ状況からモードを推奨する。
+- 利用者に自然言語で問い、回答を待って確認する（候補が standard 1つでも推奨→確認の配線を通す）。
+- 確定結果を `.intent/mode.local.md`（mode 状態のローカル正本・git 非追跡）に記録する。Enforcement / Drift-watch（共有ポリシー）は `.intent/mode.md` のまま触らない。
+- **target format の推奨→追認→記録（任意・保留可）**: mode 確定に続けて、案件から target format（どの出口へ進むか＝ `cc-sdd` / `openspec` / `to-spec`）を推せる場合に利用者へ追認を求め、追認されたら `.intent/mode.local.md` の `format` 行へ記録する。判定材料は案件種別（mode・成果物がコードか文書か・`.kiro/` や repo 直下 `openspec/` の有無等）で、出口と format の対応は `intent-packets/rules/export-route.md`（出口判定レーン）と整合させる。**mode / designer-questions / purpose と同じ追認規律**に従う: 推論できない・利用者が保留/否認したら**推測で埋めず記録しない**（未指定のまま続行＝後で出口判定が推論経路に倒す）。format の記録は任意であり、書かなくても discover は従来どおり続行する。**format の書き手は `/intent-discover` のみ**（他スキルは read-only で読む・DR26）。
+- `rules/designer-questions.md` を読み、問いの代行（designer-questions）の確認・記録を行う。
+
+### Step 2: モード定義に従ってアルゴリズムを適用する
+- 確定したモード定義（例: `.intent/modes/standard.md`）を読む。
+- `.intent/mode.local.md`（無ければ旧 `.intent/mode.md`）の `definition` が指すモード定義を開き、Intent Tree 構築フェーズに割り当てられた algo rule（`rules/algo-*.md`）を読み、適用する（standard なら `rules/algo-gore-lite.md`、refactor なら `rules/algo-gore-lite.md` + `rules/algo-drift-analysis.md`、意図不在のコードでは加えて `rules/algo-intent-recovery.md`）。例は網羅ではない。常にモード定義の表を正とする。
+
+### Step 3: Intent Tree を構築する
+- GORE-lite に従い L0（目的）→ L1（成果）→ L2（能力）→ L3（振る舞い/設計意図）→ L4（候補パケット）を分解する。
+- 確定した意図と推測（Assumptions）を分離する。未確定は Open Questions に置く。
+- 既存の `.intent/intent-tree.md` があれば読み、上書きではなく追記・更新案として提示する。
+
+### Step 3.5: 地形診断（drift-watch）
+- Step 1 で読んだ `.intent/mode.md` の `## Drift-watch（ユーザー管理）` セクションから `drift-watch` の値を確認する。`on` でないとき（off・未記載・不正値・セクション不在・mode.md 不在を含む）は地形診断を行わず、現行どおり Step 4 へ続行する（現行動作とバイト等価）。
+- `on` のときのみ、`rules/drift-terrain.md` を読み、適用する。symptom × 構築中 Intent Tree の照合・該当型の名指し提示・anti-direction / invariant 候補の Open Questions への起案・drift-log への append は、すべて rule の手順に委ねる（ここに手順を複製しない）。同 rule 末尾の「コンテキストコストの気づき」節も併せて適用し、`.intent/context-cost-cues.md` の型を照合してコンテキストを食う進め方を気づき口調で名指す（どのログにも記録しない・カタログ不在ならスキップ）。
+
+### Step 4: 提示する
+- `.intent/intent-tree.md` の更新案を提示する。
+- `rules/designer-questions.md` の Intent Tree 追加確認（L1 計測基準・画面ラフ）を、rule の適用条件に従って適用する。
+- 実装変更はしない。リファクタ案を先走って出さない。
+
+## Output Description
+
+**読み手**: これから意図を詰め始める人間開発者。
+**この出力で最初に掴ませること**: 「Intent Tree の骨子ができた。**次は `/intent-compass`**。ただし確定前に答えるべき Open Questions はこれだけ」。
+
+出力は結論を先頭に立てる。
+
+- **次の一手（先頭・1行）**: `/intent-compass`（判断基準づくり。局所最適を防ぐ Invariants/Anti-direction を定める）。
+- **確認が要る Open Questions**: 人間が確定させるべき不明点（推測で埋めず質問として残したもの）。次に進む前にここだけ片付ければよい、と分かる形で。
+- **詳細（成果物の更新案）**: `.intent/intent-tree.md` の更新案（L0–L4 / Open Questions / Assumptions。canonical と inferred を区別）、確定したモード（`.intent/mode.local.md`）、確定した designer-questions / purpose。
+
+## Safety & Fallback
+- 入力（課題・対象範囲）が曖昧なら、推測で埋めず利用者に自然言語で問い、回答を待つ。
+- 既存の Intent Tree がある場合は破壊せず、差分を更新案として提示する。
+- アプリケーションコードは変更しない。

package/templates/ja/codex/skills/intent-discover/rules/algo-drift-analysis.md

@@ -0,0 +1,34 @@
+# Algorithm: Drift Analysis
+
+現状の実装/構造と、あるべき設計意図とのズレ（drift）を観測可能に捉える。`refactor` モードの discover フェーズで GORE-lite と併用し、L0–L4 のうち特に L3（振る舞い・設計意図）と現状の乖離を明らかにする。
+
+## 手順
+
+1. **現状を棚卸しする（入力）**
+   - 対象リポジトリの構造・依存方向・主要な振る舞い、テストの有無を把握する。網羅は不要だが、**後段の Migration Slicing が実用的なスライスを切れる程度に drift を厚くする**こと（薄い棚卸しは薄い drift リストを生み、スライスが推測になる）。意図と突き合わせられる粒度を目安にする。
+   - 暗黙の設計意図（GORE-lite で起こした L1–L3）を手元に置く。あるべき設計意図が現状から起こせない（仕様が完全に失われている）場合は、refactor ではなく `behavior-unknown` モードが適することがある。discover でその兆候が出たら mode の見直しを Open Questions に記す。
+
+2. **Reflexion worksheet で突き合わせる**
+   - 突き合わせには Software Reflexion Models（Murphy & Notkin）の構造を借りた軽量ワークシートを使う。主要コンポーネントを **1回の分析につき 5〜15 要素**に絞り（広く浅くではなく、重要箇所を狭く深く）、各要素について次を並べる:
+     - **意図された責務・依存**（Intent 由来: 対応する L1 Desired Outcome / L2 Capability / L3 Behavioral・Architectural Intent）
+     - **観測された責務・依存**（コード読解由来: import/参照関係・ディレクトリ構造・呼び出しの向きを読む程度で十分）と、その**証拠**（ファイル・コード箇所）
+   - 各要素を **整合（convergence）/ 乖離（divergence）/ 欠落（absence: 意図にはあるが実装に見当たらない）** のいずれかに分類する（乖離=worksheet の分類。drift 類型の「逸脱」とは区別する）。
+   - これにより drift リストは「気になることの列挙」ではなく、意図モデルとの関係で定義された差分リストになる。
+
+3. **drift を列挙する**
+   - worksheet の divergence / absence を drift として起こす。各 drift は「現状 → あるべき」の対で書き、**差分種別（divergence / absence）・証拠・確からしさ（証拠が直接的か、推測を含むか）**を付ける。憶測の原因論には踏み込まない。
+   - 解釈として、逸脱（意図と反する設計）、腐敗（時間経過で崩れた境界・依存）、局所最適の蓄積（個別最適が全体意図を侵食）の種類を区別する。
+
+4. **各 drift を parent intent へ分類する**
+   - 各 drift が「どの Intent からの逸脱か」を特定し、対応する L1/L2/L3 に紐づける。
+   - 紐づく Intent が曖昧・未確定なものは Open Questions へ送る。
+
+## 規律
+
+- **計画技法であって実行ではない**: drift を捉えるのは Intent の詰め方であり、ここでリファクタやコード変更は行わない。
+- **事実と推測を分ける**: 観測した現状は事実として、原因・対応方針の推量は `Assumptions` に分離する。
+- **未確定は Open Questions へ**: どの intent からの逸脱か判断できないものは、推測で埋めず Open Questions に書く。
+
+## 出力
+
+drift のリスト（現状 → あるべき、差分種別と逸脱の種類、証拠と確からしさ、対応する parent intent）。GORE-lite の `intent-tree.md` の L3 と Open Questions / Assumptions に反映（案として提示）する。

package/templates/ja/codex/skills/intent-discover/rules/algo-gore-lite.md

@@ -0,0 +1,35 @@
+# Algorithm: GORE-lite
+
+Goal-Oriented Requirements Engineering の軽量版。暗黙の意図を L0–L4 のゴール階層へ段階分解する。全モード共通の Intent Tree 構築フェーズで使う（standard / refactor / behavior-unknown のいずれも本 algo を基盤にする）。
+
+## 手順
+
+1. **L0: Product Purpose を1〜2文で固定する**
+   - 「このプロダクト/サブシステムは何のために存在するか」。手段ではなく存在理由を書く。
+
+2. **L1: Desired Outcomes を引き出す**
+   - L0 を満たすために、誰の・何の状態をどう変えたいか。観点はユーザー / 事業 / 運用 / 開発体験。
+   - 「機能」ではなく「起こしたい状態変化」で書く。
+   - **Actor pass**: 各 Outcome について「誰が利益を得るか / 誰が阻害・反対しうるか / 誰がその実現に責務を持つか / どんな環境前提に依存するか」を一行ずつ書く（i* 系のアクター/依存の観点）。アクター不在の目的階層は、実装時に責務の置き場所を誤らせる。確信が持てない行は Assumptions へ。
+
+3. **L2: Capabilities へ分解する**
+   - 各 Desired Outcome を支える能力を列挙する。機能名ではなく責務・能力として書く。
+   - 「○○できる」という能力の単位。実装手段には踏み込まない。
+
+4. **L3: Behavioral / Architectural Intents を導く**
+   - 各 Capability を成立させる振る舞い・設計意図。境界、依存方向、副作用、データ整合性、UI/UX 制約を含める。
+   - ここは「なぜその設計か」の意図であり、実装そのものではない。
+
+5. **L4: Candidate Packets を出す**
+   - 実装手前の候補作業単位。Issue より上位、spec より手前の粒度。
+   - 各候補がどの L1/L2/L3 を支えるかを意識する（packet 化のときに parent intent になる）。
+
+## 規律
+
+- **canonical と inferred を混ぜない**: 確定した意図は本文に、推測は `Assumptions` セクションに分離する。根拠が無い断定をしない。
+- **未確定は Open Questions へ**: 分解の途中で判断が必要だが情報が足りないものは、推測で埋めず Open Questions に書く。
+- **コードを変更しない**: discover は意図の構造化であり、実装ではない。
+
+## 出力
+
+`intent-tree.md` の `L0 / L1 / L2 / L3 / L4 / Open Questions / Assumptions` セクションを更新（案として提示）する。

package/templates/ja/codex/skills/intent-discover/rules/algo-impact-analysis.md

@@ -0,0 +1,37 @@
+# Algorithm: Impact Analysis
+
+新機能が既存のどの境界・契約・データフローに触れるかを、実装前に棚卸す。`feature-growth` モードの discover フェーズで GORE-lite と併用する。変更影響分析（Change Impact Analysis: Bohner & Arnold）の発想を、ツール前提の依存解析から LLM の読解ベースの計画技法へ翻訳したもの。Drift Analysis が「現状と意図のズレは何か」を問う（refactor の discover）のに対し、Impact Analysis は「この付加は既存の何に触れるか」を問う — 問いが違うため、両者は置き換え可能ではない。
+
+## 手順
+
+入力＝新機能の intent（GORE-lite で階層化済みの L1–L4）と既存コードベース。
+
+1. **起点集合を特定する**
+   - 新機能の intent（特に L3/L4）から、既存コードベースのどこに接触しそうかの起点（モジュール・レイヤ・API・データ）を挙げる。新機能が「読む・呼ぶ・拡張する」対象の候補。
+   - 既存コードベースの構造把握は LLM の読解で行う: import/参照関係・ディレクトリ構造・呼び出しの向きを読む程度で十分（AST 解析や静的解析ツールを前提にしない）。
+
+2. **波及をたどる**
+   - 各起点から「ここに触れると、他に何が影響を受けるか」を依存の向きに沿って一段ずつたどり、候補を広げる（CIA の起点集合→候補影響集合の発想）。網羅は不要だが、**後段の Additive Slicing が接合点（seam）を設計できる程度に影響リストを厚くする**こと（薄い棚卸しは接合点を推測にする）。
+   - 各候補に**証拠**（ファイル・コード箇所）を付ける。読解で確認できない波及は推測として扱い、`Assumptions` へ分離する。
+
+3. **影響リストへ構造化する**
+   - 候補を影響リストとして起こす。各項目は次の3点で構造化する:
+     - **触れる境界**: モジュール / レイヤ / API
+     - **依存する既存契約**: API シグネチャ・データスキーマ・イベント・振る舞い
+     - **影響の種類**: 読む / 呼ぶ / 拡張する / 変更が必要
+   - この構造が後段の契約になる: compass では各項目を保護 Invariant（「X の既存契約を変えない」）へ起こし、packets では Additive Slicing が接合点設計の入力に取る。
+   - 「変更が必要」が支配的なら、それは付加ではなく再設計の兆候 — モードの見直し（refactor）を Open Questions に記す。
+
+4. **drift を見つけたら送り先を分ける**
+   - 調査中に既存設計の構造的問題（drift: 腐った境界・意図と食い違う依存など、feature-growth の目的外の問題）を発見したら、**本モード内で修正せず**、Open Questions へ記録して refactor モードでの別作業を推奨する。影響リストには「新機能が触れる」という事実だけを残す。
+
+## 規律
+
+- **計画技法であって実行ではない**: 影響の棚卸しは Intent の詰め方であり、ここでコード変更や seam の実装は行わない。
+- **ついでリファクタの構造的禁止**: drift を見つけても feature-growth 内で直さない。Open Questions + refactor 推奨へ送る。
+- **事実と推測を分ける**: 読解で確認できた影響は証拠付きの事実として、確認できない波及の推量は `Assumptions` に分離する。
+- **未確定は Open Questions へ**: 触れるかどうか判断できない境界は、推測で埋めず Open Questions に書く。
+
+## 出力
+
+影響リスト（各項目: 触れる境界 / 依存する既存契約 / 影響の種類、証拠付き）。compass の Invariants 化と、packets の Additive Slicing による接合点設計の入力になる。未確定分と発見した drift は `intent-tree.md` の Open Questions / Assumptions に反映（案として提示）する。

package/templates/ja/codex/skills/intent-discover/rules/algo-intent-recovery.md

@@ -0,0 +1,39 @@
+# Algorithm: Intent Recovery
+
+意図を書かずに（vibe coding で）作られた既存コードから、事後的に intent を復元する技法。`refactor` モードの discover フェーズで GORE-lite と Drift Analysis の間に入る。Drift Analysis は「あるべき設計意図」を基準点に現状との差分を測るが、vibe coding されたコードはその基準点自体が存在しない。本技法はコードの観測事実から候補 intent を逆算し、Drift Analysis に渡せる基準点を作る。
+
+## いつ使うか
+
+- 既存コードが、明示的な設計意図・spec・設計ドキュメントなしに書かれている（vibe coding、prototype の本番化、退職者の遺産など）。
+- GORE-lite で L0–L3 を起こそうとしても「あるべき姿」が人の頭にもドキュメントにも無く、コードからしか起こせない。
+- 振る舞い自体は観測可能だが（→ そこは behavior-unknown ではない）、その振る舞いを生んだ**意図が不在**。
+
+## 手順
+
+入力＝意図不在の既存コード（構造・依存・主要な振る舞い）。出力＝逆算した候補 intent（L0–L3、すべて inferred）。
+
+1. **コードから候補 intent を逆算する**
+   - 構造・依存方向・主要なデータフロー・繰り返し現れるパターンから、「このコードは何を達成しようとしているように見えるか」を L1（成果）/ L2（能力）/ L3（振る舞い・設計意図）として起こす。
+   - これは観測されたコードからの**推測**であり、作者の真の意図ではない。
+
+2. **復元した intent を必ず inferred として置く**
+   - 逆算した L0–L3 は canonical（確定）ではなく **inferred（推測 = Assumptions）** に置く。vibe coding では「たまたまそう書いた」と「そう設計した」の区別がコードに残っていないため、確定と混ぜると捏造した意図を事実として扱う罠に落ちる。
+   - 復元の根拠（どのコード観測から起こしたか）を各 inferred intent に併記する。
+
+3. **意図的か偶発かを仕分け、確証は人へ差し戻す**
+   - 復元した各 intent について「設計判断の結果」か「偶発・成り行き」かを仕分ける。判断できないものは推測で確定させず **Open Questions** へ送り、人間の確認を仰ぐ。
+   - 人間が確認・追認した intent のみ、後段で canonical に昇格してよい。
+
+4. **Drift Analysis へ基準点として渡す**
+   - 復元した（inferred な）候補 intent を、後続の Drift Analysis の「あるべき設計意図」側の入力にする。これにより Drift Analysis は「復元した意図 → 現状コード」の drift を測れるようになる。
+   - 復元 intent が薄いと drift も薄くなるため、Drift Analysis が実用的な drift を出せる程度に L1–L3 を起こす。
+
+## 規律
+
+- **復元であって正当化ではない**: コードがそう書かれている事実から intent を起こすのであって、「既存コードは正しい」と追認するのではない。誤った設計・不要な複雑さも intent 候補として起こし、Drift / Open Questions で扱う。
+- **必ず inferred**: 復元 intent を canonical と混ぜない。人間の追認なしに確定へ昇格させない（GORE-lite の canonical/inferred 分離を厳守）。
+- **計画技法であって実行ではない**: ここでコードを変更しない。
+
+## 出力
+
+逆算した候補 intent（L0–L3、すべて inferred、復元根拠と意図的/偶発の仕分け付き）。`intent-tree.md` の該当 L レベルと Assumptions / Open Questions に反映（案として提示）し、Drift Analysis の入力にする。

package/templates/ja/codex/skills/intent-discover/rules/designer-questions.md

@@ -0,0 +1,78 @@
+# Designer Questions（設計者役の詰めの問い）
+
+設計者役の詰めの問い（designer-questions）の要否確認・記録と、on のときに追加する質問群の手順。`/intent-discover` のモード確定後（Step 1）と Tree 更新案の提示時（Step 4）で使う。対話はすべて利用者への確認として行う（確認の手段は SKILL.md の規約に従う）。
+
+## 手順
+
+### モード確定後（Step 1）
+
+1. **設計者役の詰めの問いの要否を確認する**
+   - `.intent/mode.md` の `designer-questions` を読む。canonical 値は `on` / `off` の2トークン。
+   - 未確定なら、設計者役の詰めの問いが何を確認するものかを説明した上で（次の4点を列挙する: L1（成果）の成功基準の計測可能化 / 最初の packet（作業単位）が walking skeleton（入力から出力まで一通り動く最小実装）になっているかの確認 / ユーザー向け画面がある場合の画面ラフの有無 / 検証（PoC）の場合の仮説と完了判定）、推奨はせず2択（`on` = 要 / `off` = 不要）を提示して利用者に確認する。
+   - 記録済みなら、記録内容（designer-questions / purpose）を提示して変更の要否のみを確認する。
+   - 利用者が決定を保留したら、推測で埋めず「設計者役の詰めの問いの要否が未確定」を Open Questions に記録して続行する。
+
+2. **確定した designer-questions を記録する**
+   - `.intent/mode.md` の `designer-questions` 行に確定したトークンを書く。後続スキル（intent-packets / intent-validate）はこの行を参照する。
+   - **旧 scaffold への非破壊追記**: mode.md に designer-questions / purpose 行が無ければ、既存の mode / selected / reason / definition 行を保持したまま不足行を追記する。intent-tree.md に「PoC 実験定義」「画面ラフ参照」セクションが無ければ、既存セクションを保持したまま追記してから記録する。
+
+2.5. **目的・成功・想定ユーザーの追認（designer-questions の値に関わらず発火）**
+   - 推論で導出した L0 目的・成功の定義を利用者に追認する: `.intent/intent-tree.md` の L0（Product Purpose）と L1（Desired Outcomes）に置いた推論内容を提示し、「この目的・成功の捉え方で合っているか」を確認する。
+   - 推論した想定ユーザー・利用文脈（Actor）を利用者に追認する: 「誰がどんな状況でこれを使うと想定しているか」を提示し、合っているかを確認する。
+   - 各確認は「該当なし／不明／後で確認」を選べる形で提示し、回答を強制しない。これは推論+確認の哲学に基づく追認であり、機能要件の全面的な能動質問化は**しない**（L2〜L4 を一つずつ聞き出すのではなく、根の目的・成功・想定ユーザーの捉え方が誤っていないかだけを確かめる）。
+   - 利用者が追認した内容は当該 L0/L1 直下に canonical として確定する。想定ユーザーは L1 の Actor として L1 直下に記録する。利用者が訂正したら、その訂正内容で canonical を置き換える。
+   - 利用者が保留・「後で確認」を選んだ項目は、推測で埋めず `.intent/intent-tree.md` の Open Questions（export までに要回答なら `[export まで]` タグ）または Assumptions（仮の前提として置く場合）へ逃がして続行する。planning は止めない。
+
+2.6. **解収束度の判定と解先当て確認（designer-questions の値に関わらず発火）**
+   - 手順 2.5 の直後に、利用者の要望（idea・対象範囲）と構築中の Intent Tree を読み、要望が目指す target architecture（構成）の**解収束度**を判定する。判定は LLM の読解で行い、外部解析ツール・機械的スコアリングには依存しない。
+   - 収束/発散/判断不能の3分岐で扱う:
+     - **収束**（要望が特定の構成をほぼ一意に含意する。確立パターンに当てはまる）→ 下記の解先当て1問確認へ進む。
+     - **発散**（複数の妥当な解が成り立つ）→ 解を先に当てず従来経路（手順7の anchoring 回避を適用し、Impact Analysis の棚卸し・中立な選択肢提示）へ進む。
+     - **判断不能** → 推測で確定せず**発散として扱い**、判断できない旨を `.intent/intent-tree.md` の Open Questions に記録して続行する。
+   - 確立パターンの例示は数個に留め、網羅列挙しない（例: cron 化・CLI 化・ワンショット化 等。fixation を避け、例は手がかりであって解の空間ではない）。
+   - **収束時の解先当て1問確認**:
+     - Impact Analysis の棚卸し・中立な選択肢提示より**先に**、推論した構成を「目指す構成はこれですよね」と**1問で**確認する（中立な複数選択肢へ分解しない）。
+     - 確認は「該当なし／不明／後で確認」を選べる形で提示し、回答を強制しない。
+     - 結果は手順 2.5 と同型の記録規律で扱う: **追認** → 推論した target architecture を `.intent/intent-tree.md` に canonical として記録する（記録先は該当 L3（設計意図）直下、または L1/L2 直下の構成方針として既存セクションを使う。新セクションは作らない）。**訂正** → 訂正された構成で canonical を置き換える。**保留・後で確認** → 推測で確定せず Open Questions（export までに要回答なら `[export まで]` タグ）へ逃がして続行する（planning は止めない）。
+     - 解先当ては構成の**確認・記録まで**で、実装・コード生成はしない。
+
+3. **検証性を確認する（designer-questions=on のときのみ）**
+   - この開発が「何かを確かめる検証（PoC = `poc`）」か「本番・継続開発（= `product`）」かを利用者に確認し、`.intent/mode.md` の `purpose` 行に記録する。
+   - on 確定直後に加え、再実行で designer-questions が on と記録済みかつ purpose が未確定の場合もこの確認を行う。
+   - 利用者が決定を保留したら、推測で埋めず「purpose が未確定」を Open Questions に記録して続行する。
+
+4. **PoC の3つの質問（仮説・反証条件・GO/NO-GO。purpose=poc 確定直後のみ）**
+   - 次の順で利用者に質問する: 仮説（この PoC で何を確かめるか）→ 反証条件（何が観測できなければ仮説を棄却するか）→ GO/NO-GO 基準（PoC 完了後に先へ進む / やめるを判定する条件）。
+   - 回答を `.intent/intent-tree.md` の「PoC 実験定義」へ canonical として記録する。回答できない項目は推測で埋めず Open Questions に記録して続行する。
+   - **purpose が poc でないときは、この質問群を発火しない。**
+
+### Tree 更新案の提示時（Step 4・designer-questions=on のみ）
+
+5. **L1 計測基準を確認する**
+   - 各 L1 項目について「達成をどう観測・判定するか」を利用者に確認し、該当 L1 項目に `計測基準:` 行として記録する。
+   - 基準が定まらない項目は、L1 項目自体は保持したまま「基準未定」を Open Questions に記録する。
+
+6. **画面ラフの有無を確認する**
+   - まず L2/L3 にユーザー向け画面が含まれるかを判定する。
+   - 該当なら、画面ラフの有無を利用者に確認する: 有 → 参照（ファイルパスまたはリンク）を「画面ラフ参照」に記録する。無 → 作成を推奨する。利用者が見送る場合は、その旨を理由付きで Open Questions または「画面ラフ参照」に記録して続行する。
+   - 非該当なら、利用者への確認は行わず、「画面ラフ参照」に「対象外」を**必ず**記録する（intent-validate が推論なしで判定できるようにするため）。
+   - ラフ自体の作成・生成はしない（有無の確認・推奨・参照の記録まで）。
+
+6.5. **tree 版 omission recap で抜け・過剰を確認する**
+   - Tree 更新案を確定する前に、推論・収集した L0–L3（目的・成功・想定ユーザー・主要な成果と機能の枝）を短く要約して返し、「抜けているもの・逆に過剰な前提はないか」をユーザーに確認する（LLM の見落とし・ハルシネーションを人間が補正する材料として提示する）。これは機能要件にも適用する omission recap であり、L2〜L4 を一つずつ聞き出すものではない。
+   - ユーザーが**抜け**を指摘した場合は、その項目を `.intent/intent-tree.md` の該当セクションへ反映して再提示する: 目的・成功の抜け → L0（Product Purpose）／L1（Desired Outcomes）直下／想定ユーザーの抜け → L1 の Actor として L1 直下／成果・機能の枝の抜け → 該当する L1 直下の枝。
+   - ユーザーが**過剰**を指摘した場合は、確認のうえ当該項目を canonical（intent-tree.md の該当セクション）から除去する。確信が持てない場合は除去せず `.intent/intent-tree.md` の Assumptions へ降格する（仮の前提として残す）。除去前に必ずユーザーへ確認する。
+   - 各確認は「該当なし／不明／後で確認」を選べる形で提示し、回答を強制しない。保留・「後で確認」を選ばれた論点は推測で埋めず `.intent/intent-tree.md` の Open Questions（export までに要回答なら `[export まで]` タグ）へ逃がして続行する。
+   - 再編集は最大1往復に留める（recap で延々と対話しない）。残る論点は `.intent/intent-tree.md` の Open Questions へ逃がす。
+
+7. **制約下の意思決定（④）の posture を確認する**
+   - L2/L3 の能力のうち、データの書き換え・外部入力/システム境界・アクセス制御を伴うものを短く要約して提示し、「この機能群で、整合性・冪等性・エラー時の挙動・誰がアクセスできるか、を決めておくべき箇所はどれか」を**まとめて一度だけ**確認する（④の各項目を一つずつ能動質問化しない。omission recap と同じ「抜けていないかの確認」として行う）。
+   - これは決定そのものを今ここで埋める手順ではなく、**どの能力に決定スロット（④）を播くべきかの posture を捉える**手順である。**解が発散している設計判断に限り**、妥当な既定値は提示しない（anchoring bias の回避）。一方、手順 2.6 で**収束**と判定された構成要望には anchoring 回避を適用せず、推論した解を先に当てる（手順 2.6 の解先当てを参照）。スロットの一覧・発火条件は `intent-packets/rules/decision-slots.md` が正本（その anchoring 回避規律は本手順の限定に関わらず不変）。
+   - 利用者が「ここは決めておくべき」と指したものは、該当 L3 直下に「決定が要る点（④）」として `.intent/intent-tree.md` に記録する（具体値はまだ書かない。実際のスロット播種と値の確定は intent-packets が packet 単位で行う）。
+   - **高コストな決定に限り consider-the-opposite を促す**: 利用者が高コストな決定（認可・整合性・エラー意味論・後方互換）について方針を選んだ場合に限り、その方針が不適切になりうる条件（脅威・エッジケース・適用外の状況）を1つ以上挙げるよう促す（確証バイアスの緩和）。挙がった条件は当該「決定が要る点（④）」に併記して `.intent/intent-tree.md` に記録する。
+   - この反証の促しは高コストな決定にのみ課す。全スロットに摩擦を課して対話を重くしない（decision fatigue の回避）。
+   - 各確認は「該当なし／不明／後で確認」を選べる形で提示し、回答を強制しない。保留は推測で埋めず Open Questions へ逃がして続行する。
+
+## designer-questions が off のとき
+
+off のとき発火するのは、手順 1〜2 の要否確認と、手順 2.5（目的・成功・想定ユーザーの追認）、および手順 2.6（解収束度の判定と解先当て確認）のみ。手順 3〜7（検証性確認・仮説3質問・L1計測基準・画面ラフ・④ posture）と手順 6.5（tree版 recap）は発火しない。L0 目的・成功・想定ユーザーと解の形（target architecture）は PoC 専用情報（手順 3〜6）と性質が異なり、product 開発でも意図の根として必要なため、off の最小構成にも含める（解が自明な要望で回り道を防ぐ効果は off でも有効）。purpose の値が残っていても、designer-questions が on と記録されていない限り参照しない。

package/templates/ja/codex/skills/intent-discover/rules/drift-terrain.md

@@ -0,0 +1,105 @@
+# Drift Terrain（地形診断）
+
+`/intent-discover` の Step 3.5 で使う、symptom × 構築中 Intent Tree の照合ロジック。`drift-watch: on` のときだけ走る（off / 未記載 / 不正値は何もしない）。着手前に「この題材は踏みやすい地形だ」と名指しし、外れきる前に anti-direction / invariant を先に書かせるのが目的。
+
+## 診断の根拠は型カタログのみ
+
+- **診断の根拠は `.intent/drift-patterns.md` の型カタログだけ**にする。discover の段階では compass も packet もまだ無いため、照合できる材料は型カタログしかない（本質的な制約）。compass の Invariant / Anti-direction を根拠にした照合は export 工程（drift-watch の別フック）の役目であり、ここでは行わない。
+- 地形診断は**誤検知前提**。型に「該当した」ことは逸脱の確定ではない。弱い手がかりで早めに名指しし、空振りも含めて記録する。
+
+## 手順
+
+1. **drift-patterns.md を読む**
+   - `.intent/drift-patterns.md` を読み、全型（seed + 利用者が育てた型すべて）を取得する。
+   - **不在のとき**: 地形診断をスキップし、その旨を利用者に告知する（停止しない / drift-log にも書かない）。以降の手順は実行しない。
+
+2. **各型の symptom を構築中の Intent Tree と照合する**
+   - 各型の `symptom` を、いま構築している Intent Tree の**題材（topic）と L0–L3**（目的 / 成果 / 能力 / 振る舞い・設計意図）に照らす。
+   - `symptom` は**弱い手がかり**であって「当てはまったら必ず逸脱」という強い判定条件ではない。誤検知前提で、疑わしければ拾う。
+
+3. **該当型があるとき**
+   - 利用者に**名指しで提示**する。例:「この題材は `<id>` を踏みやすい地形です」。
+   - その型の「先に書かせるもの」（Anti-direction / Invariant 候補）を、Intent Tree の **Open Questions / anti-direction 候補**へ追記する。題材に依存する部分は文脈から具体化する（型カタログの汎用文をそのまま貼らず、いまの題材に即した文面にする）。
+   - `drift-log.md` へ1エントリ append する（後述の append 手順）。値は:
+     - `pattern: <該当型の id>`
+     - `stage: discover`
+     - `packet: -`（discover 段階では packet 未確定）
+     - `mechanism: pattern-catalog`
+     - `outcome: prevented`（**下書き**。drift-watch の推定であり、確定は利用者の `user-verdict`）
+     - `user-verdict: unjudged`
+     - `recorded_at: <ISO 8601>`
+     - `commit: <短縮ハッシュ | ->`
+     - `note: <1〜2行>`（何を名指しし、何を先に書かせたか）
+   - 複数型が該当したら、型ごとに1エントリずつ append する。
+
+4. **該当型がないとき（空振り / not-applicable）**
+   - 空振りも**必ず記録する**。`missed=0` を「効いた証拠」と誤読しないため、何も該当しなかった瞬間も均等に残す（確証バイアスの構造的回避）。
+   - `drift-log.md` へ1エントリ append する。値は:
+     - `pattern: -`（該当型なし。`uncatalogued:<短い名>` はカタログ外の実逸脱を指すときの値なので、空振りでは使わず `-` とする）
+     - `stage: discover`
+     - `packet: -`
+     - `mechanism: none`
+     - `outcome: not-applicable`
+     - `user-verdict: unjudged`
+     - `recorded_at: <ISO 8601>`
+     - `commit: <短縮ハッシュ | ->`
+     - `note: <1〜2行>`（地形に該当型が無かった旨）
+
+## drift-log への append 手順
+
+- **分割形で書く（CONTRACT「append-only 記録の分割・archive 規約」）**: drift-log は事象由来なので、単一 `drift-log.md` 末尾へ追記せず **日付+slug 単位の分割ファイル** `drift-log/<date>-<slug>.md` へ1エントリ書く。`<date>` は recorded_at の日付、`<slug>` は pattern（事象）を既存スラッグ規則（`intent-packets/rules/packet-format.md`）で導出する（新採番・連番を作らない）。別事象が別ファイルを触るため末尾衝突が原理的に消える。既存エントリは書き換え・削除しない（**append-only**）。
+- **9キーを固定順で必ず全部書く**: `pattern` → `stage` → `packet` → `mechanism` → `outcome` → `user-verdict` → `recorded_at` → `commit` → `note`。9キーのうち1つでも欠けたエントリは書かない。
+- **recorded_at**: 記録時刻を ISO 8601 で書く（transaction time）。
+- **commit**: `git rev-parse --short HEAD` の結果を書く。非リポジトリ・git CLI 不在などで取得できないときは `-` とする（fail-open。記録は続行する）。
+- **`drift-log/` ディレクトリが不在のとき**: ディレクトリを作ってから分割ファイルを書く。旧単一 `drift-log.md` が残っていても読み手は共存して読める（移行は本スライスの migration が担う）。
+- エントリ書式は `.intent/drift-log.md` の「エントリ書式」節の見本（`### drift-log entry`）に従う。
+
+## コンテキストコストの気づき（drift-watch 連動）
+
+地形診断と並んで、コンテキスト（トークン）を食う進め方に**気づかせる**照合を行う。drift-patterns（意図逸脱の型）とは**別カタログ**であり、症状（symptom）が「意図逸脱」ではなく「コンテキストを食う場面」である点だけが異なる。これは規範ではなく気づきであり、上の drift-patterns 照合とは性質が違うので**手順を分けて持つ**。
+
+- **`drift-watch: on` のときだけ**この照合を行う（off / 未記載 / 不正値のとき何もしない）。`.intent/context-cost-cues.md` が不在のときは照合をスキップしてその旨を告知する（停止しない）。
+- **これはどのログにも記録しない**。上の drift-patterns 照合（該当・空振りで `drift-log.md` へ append する）とは異なり、コンテキストコストの気づきは **`drift-log.md` にも他のどのログにも append しない**。理由: 消費量は計測できず outcome を評価できないため、ログに混ぜると drift-log の集計を推測値で汚す。さらに何が文脈を食うかは人により正当に異なり、記録すればプライバシーに踏み込む。**上の「drift-log への append 手順」をこの照合には適用しない**。
+
+### 手順
+
+1. **context-cost-cues.md を読む**
+   - `.intent/context-cost-cues.md` を読み、全型（seed + 利用者が育てた型すべて）を取得する。不在ならスキップして告知する（停止しない）。
+
+2. **各型の symptom を構築中の Intent Tree と照合する**
+   - 各型の `symptom` を、いま構築している Intent Tree の題材・進め方（topic と L0–L3）に照らす。`symptom` は弱い手がかりで、当てはまりが弱ければ黙る（誤検知より黙る側に倒す＝気づき機能の信頼を保つ）。
+   - 照合に使うのは構築中の Intent Tree の題材のみ。トークン消費量・git 差分・実行時メトリクスは読まない。
+
+3. **該当型があるとき（気づきの提示・ログには書かない）**
+   - 利用者に気づき口調で名指しする。例:「この題材は `<id>` に当てはまるかもしれません — これがコンテキストを食っている可能性があります」。
+   - その型の「もし意図せず効いていれば」の軽い代替（薄い入口 / JIT pull / 入力限定）を、**任意の選択肢**として添える。例:「もし意図せず効いていれば、<軽い代替> もあります（判断はお任せします）」。
+   - **矯正・指図をしない**。命令形・断定で言わず、気づきの提示に留める。大量スキルの導入・全文ロード等は正当な高コスト選択でありうるので、コストを食う選択を不要と断じない。判断は利用者に委ねる。
+   - **どのログにも append しない**（drift-patterns 照合の append 手順を流用しない）。
+
+4. **該当型がないとき**
+   - 何も名指さない。**ログにも書かない**（空振りの記録もしない＝そもそもこの照合はログを持たない）。
+
+## 制約の叩き台の気づき（drift-watch 連動）
+
+地形診断と並んで、ドメイン定石の叩き台に**早く気づかせる**薄い照合を行う。これは compass を主接点とする制約叩き台の候補提示（`intent-compass/rules/constraint-surfacing.md`）の discover 側の補助であり、上の照合とは別カタログ（`.intent/constraint-starters.md`＝再利用したい制約定石）を見る。意図逸脱・コンテキストコストとは症状が異なるので**手順を分けて持つ**。
+
+- **`drift-watch: on` のときだけ**この照合を行う（off / 未記載 / 不正値のとき何もしない）。`.intent/constraint-starters.md` が不在のときは照合をスキップしてその旨を告知する（停止しない）。
+- **これはどのログにも記録しない**。上の drift-patterns 照合（`drift-log.md` へ append する）とは異なり、制約の叩き台の気づきは **`drift-log.md` にも他のどのログにも append しない**（context-cost-cues の気づきと同じ扱い）。
+- **これは提示であって自動転記ではない**。候補に気づかせるだけで、Anti-direction / Invariants へ自動で書き込まない。採否・記述は compass で人が行う（主接点）。
+
+### 手順
+
+1. **constraint-starters.md を読む**
+   - `.intent/constraint-starters.md`（同梱の定石）と、あれば `.intent/constraint-library.md`（利用者が育てた制約）を read-only で読み、全定石（`## id:` 単位）を取得する。いずれも不在ならスキップして告知する（停止しない）。
+
+2. **各定石の「適合する状況」を構築中の Intent Tree と照合する**
+   - 各定石の `適合する状況` を、いま構築している Intent Tree の題材・ドメインに照らす。`適合する状況` は弱い手がかりで、当てはまりが弱ければ黙る（誤検知より黙る側に倒す）。
+   - 照合に使うのは構築中の Intent Tree の題材のみ。コード差分・実行時メトリクスは読まない。
+
+3. **該当する定石があるとき（気づきの提示・ログには書かない）**
+   - 利用者に気づき口調で名指しする。例:「この題材は `<id>`（<name>）に当てはまるかもしれません — compass で叩き台として検討できます」。押し付けず、候補を絞る。
+   - 詳しい叩き台（Anti-direction 候補・Invariant 候補）の提示と採否は **compass（主接点）に委ねる**。discover では「この定石が効きそう」と早期に気づかせるまで。
+   - **どのログにも append しない**。
+
+4. **該当する定石がないとき**
+   - 何も名指さない。**ログにも書かない**（この照合はログを持たない）。