intent-planner 0.13.1

package/templates/en/intent/scripts/pre-push

@@ -0,0 +1,27 @@
+#!/bin/sh
+# intent-planner pre-push hook
+#
+# Delegates the off/remind/gate decision entirely to intent-check.mjs
+# (single source of judgment). Only exit code 1 (gate violation) blocks
+# the push; exit 0 (ok/remind) and exit 2 (internal error) fail open.
+# `git push --no-verify` bypasses this hook by design (git standard).
+#
+# git runs pre-push from the repository top level. Ref info on stdin is
+# intentionally not consumed.
+
+if ! command -v node >/dev/null 2>&1; then
+  echo "intent-check: node not found; enforcement check skipped" >&2
+  exit 0
+fi
+
+if [ ! -f .intent/scripts/intent-check.mjs ]; then
+  echo "intent-check: .intent/scripts/intent-check.mjs not found; enforcement check skipped" >&2
+  exit 0
+fi
+
+node .intent/scripts/intent-check.mjs
+rc=$?
+if [ "$rc" -eq 1 ]; then
+  exit 1
+fi
+exit 0

package/templates/en/intent/spec-ingest/README.md

@@ -0,0 +1,18 @@
+# Spec Ingest Derived Views
+
+> `/intent-from-spec` reads an input natural-language specification and writes the extracted intent candidates and gaps under this directory as derived, easy-to-transcribe views. Everything except this README is **NOT tracked by Git (local-only)**. The views placed here are **derived, NOT the source of truth**. The authority remains the canonical files such as `.intent/intent-tree.md` and `.intent/intent-compass.md`; these views are merely a snapshot (candidates / hypotheses) reflecting the input spec at read time.
+
+## Structure
+
+```
+.intent/spec-ingest/
+├── README.md         # this description (tracked by Git)
+└── spec-ingest.md    # the ingest view produced by /intent-from-spec (untracked, regenerated by full replacement)
+```
+
+## Nature of this directory
+
+- **Derived / regenerable**: `spec-ingest.md` is regenerated by **full replacement** from the input specification every time `/intent-from-spec` runs. Hand edits are overwritten on the next run (do not edit).
+- **Not the source of truth**: The authority for design intent stays in the canonical `.intent/intent-tree.md` / `.intent/intent-compass.md`. This view holds **candidates / hypotheses (Assumptions)** extracted from the spec; editing it here does not propagate to the canonical files. To adopt an item, review it and **manually transcribe** it into the discover / compass dialogue (there is no automated handoff).
+- **Not tracked by Git**: `spec-ingest.md` and everything else except this README are local-only and not tracked (only this README is tracked). By design this avoids merge conflicts and loss from overwrites in team settings.
+- **Read-only extraction layer + scoped Write**: `/intent-from-spec` does not modify the input specification (read-only) and does not modify the canonical artifacts. Its writes are confined to this `.intent/spec-ingest/` directory.

package/templates/ja/agents/claude/CLAUDE.md

@@ -0,0 +1,62 @@
+# intent-planner（Claude 向け quickstart）
+
+intent-planner は、実装に入る**前**に「全体の意図」と「統一した設計方針」を人間とエージェントで擦り合わせる、軽量な **Intent Planning レイヤー**です。各ファイル単位では妥当でも全体の設計意図が少しずつ崩れていく architectural drift を、エージェントが横断的な intent を持たないまま局所最適（local optimization）へ逃げることを止めて防ぎます。
+
+これは full IDD framework ではなく、spec 駆動フロー（cc-sdd）の**手前**に挟む pre-spec ステージです。ここで詰めた intent を、cc-sdd の requirements → design → tasks フローへ非破壊・低トークンで橋渡しします。
+
+## ワークフロー
+
+`/intent-discover` から始め、以下を順に実行します。各ステップの成果物（`.intent/` 配下の Markdown）をレビューしてから次へ進みます。
+
+1. `/intent-discover` — Intent Tree（L0–L4）を構築し、Intent の詰め方モードを推奨・確定し、設計者役の詰めの問い（designer-questions）の要否を確認・記録する
+2. `/intent-compass` — North Star / Anti-direction / Invariants など判断基準を作る
+3. `/intent-packets` — cc-sdd に渡す前の作業単位（packet）に分解する
+4. `/intent-export-cc-sdd` — 選んだ packet を cc-sdd の下書きに変換する
+
+上の4つは「計画」フェーズです。export 後も intent は使い捨てず、維持・随時の4スキルでサイクルとして育て続けます。
+
+- `/intent-status` — 随時（迷ったとき）。現在地の要約と「次の一手」をちょうど1つ推奨する（読み取り専用）
+- `/intent-validate` — export 前（推奨）。成果物間の矛盾・カバレッジ漏れ・境界不整合を深刻度付きで報告する（読み取り専用）
+- `/intent-writeback` — packet の実装完了後。学びを `.intent/deltas.md` に delta として記録し、承認された項目だけを canonical 成果物へ昇格する
+- `/intent-improve` — 節目。`.intent/` と実装の現実を completeness / correctness / coherence の3軸で再整合する
+
+これらの `intent-*` skill は `.claude/skills/intent-*/SKILL.md` に配置されています。
+
+## 能動的な行動促し（命令形・短文）
+
+- 実装に入る前に、まず `/intent-discover` を実行する。
+- 現在地に迷ったら `/intent-status` を実行する。
+- 実装中は、該当 **packet** と関係する **Invariant** / Decision Rule だけを読む（Compass 全文・Tree 全文は読まない）。
+
+## pull 規律（全ロードしない）
+
+実装前に読むのは「該当 **packet** ＋ 関係する **Invariant** / Decision Rule だけ」。Compass 全文・Tree 全文を常時ロードしない。Spec/Invariant 本体はここに転記せず、参照先を案内する（`.intent/intent-compass.md`・`.intent/intent-tree.md`・`.intent/packets/` 配下の該当 packet）。
+
+## steering 生成は非推奨
+
+責務追加ごとに横断的な `steering`（特に steering custom）を生成しない。必要な制約は intent が `export` を通じて spec 単位に供給する（just-in-time, JIT）ため、新たな steering を立てるより該当する制約を pull することを優先する。
+
+## .intent/ scaffold
+
+Intent の知能と planning 成果物は `.intent/` にあり、エージェント非依存です。
+
+- `intent-tree.md` — Intent Tree（L0–L4）
+- `intent-compass.md` — North Star / Anti-direction / Invariants
+- `packets/` — Packet Plan と packet ファイル（1 packet = 1 ファイル）
+- `mode.md` / `modes/` — Intent の詰め方モードと記録
+- `cc-sdd/` — cc-sdd へ渡す requirements / design / tasks の下書き
+
+詳細は `.intent/README.md` を参照してください。
+
+## cc-sdd 連携
+
+`/intent-export-cc-sdd` が生成する対象 packet の `.intent/cc-sdd/<スラッグ>/requirements.md` を cc-sdd の `/kiro-spec-init` に渡すことで、Intent Planning の成果を cc-sdd の spec 駆動フローへ引き継げます。intent-planner は下書きまでで、本体は cc-sdd が生成し各フェーズで人間がレビューします。
+
+## ルール
+
+- Intent Planning フェーズではアプリケーションコードを変更しない。
+- parent intent を支えない局所リファクタを提案しない。
+- 各 packet は parent intent を必ず参照し、各タスクは invariant を保持する。
+- 意図が不明なときはコードを編集せず Open Questions に書く。
+- 推測された意図は、人間がレビューするまで暫定として扱う。
+- export 済み packet の Scope を超える実装指示が来たら、そのまま実装し続けず `/intent-packets` で新領域の packet を起こす（または既存 packet をスコープ拡大して supersede）→ 再 export で intent に戻る。新領域の決定（認可・整合性・冪等性・エラー意味論）と packet 固有の不変則の抜けを防ぐため。

package/templates/ja/agents/codex/AGENTS.md

@@ -0,0 +1,62 @@
+# intent-planner（Codex 向け quickstart）
+
+intent-planner は、実装に入る**前**に「全体の意図」と「統一した設計方針」を人間とエージェントで擦り合わせる、軽量な **Intent Planning レイヤー**です。各ファイル単位では妥当でも全体の設計意図が少しずつ崩れていく architectural drift を、エージェントが横断的な intent を持たないまま局所最適（local optimization）へ逃げることを止めて防ぎます。
+
+これは full IDD framework ではなく、spec 駆動フロー（cc-sdd）の**手前**に挟む pre-spec ステージです。ここで詰めた intent を、cc-sdd の requirements → design → tasks フローへ非破壊・低トークンで橋渡しします。
+
+## ワークフロー
+
+`/intent-discover` から始め、以下を順に実行します。各ステップの成果物（`.intent/` 配下の Markdown）をレビューしてから次へ進みます。
+
+1. `/intent-discover` — Intent Tree（L0–L4）を構築し、Intent の詰め方モードを推奨・確定し、設計者役の詰めの問い（designer-questions）の要否を確認・記録する
+2. `/intent-compass` — North Star / Anti-direction / Invariants など判断基準を作る
+3. `/intent-packets` — cc-sdd に渡す前の作業単位（packet）に分解する
+4. `/intent-export-cc-sdd` — 選んだ packet を cc-sdd の下書きに変換する
+
+上の4つは「計画」フェーズです。export 後も intent は使い捨てず、維持・随時の4スキルでサイクルとして育て続けます。
+
+- `/intent-status` — 随時（迷ったとき）。現在地の要約と「次の一手」をちょうど1つ推奨する（読み取り専用）
+- `/intent-validate` — export 前（推奨）。成果物間の矛盾・カバレッジ漏れ・境界不整合を深刻度付きで報告する（読み取り専用）
+- `/intent-writeback` — packet の実装完了後。実装で得た学びを `.intent/deltas.md` に delta として記録し、承認された項目だけを canonical 成果物へ昇格する
+- `/intent-improve` — 節目（複数 packet 実装後など）。`.intent/` と実装の現実を completeness / correctness / coherence の3軸で再整合する
+
+これらの `intent-*` skill は `.agents/skills/intent-*/SKILL.md` に配置されています。
+
+## 能動的な行動促し（命令形・短文）
+
+- 実装に入る前に、まず `/intent-discover` を実行する。
+- 現在地に迷ったら `/intent-status` を実行する。
+- 実装中は、該当 **packet** と関係する **Invariant** / Decision Rule だけを読む（Compass 全文・Tree 全文は読まない）。
+
+## pull 規律（全ロードしない）
+
+実装前に読むのは「該当 **packet** ＋ 関係する **Invariant** / Decision Rule だけ」。Compass 全文・Tree 全文を常時ロードしない。Spec/Invariant 本体はここに転記せず、参照先を案内する（`.intent/intent-compass.md`・`.intent/intent-tree.md`・`.intent/packets/` 配下の該当 packet）。
+
+## steering 生成は非推奨
+
+責務追加ごとに横断的な `steering`（特に steering custom）を生成しない。必要な制約は intent が `export` を通じて spec 単位に供給する（just-in-time, JIT）ため、新たな steering を立てるより該当する制約を pull することを優先する。
+
+## .intent/ scaffold
+
+Intent の知能（mode 定義・アルゴリズム rules・cc-sdd 橋渡し）と planning 成果物は `.intent/` にあり、エージェント非依存です。
+
+- `intent-tree.md` — Intent Tree（L0–L4）
+- `intent-compass.md` — North Star / Anti-direction / Invariants
+- `packets/` — Packet Plan（`plan.md`）と packet ファイル（`active/` 配下に 1 packet = 1 ファイル。`index.md` が active packet の一覧で、完了した packet は `archive/` へ移動）
+- `mode.md` / `modes/` — Intent の詰め方モード（選択中のモードと designer-questions / purpose の記録、モード定義）
+- `cc-sdd/` — cc-sdd へ渡す requirements / design / tasks の下書き（packet 毎に `<スラッグ>/` ディレクトリで保持）
+
+詳細は `.intent/README.md` を参照してください。
+
+## cc-sdd 連携
+
+`/intent-export-cc-sdd` が生成する対象 packet の `.intent/cc-sdd/<スラッグ>/requirements.md`（凝縮 Project Description）を cc-sdd の `/kiro-spec-init` に渡すことで、Intent Planning の成果を cc-sdd の spec 駆動フローへ滑らかに引き継げます。intent-planner は下書きまでで、本体は cc-sdd が生成し各フェーズで人間がレビューします。
+
+## ルール
+
+- Intent Planning フェーズではアプリケーションコードを変更しない。
+- parent intent を支えない局所リファクタを提案しない。
+- 各 packet は parent intent を必ず参照し、各タスクは invariant を保持する。
+- 意図が不明なときはコードを編集せず Open Questions に書く。
+- 推測された意図は、人間がレビューするまで暫定として扱う。
+- export 済み packet の Scope を超える実装指示が来たら、そのまま実装し続けず `/intent-packets` で新領域の packet を起こす（または既存 packet をスコープ拡大して supersede）→ 再 export で intent に戻る。新領域の決定（認可・整合性・冪等性・エラー意味論）と packet 固有の不変則の抜けを防ぐため。

package/templates/ja/agents/gemini/GEMINI.md

@@ -0,0 +1,62 @@
+# intent-planner（Gemini CLI 向け quickstart）
+
+intent-planner は、実装に入る**前**に「全体の意図」と「統一した設計方針」を人間とエージェントで擦り合わせる、軽量な **Intent Planning レイヤー**です。各ファイル単位では妥当でも全体の設計意図が少しずつ崩れていく architectural drift を、エージェントが横断的な intent を持たないまま局所最適（local optimization）へ逃げることを止めて防ぎます。
+
+これは full IDD framework ではなく、spec 駆動フロー（cc-sdd）の**手前**に挟む pre-spec ステージです。ここで詰めた intent を、cc-sdd の requirements → design → tasks フローへ非破壊・低トークンで橋渡しします。
+
+## ワークフロー
+
+`/intent-discover` から始め、以下を順に実行します。各ステップの成果物（`.intent/` 配下の Markdown）をレビューしてから次へ進みます。
+
+1. `/intent-discover` — Intent Tree（L0–L4）を構築し、Intent の詰め方モードを推奨・確定し、設計者役の詰めの問い（designer-questions）の要否を確認・記録する
+2. `/intent-compass` — North Star / Anti-direction / Invariants など判断基準を作る
+3. `/intent-packets` — cc-sdd に渡す前の作業単位（packet）に分解する
+4. `/intent-export-cc-sdd` — 選んだ packet を cc-sdd の下書きに変換する
+
+上の4つは「計画」フェーズです。export 後も intent は使い捨てず、維持・随時の4スキルでサイクルとして育て続けます。
+
+- `/intent-status` — 随時（迷ったとき）。現在地の要約と「次の一手」をちょうど1つ推奨する（読み取り専用）
+- `/intent-validate` — export 前（推奨）。成果物間の矛盾・カバレッジ漏れ・境界不整合を深刻度付きで報告する（読み取り専用）
+- `/intent-writeback` — packet の実装完了後。実装で得た学びを `.intent/deltas.md` に delta として記録し、承認された項目だけを canonical 成果物へ昇格する
+- `/intent-improve` — 節目（複数 packet 実装後など）。`.intent/` と実装の現実を completeness / correctness / coherence の3軸で再整合する
+
+これらの `intent-*` skill は `.agents/skills/intent-*/SKILL.md` に配置されています（Gemini CLI は `.agents/skills/` を Agent Skills として読み込みます）。
+
+## 能動的な行動促し（命令形・短文）
+
+- 実装に入る前に、まず `/intent-discover` を実行する。
+- 現在地に迷ったら `/intent-status` を実行する。
+- 実装中は、該当 **packet** と関係する **Invariant** / Decision Rule だけを読む（Compass 全文・Tree 全文は読まない）。
+
+## pull 規律（全ロードしない）
+
+実装前に読むのは「該当 **packet** ＋ 関係する **Invariant** / Decision Rule だけ」。Compass 全文・Tree 全文を常時ロードしない。Spec/Invariant 本体はここに転記せず、参照先を案内する（`.intent/intent-compass.md`・`.intent/intent-tree.md`・`.intent/packets/` 配下の該当 packet）。
+
+## steering 生成は非推奨
+
+責務追加ごとに横断的な `steering`（特に steering custom）を生成しない。必要な制約は intent が `export` を通じて spec 単位に供給する（just-in-time, JIT）ため、新たな steering を立てるより該当する制約を pull することを優先する。
+
+## .intent/ scaffold
+
+Intent の知能（mode 定義・アルゴリズム rules・cc-sdd 橋渡し）と planning 成果物は `.intent/` にあり、エージェント非依存です。
+
+- `intent-tree.md` — Intent Tree（L0–L4）
+- `intent-compass.md` — North Star / Anti-direction / Invariants
+- `packets/` — Packet Plan（`plan.md`）と packet ファイル（`active/` 配下に 1 packet = 1 ファイル。`index.md` が active packet の一覧で、完了した packet は `archive/` へ移動）
+- `mode.md` / `modes/` — Intent の詰め方モード（選択中のモードと designer-questions / purpose の記録、モード定義）
+- `cc-sdd/` — cc-sdd へ渡す requirements / design / tasks の下書き（packet 毎に `<スラッグ>/` ディレクトリで保持）
+
+詳細は `.intent/README.md` を参照してください。
+
+## cc-sdd 連携
+
+`/intent-export-cc-sdd` が生成する対象 packet の `.intent/cc-sdd/<スラッグ>/requirements.md`（凝縮 Project Description）を cc-sdd の `/kiro-spec-init` に渡すことで、Intent Planning の成果を cc-sdd の spec 駆動フローへ滑らかに引き継げます。intent-planner は下書きまでで、本体は cc-sdd が生成し各フェーズで人間がレビューします。
+
+## ルール
+
+- Intent Planning フェーズではアプリケーションコードを変更しない。
+- parent intent を支えない局所リファクタを提案しない。
+- 各 packet は parent intent を必ず参照し、各タスクは invariant を保持する。
+- 意図が不明なときはコードを編集せず Open Questions に書く。
+- 推測された意図は、人間がレビューするまで暫定として扱う。
+- export 済み packet の Scope を超える実装指示が来たら、そのまま実装し続けず `/intent-packets` で新領域の packet を起こす（または既存 packet をスコープ拡大して supersede）→ 再 export で intent に戻る。新領域の決定（認可・整合性・冪等性・エラー意味論）と packet 固有の不変則の抜けを防ぐため。

package/templates/ja/claude/skills/CONTRACT.md

@@ -0,0 +1,90 @@
+# intent-* Skill 共通契約
+
+全ての `intent-*` skill が従う規約。対象は `intent-` で始まる skill 全体であり、個別列挙には依存しない（skill を追加しても本契約はそのまま適用される）。cc-sdd の `kiro-*` skill と同じ骨格に揃え、非破壊に共存する。
+
+## frontmatter（必須フィールド）
+
+```yaml
+---
+name: intent-<phase>            # 必ず intent- で始める。kiro-* と衝突させない（全スキル必須）
+description: <一行説明>          # いつ使うかが分かる説明（全スキル必須）
+allowed-tools: Read, Write, Glob, Grep, AskUserQuestion  # （全スキル必須）
+argument-hint: <引数の説明>      # （全スキル必須）
+# disable-model-invocation: true  # canonical-writer のみ必須（下記参照）。auto-invocable には置かない
+---
+```
+
+- 必須フィールドは `name` / `description` / `allowed-tools` / `argument-hint` の4つ（全スキル一律）。
+- **`disable-model-invocation: true` は canonical を書き換えるスキル（canonical-writer）のみ必須**。read-only または派生領域 `.intent/<領域>/` 限定の Write で canonical を書き換えないスキル（auto-invocable）には**置かない**＝モデルが文脈から自動起動できる。
+  - 自動起動可否の**判定軸は「canonical（intent-tree / intent-compass / `.intent/packets/` 配下の packet・plan.md 等の正本）を書き換えるか否か」**。書き換えないなら自動起動可（disable を置かない）、書き換えるなら `disable-model-invocation: true` でスラッシュ起動前提にする。
+  - この「auto-invocable」軸は、下記 frontmatter 例外節の **「read-only skill（`allowed-tools` を `Read, Glob, Grep` に絞る・`intent-status` / `intent-validate` のみ）」とは別軸**である（混同しない）。read-only skill 軸は allowed-tools の縮小に関する規律であり、auto-invocable 軸は Write を持つ `intent-overview` / `intent-from-spec` / `intent-to-spec` も含む（これらは派生領域限定 Write で canonical を書き換えないため auto-invocable）。詳細な相互参照は下記「read-only skill」記述を参照。
+  - **スキル分類（後続が参照する正本列挙）**:
+    - **auto-invocable（5）** = `disable-model-invocation` を**置かない**: `intent-status` / `intent-validate` / `intent-overview` / `intent-from-spec` / `intent-to-spec`。
+    - **canonical-writer（7）** = `disable-model-invocation: true` を**必須**: `intent-discover` / `intent-compass` / `intent-packets` / `intent-writeback` / `intent-improve` / `intent-export-cc-sdd` / `intent-export-openspec`。
+    - この列挙は test の `AUTO_INVOCABLE_SKILLS`（`test/structure-pack.test.mjs`）と一致を保つこと（二重管理の歯止め）。auto-invocable 集合を変更する場合は本列挙と当該テストを同時に更新する。
+- `name` は `intent-*`。ディレクトリ名も一致させる。`kiro-*` と決して衝突させない。
+- `allowed-tools` は**計画系に限定**: `Read, Write, Glob, Grep, AskUserQuestion`（必要に応じ `Agent`）。
+  - 例外: export スキル（現在は `intent-export-cc-sdd` が `/kiro-spec-init`、`intent-export-openspec` が `/opsx:propose` を起動するため）のみ `Skill` を追加してよい。起動は各スキルにつきこの1コマンドまで。
+  - 例外（Bash 限定）: staleness 検査を行うスキル（現在は `intent-export-cc-sdd` / `intent-export-openspec` のゲート判定と `intent-status` の鮮度警告）は、読み取り専用スクリプト `node .intent/scripts/intent-check.mjs` の起動、および export スキル（`intent-export-cc-sdd` / `intent-export-openspec`）が export 記録のコミットハッシュを取得するための `git rev-parse --short HEAD`（読み取り専用）の実行に限り `Bash` を追加してよい（いずれもファイルの作成・変更・削除を行わない）。これ以外の用途での Bash 利用は intent-* skill に許可しない。
+  - 例外: **read-only skill**（現在は `intent-status` / `intent-validate`）は `allowed-tools` を **`Read, Glob, Grep` に絞る**。`Write` と対話確認ツール（`AskUserQuestion`）を持たない。これは標準セットの意図的な縮小であり、許可される。例外として `intent-status` は上記の Bash 限定例外に基づき、読み取り専用スクリプト `node .intent/scripts/intent-check.mjs` の起動に限り `Bash` を併用できる（ファイルの作成・変更・削除を行わない性質は維持。`allowed-tools` は `Read, Glob, Grep, Bash` となる）。`intent-validate` は Bash を持たない。
+    - 注意（terminology の別軸）: この **「read-only skill」軸（allowed-tools 縮小・`intent-status` / `intent-validate` のみ）** と、上記 frontmatter 必須規約の **「auto-invocable」軸（canonical 非書き換え・`disable-model-invocation` を置かない 5 スキル）** は**別軸**である。auto-invocable には Write を持つ `intent-overview` / `intent-from-spec` / `intent-to-spec` も含まれるため、両者の集合は一致しない。混同しないこと。
+
+## 本文構成
+
+cc-sdd の流儀に揃える。
+
+```
+# <skill-name> Skill
+
+## Core Mission
+- Success Criteria: ...
+
+## Execution Steps
+### Step 1: ...   （必要に応じ rules/*.md を Read して適用）
+### Step 2: ...
+
+## Output Description
+- 生成した更新案
+- 人間が確認すべき Open Questions
+- 次に実行すべきコマンド
+
+## Safety & Fallback
+- エラー時/前提欠如時の挙動
+```
+
+## 共通の制約
+
+- **出力は「更新案の提示」を基本**とする。`.intent/` への Write は許可。
+- **canonical への書き込み権限はフェーズで分かれる**（隠れた前提にしない）。canonical 成果物（intent-tree.md / intent-compass.md / `.intent/packets/` 配下の packet ファイル・plan.md）について:
+  - **起草スキル（実装前）は canonical を直接書いてよい**: `/intent-discover`（intent-tree 起案）・`/intent-compass`（North Star / Anti-direction / Invariants / Decision Rules の起草）・`/intent-packets`（packet ファイル起案）は、利用者確認のうえで canonical を直接 Write するのが正規動作。
+  - **`/intent-writeback`（実装後）は canonical を直接書かない**: 実装の現実から逆抽出した学びは、必ず `deltas.md` 経由（delta 記録 → 承認 → 昇格）でのみ canonical へ反映する（writeback-protocol.md §3）。packet ファイルへの Evidence 直書きで済ませない。
+  - この区別は「実装前の起草」と「実装後の逆抽出」のフェーズ境界に対応する。同じ canonical でも、どのフェーズのどのスキルが書くかで経路が違う。
+- **アプリケーションコードを変更しない**（INV6）。
+  - INV6 の射程は「アプリコードを変更しない」であって「他 skill を起動しない」ではない。両者は別概念。`intent-export-cc-sdd` が `/kiro-spec-init` を起動するのは INV6 と矛盾しない（コードを触らない）。
+- **モードを尊重する（read fallback 規約）**: mode 状態を **`mode.local.md`（無ければ旧 `mode.md`）→ どちらにも無ければ `standard` 既定** の順で読む（後方互換フォールバック）。定義ファイルのモード定義に従って動く。`mode.local.md` も旧 `mode.md` も不在なら `standard` を既定として続行し、Open Questions に「モード未確定・`/intent-discover` 推奨」を併記する（停止しない）。Enforcement / Drift-watch（共有ポリシー）は `mode.md` から読む（このフォールバック規約の対象外）。
+- **前段の成果物が欠如しているとき**は、推測で穴埋めせず「先に該当コマンドを実行」を案内して停止する（mode 状態の不在とは区別する）。
+
+## 問いと用語の作法
+
+- **問いは自己完結文にする**: 利用者への問い・確認の文面は、術語を知らなくても回答できる自己完結文とする。術語を使う場合は、問い文面の中に一行説明を含める（例: 「最初の packet（作業単位）が、入力から出力まで一通り動く最小実装（walking skeleton）になっているかを確認します」）。
+- **術語は英語のまま + 一行説明**: 術語を日本語の訳語に置換しない。説明が要る場合は、機能・意味を述べる一行説明（括弧書きまたは blockquote）を初出箇所に添える。
+- **造語を勝手に作らない**: 正規語彙（ubiquitous language＝intent 成果物で既に使われている合意済みの用語の集合）に無い新造の語を勝手に作らず、既存の語を再利用する。どうしても新しい語を導入する場合は、初出箇所に一行説明を添える。
+
+## スキル間の状態共有
+
+- 状態の共有点は **`mode.local.md`（mode 状態: mode/designer-questions/purpose・ローカル専用・git 非追跡）** と **`mode.md`（共有ポリシー: Enforcement/Drift-watch・git 追跡）** の2ファイル（隠れ共有を作らない）。read fallback 規約は上記「モードを尊重する」に集約する。
+- `.intent/deltas.md` は `.intent/packets/` 配下の packet ファイルと同様の**成果物**（intent-writeback が書き、intent-status / intent-improve が読む）であり、mode 状態共有とは別物。隠れ共有の新設ではない。
+
+### append-only 記録の分割・archive 規約
+
+`.intent/` の append-only 単一 Markdown 記録（deltas / export-log / drift-log / milestones / compass-archive など、書き手が末尾追記し読み手が全体を読む同型の記録）は、並行追記で同一アンカー（ファイル末尾）への衝突を起こし肥大化する。これを構造的に解くため、append-only 記録は次の規約に従って物理形を持つ（規約の単一正本はここ）。
+
+1. **active 面（現在の射影）と履歴（archive）を分ける**。現在参照する記録は active 面に薄く保ち、終端した（もう更新されない）エントリは archive へ退避する。
+2. **分割キーは2分類**。記録は単一ファイルへの末尾追記をやめ、衝突しない自然キーで分割した小ファイルへ書く。分類は記録の由来で決める: **packet 由来＝packet 単位ファイル**（例: `deltas/<packet-slug>.md`）／**事象由来＝日付+slug 単位ファイル**（例: `drift-log/<date>-<slug>.md`）。別 packet / 別事象が別ファイルを触るため、末尾衝突が原理的に消える。
+3. **連番採番は用いず日付+slug を用いる**。ファイル名に `0001` のような中央カウンタの連番を使わない（並行セッションは互いの採番を見られず衝突を防げない）。代わりに日付+slug を用いる。
+4. **archive 退避は既存の `archive/<年>/` 構造を踏襲する**。終端エントリは記録ディレクトリ配下の `archive/<年>/`（年単位ディレクトリ。packet が既に持つ precedent）へ退避し、active を薄く保つ。新しい退避命名を発明しない。
+5. **順序が load-bearing な記録に merge=union を用いない**。`merge=union`（gitattributes での衝突マーカー消去）は順序を静かに壊すため、エントリの順序が意味を持つ記録には用いない。衝突は分割（規約2）で構造的に消す。
+
+- **分割キーの命名は既存の packet スラッグ規則を参照し、新しい採番規則を再定義しない**。slug の決定的導出（NFC 正規化→trim→小文字化→危険文字を `-` へ→連続 `-` 圧縮→前後 `-` 除去→非 ASCII 保持）と日付部（起案日）は `intent-packets/rules/packet-format.md` のスラッグ規則が単一正本であり、分割キーはそれを参照するだけでよい（新採番ロジック・中央カウンタを持ち込まない）。
+- 記録の中身（各記録のエントリ書式・固定キー順など）はこの規約の対象外であり、分割・archive は配置のみを定める（中身は behavior-preserving に保つ）。
+- **5記録ファイルの置き場（規約2の適用先）**: 上の分類を5ファイルすべてに適用する。**packet 由来**＝`deltas/<packet-slug>.md`・`export-log/<packet-slug>.md`（packet 単位）。**事象由来**＝`drift-log/<date>-<slug>.md`・`milestones/<date>-<event-slug>.md`（日付+slug 単位）。**compass-archive は退避された Decision Rule の rule 単位**＝`compass-archive/<rule-slug>.md`（同一 rule の再 supersede は同ファイル）。export-log は読み手横断追随が完結するまで旧 `export-log.md` を生成 active ミラー（分割ファイルを `exported_at` 昇順連結・派生で手編集しない）として併存させ、書き手が毎 export で再生成する。

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

@@ -0,0 +1,55 @@
+---
+name: intent-compass
+description: Intent Tree から、今回の変更における判断基準（North Star / Anti-direction / Invariants / Decision Rules）を構築する。Claude が局所最適に逃げるのを防ぐ。実装はしない。
+disable-model-invocation: true
+allowed-tools: Read, Write, Glob, Grep, AskUserQuestion, Bash
+argument-hint: <今回の変更の焦点（任意）>
+---
+
+# 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 既定）は、その節を実際に更新した時点で日時へ置き換える。日時は Bash の `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/claude/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/claude/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/claude/skills/intent-discover/SKILL.md

@@ -0,0 +1,63 @@
+---
+name: intent-discover
+description: Intent Planning の入口。リポジトリの課題感・README・既存コード概要から Intent Tree (L0-L4) を構築し、Intent の詰め方モードを推奨・確定する。実装はしない。
+disable-model-invocation: true
+allowed-tools: Read, Write, Glob, Grep, AskUserQuestion
+argument-hint: <課題・アイデア・対象範囲>
+---
+
+# 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`）を確認し、リポジトリ状況からモードを推奨する。
+- `AskUserQuestion` で利用者に確認する（候補が 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 がある場合は破壊せず、差分を更新案として提示する。
+- アプリケーションコードは変更しない。