intent-planner 0.13.1

package/templates/ja/claude/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/claude/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/claude/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/claude/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/claude/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/claude/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. **該当する定石がないとき**
+   - 何も名指さない。**ログにも書かない**（この照合はログを持たない）。

package/templates/ja/claude/skills/intent-discover/rules/mode-selection.md

@@ -0,0 +1,31 @@
+# Mode Selection
+
+リポジトリの状況から Intent の詰め方モードを推奨するロジック。`/intent-discover` の冒頭で使う。これは拡張点でもある（新モードを足したら、ここに推奨条件を追記する）。
+
+## 手順
+
+1. **利用可能なモードを列挙する**
+   - `.intent/modes/*.md` を Glob で探す。各モードの「適合する状況」節を読む。
+
+2. **リポジトリ状況を軽く観察する**
+   - 既存コードの有無・規模、テストの有無、README/docs の充実度、`.intent/` の既存成果物の有無。
+   - 深く読み込まない。推奨に必要な手がかりだけ。
+
+3. **モードを推奨する**
+   - 現在の同梱モードは `standard` / `refactor` / `behavior-unknown` / `feature-growth` の4つ。リポジトリ状況から次の条件で推奨する:
+     - 新規・意図が未言語化 → `standard`（既定）
+     - 既存大規模・リファクタ対象（既存コード規模が大きい・設計ドリフトがある）→ `refactor`（意図を書かずに作られたコード＝vibe coding も refactor へ。discover で Intent Recovery を併用する）
+     - 振る舞いが不明なレガシー（テストなし／少ない・仕様が失われている）→ `behavior-unknown`
+     - 既存システムへの**機能追加**（extend / integrate / add-to 系の要望・振る舞いが既知・再設計が目的でない）→ `feature-growth`（使い分け: 既存の構造を変えたいなら `refactor`、既存へ付加したいなら `feature-growth`）
+   - どの条件にも明確に当てはまらない場合は `standard` を推奨する。
+
+4. **利用者に確認する**
+   - 推奨モードと理由を提示し、`AskUserQuestion` で確認・変更を求める。
+   - **モード候補が1つでも複数でも、推奨 → 確認 → 記録の配線は必ず通す**。これにより、モードが増減しても利用者の体験が変わらない。
+
+5. **確定結果を記録する**
+   - 確定したモードを `.intent/mode.local.md`（mode 状態のローカル正本・git 非追跡）に書く（mode / selected / reason / definition）。旧環境で `mode.local.md` が存在しない場合の読み取りは、後方互換フォールバック（`mode.local.md` → `mode.md` → standard）で吸収される。Enforcement / Drift-watch の読み取りは引き続き `mode.md` を参照する。
+
+## 新モードを推奨対象に加える
+
+新しい `.intent/modes/<name>.md` を作ったら、上記 3 の推奨指針に「どんなリポジトリ状況で <name> を推奨するか」を追記する。

package/templates/ja/claude/skills/intent-export-cc-sdd/SKILL.md

@@ -0,0 +1,88 @@
+---
+name: intent-export-cc-sdd
+description: 選んだ packet 1つを、トークンを浪費せず cc-sdd へ渡せる凝縮した下書きに変換する。cc-sdd の本体生成は侵さない。続行指示時に /kiro-spec-init を起動できる。
+disable-model-invocation: true
+allowed-tools: Read, Write, Glob, Grep, AskUserQuestion, Skill, Bash
+argument-hint: <対象 packet 名（任意）>
+---
+
+# intent-export-cc-sdd Skill
+
+## Core Mission
+- **Success Criteria**:
+  - 対象 packet 1つを cc-sdd の凝縮 Project Description + design/tasks ヒントに変換している
+  - 入力を対象 packet ファイル + compass のプロジェクト普遍 Invariants/Anti-direction に限定し、Tree/Compass 全文を cc-sdd へ転記していない
+  - tasks ヒントが parent intent / invariant 参照を持ち、impl への伝播構造になっている
+  - 出力主役が自然言語案内で、続行指示時に /kiro-spec-init を起動できる
+  - アプリケーションコードを一切変更していない
+
+## Execution Steps
+
+### Step 1: 対象 packet を1つに絞る
+- `.intent/packets/index.md` を読み、active packet の候補を提示する。index.md が不在の場合は `.intent/packets/active/` 配下の frontmatter から直接候補一覧を構成して継続し、index の再生成を促す。`.intent/packets/` 自体が不在（または `active/` が空）なら「先に `/intent-packets` を実行」を案内して停止する。
+- 引数で packet が指定されていればそれを、なければ候補から優先順位や利用者確認で1つに絞り、確定した対象 packet のファイル（`.intent/packets/active/` 配下）のみを読む（全 packet ファイルの丸読みをしない）。
+- **draft ガード**: 確定した対象 packet の `state` が draft の場合、AskUserQuestion で「active 化して export を続行するか」を確認し、利用者が承認したら frontmatter の `state` を active へ更新して `index.md` を再生成してから続行する（確認なしに draft のまま export しない。export が canonical を書き換えるのはこの active 化に限る）。
+- `.intent/mode.local.md`（無ければ旧 `.intent/mode.md`）の mode 状態を読む。無ければ standard 既定で続行し告知する。
+
+### Step 1.5: enforcement ゲート（writeback 鮮度検査）
+- Step 1 で読んだ `.intent/mode.md` の `## Enforcement（ユーザー管理）` セクションから `enforcement` の値を確認する。off・未記載・不正値（mode.md 不在を含む）なら本検査を行わず、現行どおり Step 2 へ続行する。
+- remind または gate のとき、Bash で `node .intent/scripts/intent-check.mjs` を実行し（読み取り専用スクリプト。ファイルの作成・変更・削除を行わない）、stdout に従う。
+- **判定行の解釈規則**: 停止判断は stdout 1行目の判定行の `block=` のみを正とする（再導出・独自解釈をしない）。警告の要否は `result=stale` または `pending>0` で決める。`result=not-applicable` のときも判定行の `pending=` の値をそのまま使う。
+- gate かつ `block=yes` のとき: 根拠（pending の packet 名・経過コミット数/閾値。intent-check の2行目以降の人間可読行をそのまま引用する）を提示して export を停止し、`/intent-writeback` の実行を案内する。続けて AskUserQuestion で「それでも export を続行するか」を確認し、利用者が明示的に続行を指示したときのみ、警告を提示したうえで export を実行する（誤検知時の逃げ道）。
+- remind かつ違反検出（`result=stale` または `pending>0`）のとき: 同じ根拠を警告として提示し、停止せず続行する。
+- intent-check 自体が実行不可（Bash 不可・スクリプト不在・exit 2）のときのみ: staleness を not-applicable として扱い、`.intent/deltas.md` の pending な Delta エントリ（`- Status: pending` を持つもの）を Read/Grep で確認し、その結果を `pending` として上と同じ分岐に入る。
+
+### Step 1.6: drift 照合（drift-watch）
+- Step 1 で読んだ `.intent/mode.md` の `## Drift-watch（ユーザー管理）` セクションから `drift-watch` の値を確認する。`on` でないとき（off・未記載・不正値・セクション不在・mode.md 不在を含む）は本照合を行わず、現行どおり Step 1.7 へ続行する（現行動作とバイト等価）。
+- `on` のときのみ、`rules/drift-export-check.md` を読み、適用する。対象 packet の design/tasks ヒント × compass（North Star / Anti-direction / Invariants）の照合・抵触の名指し提示・drift-log への `stage: export` エントリの append・outcome の利用者判定での確定は、すべて rule の手順に委ねる（ここに手順を複製しない）。
+- この照合は **warn のみ・export を停止しない**（停止できるのは Step 1.5 の enforcement ゲートだけ。drift-watch は誤検知前提のため止めない）。
+- 3関所の順序と直交: **enforcement（手続き・停止しうる, Step 1.5） → drift-watch（方向・停止しない, Step 1.6） → Open Questions（期限・停止しない, Step 1.7）**。検査対象が直交する（手続き / 方向 / 期限）。
+
+### Step 1.7: 未回答 Open Questions の確認
+- `rules/export-questions.md` を読み、適用する。
+
+### Step 1.8: cc-sdd 前提の preflight 照合（warn のみ・停止しない）
+- `.kiro/` ディレクトリの有無を read-only で観測する（Read/Glob。`intent-check.mjs` 等の機械検査に寄せない）。
+- `.kiro/` が**不在**のとき: cc-sdd（kiro）が導入されていない可能性を **warn** する。「cc-sdd 前提（`.kiro/`）が見当たらない。cc-sdd を導入するか、読める成果物が目的なら format 軸の射影（読める Spec への出口）も選べる」と案内する（出口の選び方は `rules/export-route.md` の出口判定レーンに従う。本 SKILL から他 export/射影スキルのコマンド名は名指ししない）。**下書き生成は止めない**（Step 2 以降へ続行する）。
+- `.kiro/` が**存在**するとき: 何も出さず Step 2 へ続行する（従来どおり・warn 無し）。
+- この照合は **warn のみ・export を停止しない**（停止できるのは Step 1.5 の enforcement ゲートだけ。preflight は drift-watch と同じ誤検知前提で止めない＝`.kiro/` を後から入れる経路を潰さない）。出口の妥当性は `rules/export-route.md`（出口判定レーン）の規約に沿う。
+
+### Step 2: マッピング規則を適用する
+- `rules/map-cc-sdd.md` を読み、適用する。
+- 入力は対象 packet ファイル1つ（Safety / Invariants の packet 固有 invariant を含む）+ `.intent/intent-compass.md` のプロジェクト普遍 Invariants/Anti-direction のみ（Tree 全文・他 packet は読まない。方向が要る場合のみ Tree L0–L1 を要約参照）。
+
+### Step 3: 下書きを生成する
+- 下書きは packet ごとのディレクトリ `.intent/cc-sdd/<スラッグ>/` 配下に書く。スラッグの導出と衝突時の扱いは `rules/map-cc-sdd.md` の「出力レイアウト」節に従う。
+- `.intent/cc-sdd/<スラッグ>/requirements.md` に凝縮 Project Description（cc-sdd 投入本文）を書く。
+- `.intent/cc-sdd/<スラッグ>/design.md` に design ヒント（箇条書き）、`.intent/cc-sdd/<スラッグ>/tasks.md` に「Intent 由来の制約」セクション + tasks チェック項目を書く。
+- cc-sdd の本体は完成させない。tasks ヒントには parent intent と invariant 参照を必ず残す。
+- 下書きの生成を終えたら、export 記録を **packet 単位の分割ファイル** `.intent/export-log/<packet-slug>.md` へ書く（CONTRACT「append-only 記録の分割・archive 規約」に従う）。`<packet-slug>` は packet 名から既存スラッグ規則（`intent-packets/rules/packet-format.md`）で導出する（新採番・連番を作らない）。ファイルには scaffold と同じテーブルヘッダ（`| packet | exported_at | commit |`）+ `| <packet 名> | <export 日時（ISO 8601 UTC）> | <コミットハッシュ> |` の1行を書く（既存ファイルがあれば行を追記し、過去の行は消さない）。コミットハッシュは Bash で `git rev-parse --short HEAD`（読み取り専用）で取得し、取れない場合は `-`。`.intent/export-log/` ディレクトリが無ければ作る。
+- 続けて旧 `.intent/export-log.md` を**生成 active ミラー**として再生成する: `.intent/export-log/*.md` の全データ行を `exported_at` 昇順に連結し、scaffold と同じヘッダ + 全行で上書きする（分割ファイルが正本・ミラーは派生で手編集しない）。これにより単一ファイルを読む既存経路（status / validate / writeback / intent-check）が壊れない。読み手横断追随が完結する後続スライス（wire）でミラーは fold される。
+
+### Step 4: 受け渡しを案内する（自然言語主導）
+- 出力の主役は自然言語案内: 対象 packet の `.intent/cc-sdd/<スラッグ>/requirements.md` のパスを示し、「このまま cc-sdd に渡してよいか」を確認する。
+- 利用者が続行を指示したら、対象 packet の `.intent/cc-sdd/<スラッグ>/requirements.md` の本文を読み、その本文を引数として `/kiro-spec-init` を起動する（`Skill` を使う。利用者にコピペを強制しない）。
+- フォールバックとして、`/kiro-spec-init` 用の改行最小化コピーブロックも併記する（主ではない）。
+- **代行は `/kiro-spec-init` の起動まで**。その後の requirements → design → tasks は cc-sdd の3フェーズ承認に従い、各フェーズで利用者の続行指示を待つ。自動で突き進まない。
+- **戻り先の明示（writeback フェーズの入口）**: 案内の末尾に、cc-sdd 実装が一巡したら（実装の現実から学びが出たら）`/intent-writeback` で canonical へ戻すことを一行添える。実装後の学びを packet ファイルへ Evidence 直書きして済ませず、必ず writeback（delta 経由）を通す。これは「実装前の起草（compass/packets が canonical を直接書く）」と「実装後の逆抽出（writeback で delta 経由）」のフェーズ境界を利用者に明示するための案内。
+
+## Output Description
+- 対象 packet の `.intent/cc-sdd/<スラッグ>/{requirements, design, tasks}.md` の更新案
+- `.intent/export-log.md` への export 記録1行（追記）
+- draft を active 化した場合の対象 packet ファイルの `state` 更新と `.intent/packets/index.md` の再生成（該当なしの場合は省略）
+- 未回答 `[export まで]` Question の確認結果（提示した問いと利用者判断。該当なしの場合は省略）
+- cc-sdd へ渡してよいかの確認（自然言語案内・主）
+- `/kiro-spec-init` 用コピーブロック（フォールバック・従）
+- 実装前に確認すべき点
+- 実装が一巡したあとの戻り先案内（`/intent-writeback` で canonical へ。packet への Evidence 直書きで済ませない）
+
+## Safety & Fallback
+- `.intent/packets/` が不在（または `active/` が空）なら停止して `/intent-packets` を案内する。
+- index.md 不在は停止せず、`active/` 配下から直接候補を構成して継続し、index の再生成を促す。
+- canonical への書き込みは draft ガードの active 化（`state` 更新 + `index.md` 再生成）のみで、利用者の承認を得たときに限る。intent-tree / intent-compass / packet 本文は書き換えない。
+- mode.md 不在は停止せず standard 既定で続行し告知する。
+- enforcement の検査は fail-open: intent-check が実行不可でも export を止めない。停止するのは enforcement が gate で判定行が `block=yes` のとき、または実行不可フォールバックで gate かつ pending を検出したときのみで、いずれの場合も利用者の明示続行で実行できる。
+- Open Questions の確認は停止ではなく確認であり、明示続行で export できる。
+- cc-sdd の requirements/design/tasks の本体を完成させない（下書き・ヒントまで）。
+- `/kiro-spec-init` 以降の cc-sdd フェーズを自動起動しない。
+- アプリケーションコードは変更しない（INV6。他 skill の起動は INV6 と別概念であり許される）。

package/templates/ja/claude/skills/intent-export-cc-sdd/rules/drift-export-check.md

@@ -0,0 +1,75 @@
+# Drift Export Check（export 水際照合）
+
+`/intent-export-cc-sdd` の Step 1.6 で使う、対象 packet の design/tasks ヒント × compass の照合ロジック。`drift-watch: on` のときだけ走る（off / 未記載 / 不正値は何もしない）。enforcement ゲート（Step 1.5・停止しうる）の後・Open Questions 確認（Step 1.7・停止しない）の前に挟み、cc-sdd へ渡す直前――逆戻りが効かなくなる直前――で compass の方向から外れていないかを警告する。
+
+## 照合の根拠は compass
+
+- **照合の根拠は `.intent/intent-compass.md` の North Star / Anti-direction / Invariants** にする。export の段階では compass が既に存在するため、ここでは型カタログ（`.intent/drift-patterns.md`）ではなく compass を根拠にする（discover の地形診断は compass も packet もまだ無いため型カタログを根拠にする。export はその姉妹工程で、根拠が compass である点が違い）。
+- 水際照合は**誤検知前提**。compass の要素に「抵触した」ことは逸脱の確定ではない。妥当な設計を誤って拾うこと（false-positive）を最初から織り込み、空振りも含めて記録する。
+- **この照合は方向の関所であり、停止しない**。enforcement ゲート（手続きの関所・停止しうる）とは検査対象が直交する。drift の検知で export を止めることはしない（停止できるのは Step 1.5 の enforcement ゲートだけ）。
+
+## 手順
+
+1. **入力を取得する**
+   - 対象 packet の **design/tasks ヒント生成内容**（いま export が生成しようとしている下書きの中身）を入力にする。
+   - `.intent/intent-compass.md` の **North Star** / **Anti-direction** / **Invariants**（プロジェクト普遍 Invariant）を読む。
+   - **compass 不在 / 未記入のとき**: 水際照合をスキップし、その旨を利用者に告知する（停止しない / drift-log にも書かない）。以降の手順は実行しない。
+
+2. **design/tasks ヒントを compass と照合する**
+   - 生成しようとしている design/tasks ヒントを、compass の **Invariants**（壊してはいけない制約に抵触しないか）・**Anti-direction**（避けると決めた方向へ寄っていないか）・**North Star**（最終状態から逸れていないか）に照らす。
+   - これは**意味的な照合**であって機械判定ではない。誤検知前提で、疑わしければ拾う。
+
+3. **抵触があるとき**
+   - 利用者に**警告のみ提示する**――**export を停止しない**。何に抵触したか（どの Invariant / Anti-direction / North Star か）と、design/tasks ヒントのどの部分が外れているかを名指しする。
+   - `drift-log.md` へ1エントリ append する（後述の append 手順）。値は:
+     - `pattern: <該当する drift-patterns の id | uncatalogued:<短い名> | ->`（特定できれば id、カタログ外の実逸脱なら `uncatalogued:<短い名>`、判別できなければ `-`）
+     - `stage: export`
+     - `packet: <対象 packet 名>`
+     - `mechanism: compass-anti-direction`（Anti-direction に抵触したとき）または `compass-invariant`（Invariant に抵触したとき。どちらの compass 要素に抵触したかで選ぶ）
+     - `outcome: caught`（**下書き**。drift-watch の推定であり、確定は利用者の `user-verdict` と後述の判定で決まる）
+     - `user-verdict: unjudged`
+     - `recorded_at: <ISO 8601>`
+     - `commit: <短縮ハッシュ | ->`
+     - `note: <1〜2行>`（何に抵触し、何を警告したか）
+   - 複数箇所が抵触したら、抵触ごとに1エントリずつ append する。
+
+4. **outcome は利用者判定で確定する（下書きの解決）**
+   - `outcome` は手順3で `caught` を**下書き**しただけであり、最終値は利用者の判定で決まる:
+     - 利用者が警告を容れて design を引き戻したとき → `caught`（捕捉成功・効いた系）
+     - 利用者が無視してそのまま通したとき → `missed`（防げず通った・効かなかった系）
+     - 設計が実際には妥当で誤検知だったとき → `false-positive`（誤検知だった・効かなかった系）
+   - `user-verdict` が確定値を裏づける: 妥当な指摘なら `valid` / 誤検知なら `false-alarm` / 未判定なら `unjudged`。利用者が未判定でも `unjudged` のまま記録・集計対象になる。
+
+## 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`）に従う。
+
+## スコープ超過照合（DR9 第二防御・packet-scope-overflow）
+
+compass 照合（上記）とは**照合根拠が別物**の第二の照合。compass 照合が「compass 普遍 Invariant に抵触したか」を見るのに対し、これは「**対象 packet の宣言スコープ（`## Scope` / `## Non-scope`）を超える実装指示が来ていないか**」を見る。超えたとき、新領域でこそ必要になる **packet 固有 invariant**（認可・データ整合性・トランザクション境界・冪等性）が cc-sdd 成果物に不在であることを drift として警告する。`drift-watch: on` のときだけ走り、**警告のみ・停止しない・誤検知前提**は compass 照合と同じ。これは第一防御（規約文書の「スコープ超過なら intent に戻る」規律＝想起のみ）の効きを測る計器でもある。
+
+照合は2点で行う（利用者確定 2026-06-20「両方」）:
+
+1. **export 水際（この Step 1.6）**: いま export しようとしている下書きが、対象 packet の `## Scope` を超え `## Non-scope` 側へ及んでいないかを見る。下書き自体がスコープを逸脱していれば、export 時点で拾える。
+2. **後段の軽い提示（実装段の再照合）**: export 後にユーザーが出した**実装指示の文面**が対象 packet の `## Scope` を超える（例: フロント専用 packet なのにバックエンド/認可/トランザクション境界の実装を指示）とき、軽く再照合して名指しする。これは「intent に戻る」（`/intent-packets` で新領域の packet を起こし再 export）への差し戻しを促す入口で、停止はしない。
+
+### 照合の入力と規律
+
+- **入力は実装指示の文面と packet の `## Scope` / `## Non-scope` 宣言のみ**。コード差分・実装結果は読まない（INV5/INV6・DR14）。意味的照合であって機械判定ではない。
+- 照合根拠は **packet 固有 invariant の不在**。compass 普遍 Invariant 照合（上記）とロジックを混同しない。普遍 Invariant が export で転記されていることは、新領域の固有制約をカバーしない（別レイヤー）。
+- **異常系**: 対象 packet が無い / `## Scope` 未記入のときは照合をスキップし告知する（停止しない・drift-log に書かない）。
+
+### スコープ超過があるとき
+
+- 利用者に**警告のみ提示する**――export も実装も停止しない。何が packet スコープ（例: フロント）を超え、どの新領域（例: バック/認可/トランザクション）に及び、どの packet 固有 invariant（認可・整合性・トランザクション境界・冪等性）が不在かを名指しし、「`/intent-packets` で新領域の packet を起こして再 export する（intent に戻る）」を案内する。
+- `drift-log.md` へ1エントリ append する（上記 append 手順と同一）。値の差分は:
+  - `mechanism: packet-scope-overflow`（compass 系の2値とは別の第二防御由来。集計上分離できる）
+  - `pattern: uncatalogued:scope-overflow`（型カタログに scope-creep 型 seed があればその id。無ければ `uncatalogued:scope-overflow`）
+  - `stage: export`（水際で拾った場合）。後段の実装段で拾った場合も、export 由来の照合の延長として `stage: export` を用い、`note` に「実装段の再照合」と明記する（新 stage 値は増やさない＝既存3値 `discover | export | improve` のスキーマを変えない）。
+  - 他キー（`packet` / `outcome: caught` 下書き / `user-verdict: unjudged` / `recorded_at` / `commit` / `note`）は compass 照合と同じ規律。
+- `outcome` の確定は compass 照合と同じ（利用者が intent に戻れば `caught` / 無視して押し切れば `missed` / 実際は妥当な拡張で誤検知なら `false-positive`）。

package/templates/ja/claude/skills/intent-export-cc-sdd/rules/export-questions.md

@@ -0,0 +1,23 @@
+# Export Questions Check
+
+export 実行前に、未回答の `[export まで]` 付き Open Questions を確認する手順。`/intent-export-cc-sdd` の Step 1.7 で使う。対話はすべて利用者への確認として行う（確認の手段は SKILL.md の規約に従う）。
+
+## 検出
+
+- `.intent/intent-tree.md` と `.intent/intent-compass.md` の Open Questions 節を読み、`[export まで]` を含む問いを検出する。節に残っている問い = 未回答として扱う。
+- 検出対象はこの2ファイルのみ。問いの正本は両ファイルの Open Questions 節であり、`.intent/packets/plan.md` の Deferred は意図的見送りの記録であって問いではないため対象外。
+- **enforcement 設定（`.intent/mode.md` の Enforcement セクション）は参照しない**（Step 1.5 の enforcement ゲートとは独立に動作する）。
+
+## 手順
+
+1. **検出ゼロの場合（タグ規約を持たない旧 scaffold を含む）**
+   - 何も提示せず、次のステップへ進む（挙動変化なし）。
+
+2. **検出ありの場合**
+   - 検出した問いの一覧を提示する。
+   - 「回答してから export するか、このまま続行するか」を利用者に確認する。
+   - これは停止ではなく確認である。利用者が明示的に続行を指示したら export を実行する。
+
+## 規律
+
+- コードを変更しない。