intent-planner 0.13.1

package/templates/ja/intent/intent-compass.md

@@ -0,0 +1,55 @@
+# Intent Compass
+
+> `/intent-compass` が更新します。局所最適を防ぐための判断基準を管理します。
+
+## North Star
+
+この変更で近づきたい最終状態。
+
+## Current Drift
+
+現状、どの intent からどうズレているか（このズレを drift と呼ぶ）。
+
+## Direction
+
+今回の作業で強める方向。
+
+## Anti-direction
+
+今回避ける方向。Claude がやりがちな局所最適（全体の意図より目先の修正を優先してしまうこと）・小手先リファクタもここに明示列挙する。例: 「ついでに別の処理も直す」「テストなしの一括置換」「ドメインロジックを UI に寄せる」。
+
+## Invariants
+
+絶対に壊してはいけない振る舞い・API・データ・UX・運用制約。
+
+> 否定形発問（「これを無視したら最悪何が起きるか」等）で確認した結果、真に守るべきと確定した**普遍**制約のみをここへ記入する（過剰前提は混入しない）。packet 固有の制約候補は Open Questions に保留する。
+
+ここに保持するのは**プロジェクト普遍 invariant** のみ:
+
+- **プロジェクト普遍 invariant**: feature を問わず全作業で守る少量の制約。`/kiro-steering-custom` で `.kiro/steering/` に置くと全作業で効く（起動時コンテキスト増を最小化するため少量に限る）。
+- **packet 固有 invariant**（特定の作業単位でのみ守る制約）の正本は各 packet ファイル（`.intent/packets/active/<packet_id>.md`）の Safety / Invariants 節。compass には書かない。export 時は packet ファイルから cc-sdd の tasks へ焼き込まれる。packet が archive へ移動すると packet 固有 invariant も packet ファイルとともに退場する（compass 側に残骸を残さない）。
+
+## Decision Rules
+
+迷ったときの判断基準。1判断1エントリの軽量 ADR として残す: **Context**（問いと状況）/ **Decision**（採る選択肢）/ **Why**（基準）/ **Alternatives considered**（検討した代替案。QOC の不採用 Options とその理由の要約）/ **Consequences**（Invariants・Anti-direction への接続）/ **Revisit when**（見直し条件。定まらない場合は「未定」と明示し空欄にしない）。決定を覆すときは、新しいエントリを追加し、古いエントリに superseded と後継への参照を明記したうえで6欄のまま `.intent/compass-archive.md` へ移動する（compass には現役の判断基準だけが残る）。
+
+例:
+- **Context**: 集計ロジックの置き場所（UI で完結 vs ドメイン層） / **Decision**: ドメイン層に置く / **Why**: L3 の境界 intent（UI は表示のみ）に一致 / **Alternatives considered**: UI で完結 — 表示と集計が混在し L3 の境界 intent に反するため不採用 / **Consequences**: Invariant「Domain logic を UI framework に寄せない」を全 packet に課す / **Revisit when**: 表示専用の集計がドメイン層を肥大化させ始めたとき
+- **Context**: 大きな置換の進め方（一括置換 vs 段階移行） / **Decision**: rollback 可能な slice を優先 / **Why**: behavior-preserving を観測可能に保つ / **Alternatives considered**: 一括置換 — 失敗時に切り戻せず behavior-preserving を観測できないため不採用 / **Consequences**: Anti-direction「テストなしの大規模置換」を禁止に追加 / **Revisit when**: 未定
+
+## Evidence
+
+この intent を支える証拠。README、コード、テスト、ログ、ユーザー課題、運用課題など。
+
+Updated (Invariants): —
+Updated (Decision Rules): —
+
+> Invariants 節 / Decision Rules 節それぞれを最後に更新した時点。`/intent-compass` が当該節を更新したときに ISO 8601 で打刻する（初期値の `—` は未打刻を表す）。read-only 検証（intent-validate の stale 検査）が packet の `updated_at` と比較する際の compass 側の基準であり、`—` の節は比較対象外（未検証としてスキップ）になる。
+
+## Open Questions
+
+判断に必要だが未確定の問い。
+
+> 否定形発問で挙がった制約のうち、特定の作業単位でのみ守る **packet 固有制約（候補）** は、行き先の packet が定まるまでここに保留する（packet 起票時に当該 packet の Safety / Invariants へ転記される）。
+
+> 回答はいつでも構いません（未回答でも planning は先に進められます）。このファイルを直接編集するか、会話で伝えると次のスキル実行時に反映されます。export までに回答が必要な問いにのみ `[export まで]` タグを付けます（タグのない問いはいつでも回答可）。

package/templates/ja/intent/intent-tree.md

@@ -0,0 +1,59 @@
+# Intent Tree
+
+> `/intent-discover` が更新します。canonical（確定）と inferred（推測=Assumptions）を混ぜないこと。L0〜L4 は意図の階層レベル（Level。L0=目的 〜 L4=作業単位候補）。
+
+## L0: Product Purpose
+
+このプロダクト / アプリ / サブシステムは何のために存在するか。
+
+> 推論した目的をユーザーに追認した結果（確定した目的）を canonical として記入する。未追認・推測のものは Assumptions へ。
+
+## L1: Desired Outcomes
+
+ユーザー・事業・運用・開発体験にどんな状態変化を起こしたいか。designer-questions が on のときは、各 L1 項目に `計測基準:` 行（達成をどう観測・判定するか）を併記する。
+
+> 追認した想定ユーザー（Actor）と成功の定義をここに記入する（誰のどんな状態変化か）。追認できていないものは Assumptions / Open Questions へ。
+
+## L2: Capabilities
+
+Desired Outcome を支える能力。機能名ではなく、責務・能力として書く。
+
+## L3: Behavioral / Architectural Intents
+
+Capability を成立させるための振る舞い・設計意図。境界、依存方向、副作用、データ整合性、UI/UX 制約などを含める。
+
+## L4: Candidate Packets
+
+実装に落とす前の候補作業単位。Issue より少し上位、spec より少し手前の粒度。
+
+## PoC 実験定義（purpose: poc のとき記入）
+
+> `/intent-discover` が purpose=poc のときに更新します。purpose が poc でない場合は空のままで構いません。
+
+### 仮説
+
+この PoC で何を確かめるか。
+
+### 反証条件
+
+何が観測できなければ仮説を棄却するか。
+
+### GO/NO-GO 基準
+
+PoC 完了後に先へ進む / やめるを判定する条件。
+
+## 画面ラフ参照（designer-questions: on のとき記入）
+
+> `/intent-discover` が designer-questions=on のときに更新します。ユーザー向け画面を含む場合はラフ（ワイヤーフレーム・スケッチ等）のパスまたはリンク、無しと判断した場合はその理由。UI 非該当の場合は「対象外」。
+
+## Open Questions
+
+人間が確認すべき未確定事項。
+
+> 追認できなかった目的・成功の定義・想定ユーザーは、確定するまでここに保留する（確定したら L0 / L1 へ移す）。
+
+> 回答はいつでも構いません（未回答でも planning は先に進められます）。このファイルを直接編集するか、会話で伝えると次のスキル実行時に反映されます。export までに回答が必要な問いにのみ `[export まで]` タグを付けます（タグのない問いはいつでも回答可）。
+
+## Assumptions
+
+AI が推測した前提。推測は canonical な intent と混ぜない。

package/templates/ja/intent/milestones/README.md

@@ -0,0 +1,10 @@
+# milestones/（分割形の active 面）
+
+milestones は **事象由来**の記録なので、**日付+slug 単位ファイル** `milestones/<date>-<event-slug>.md` に分割して書く。別事象が別ファイルを触るため末尾衝突が原理的に消える。
+
+- ここ（active 面）には現在参照する節目イベントだけを薄く置く。
+- 終端した（もう参照しない）エントリは `milestones/archive/<年>/` へ退避する。
+- ファイル名の `<event-slug>` は event 自然文を既存のスラッグ規則（`intent-packets/rules/packet-format.md`）で導出する。`<date>` は recorded_at。連番（`0001` 等の中央カウンタ）は使わない。
+- **手動記入**: milestones は利用者が宣言的に記入する記録です。分割形では、節目イベントごとに `milestones/<date>-<event-slug>.md` を1ファイル作って `| event | recorded_at | note |` の1行を書きます（event 自然文はそのまま保持＝improve の Revisit 照合・status の未消化検出が読む）。
+
+> この README は規約の**言い換え**であり、規約の単一正本は CONTRACT.md「append-only 記録の分割・archive 規約」。置き方の判断は CONTRACT を参照すること。

package/templates/ja/intent/milestones.md

@@ -0,0 +1,22 @@
+# Milestones
+
+> プロジェクトの節目イベント（「本番構成確定」「外部公開 API 化」等）を1行追記で記録します。書き手は利用者だけで、読み手は `/intent-improve`（各 event を Decision Rules の `Revisit when` と照合）と `/intent-status`（未消化 milestone の残課題表示）です。決定・学び・状態は持たず、節目イベントの記録専用です。
+
+## 運用説明
+
+- **append-only**: 行は追記のみです。過去の行を書き換えたり削除したりしません（世界線アンカーの非対称を生まないため）。
+- **利用者が宣言的に記入する**: 節目イベントは利用者が手で記入します。このファイルは自動検出をしません（記録の主体は利用者です）。
+- **分割形で記入する（CONTRACT「append-only 記録の分割・archive 規約」）**: milestones は事象由来なので、この単一ファイル末尾へ追記する代わりに、節目イベントごとに **日付+slug 単位の分割ファイル** `milestones/<date>-<event-slug>.md` を1ファイル作って `| event | recorded_at | note |` の1行を書きます。`<date>` は recorded_at、`<event-slug>` は event 自然文を既存スラッグ規則（`intent-packets/rules/packet-format.md`）で導出します（連番は使いません）。event 自然文はそのまま保持してください（読み手の照合対象）。置き方の詳細は `milestones/README.md`、規約の正本は CONTRACT を参照。終端した節目は `milestones/archive/<年>/` へ退避できます。
+- **読み手の参照**: `/intent-improve` が各 `event` を全 Decision Rule の `Revisit when` 欄と substring（部分文字列）照合し、合致した Rule を見直し再提案へ挙げます。`/intent-status` は記録済みだが対応する見直しが未処理の milestone を残課題として併記します。いずれも read-only の照合で、compass を自動書き換えしません。
+
+## 記入の指針
+
+- **event**: Decision Rule の `Revisit when` と substring 照合する自然文の文字列です。短すぎると過剰一致するため、何が確定した節目かが分かる十分に具体的な自然文を書いてください（例:「本番構成を AWS ECS に確定」）。
+- **recorded_at**: ISO 8601（例: `2026-06-18`）で記入します。
+- **note**: 任意の補足です（不要なら `-`）。
+
+| event | recorded_at | note |
+|---|---|---|
+<!-- 記入例（このコメント行は実テーブルに含めません）:
+| 本番構成を AWS ECS に確定 | 2026-06-18 | 開発合宿でインフラ方針を確定 |
+-->

package/templates/ja/intent/mode.local.md

@@ -0,0 +1,23 @@
+# Active Mode（ローカル）
+
+> `/intent-discover` がモードを確定したときに更新します。これは intent-* スキル間で共有される作業状態（mode の詰め方）です。
+> **このファイルはローカル専用（git 非追跡）です。** チーム/並行セッションで各自の作業モードが衝突しないよう、`mode` / `designer-questions` / `purpose`（作業の詰め方）をここに置きます。共有したいポリシー（Enforcement / Drift-watch）は `mode.md`（追跡）にあります。
+
+- **mode**: (未確定 — `/intent-discover` を実行すると推奨・確定されます)
+- **selected**: (確定日 ISO 8601)
+- **reason**: (なぜこのモードが選ばれたか)
+- **definition**: (例: `.intent/modes/standard.md`)
+- **designer-questions**: (未確定 — on / off。設計者役の詰めの問い。`/intent-discover` が説明・確認・記録します)
+- **purpose**: (未確定 — poc / product。designer-questions が on のとき `/intent-discover` が確認・記録します)
+- **format**: (未確定 — cc-sdd / openspec / to-spec。案件の出力体裁＝どの出口へ進むか。任意。`/intent-discover` が推奨・確認・記録します。未指定なら出口は案件種別から推論されます)
+
+## このファイルの扱い（スキル共通の規約）
+
+- `/intent-discover` がモード推奨 → 利用者確認 → ここに確定結果を書きます。
+- `/intent-compass` / `/intent-packets` / `/intent-export-cc-sdd` 等は、このファイルを読み、`definition` のモード定義に従って動きます。
+- **読み取りの後方互換（read fallback）**: 読み手は **このファイル（`mode.local.md`）→ 無ければ旧 `mode.md` の mode 状態 → どちらにも無ければ `standard` 既定** の順で読みます。旧 scaffold（mode 状態が `mode.md` にしか無い既存環境）でも壊れません。
+- **このファイルが未確定 / 不在のとき**: 各スキルは停止せず `standard` を既定モードとして続行し、出力の Open Questions に「モードが未確定。`/intent-discover` でモードを確定することを推奨」を併記します。
+- これは「前段の成果物（tree/compass/packets）が無いとき停止案内する」のとは区別されます。mode 状態の不在だけでは停止しません。
+- **designer-questions / purpose が未記録・行自体が無い（旧 scaffold）とき**: 各スキルは停止せず未確定として続行し、出力の Open Questions に告知します。読み手は必ず designer-questions を先に判定します（on と記録されていない限り purpose の値を参照しません）。designer-questions / purpose を書くのは `/intent-discover` のみです。
+- **format の読み取り契約（未指定の3形態）**: `format` は案件の出力体裁（どの出口へ進むか＝ cc-sdd / openspec / to-spec）を記録する任意フィールドです。読み手（`/intent-packets` の出口判定・export 系の preflight）は、次の3形態をすべて「**未指定**」として同一に扱い、停止せず案件種別（mode・`.kiro/` の有無等）からの**推論**へ倒します: ①`format` 行が無い（旧 scaffold / 既存環境）②プレースホルダ値（`(未確定 — …)`）③値域（cc-sdd / openspec / to-spec）外の値。`format` が有効値で明示されているときのみ、その出口を確定的に読み取ります。`format` を書くのは `/intent-discover` のみで、未指定でも各スキルは従来どおり動作します（後方互換）。
+- **ローカル専用の理由**: `mode` / `designer-questions` / `purpose` は「いま誰が・どの作業をしているか」に紐づく動的な状態です。git で共有すると、チーム開発で他メンバーの作業モードが pull で降ってきたり、並行セッションで上書きされて衝突します。そのため git 非追跡にします（installer が `.gitignore` に登録します）。共有したいポリシー（Enforcement / Drift-watch）は追跡される `mode.md` に置きます。

package/templates/ja/intent/mode.md

@@ -0,0 +1,32 @@
+# Shared Policy（共有ポリシー）
+
+> このファイルは **チームで共有する（git 追跡される）** ポリシーを置きます: `Enforcement`（書き戻し強制）と `Drift-watch`（逸脱監視）。
+> **作業の詰め方（`mode` / `designer-questions` / `purpose`）は `mode.local.md`（ローカル専用・git 非追跡）にあります。** チーム/並行セッションでの衝突を避けるため分離しています。
+> **後方互換**: 旧 scaffold ではこのファイルに mode 状態も同居していました。読み手は `mode.local.md` を先に読み、無ければこのファイルの mode 状態行（在れば）にフォールバックします。
+
+## Enforcement（ユーザー管理）
+
+> このセクションは利用者だけが編集します。`/intent-discover` を含むスキルはこのセクションを変更しません（読み取りのみ）。
+
+- **enforcement**: off
+- **enforcement-threshold**: 5
+- **enforcement-exclude**: 
+
+- **enforcement** — 書き戻し（writeback）強制の強度。値は `off` | `remind` | `gate` の3つです:
+  - `off`（既定）: 検査を行いません。従来どおりの動作です。
+  - `remind`: 書き戻し漏れを検出したら警告のみ表示します。停止はしません。
+  - `gate`: 書き戻し漏れを検出したら export / push を停止します（明示的な続行指示や `--no-verify` の逃げ道は残ります）。
+- **enforcement-threshold** — staleness（書き戻し漏れ）と判定するコミット数の閾値です。正の整数（既定: 5）。
+- **enforcement-exclude** — staleness の計数から除くパス（カンマ区切りの相対パス接頭辞。空のままで構いません）。`.intent/` は常に暗黙で除外されます。
+- 切り替えはこのファイルを直接編集して行います。未記載・不正値のときは off / 5 / 除外なし として扱われ、停止しません。
+
+## Drift-watch（ユーザー管理）
+
+> このセクションは利用者だけが編集します。`/intent-discover` を含むスキルはこのセクションを変更しません（読み取りのみ）。
+
+- **drift-watch**: off
+
+- **drift-watch** — 逸脱（drift）監視の強度。値は `off` | `on` の2つです:
+  - `off`（既定）: 何もしません。従来どおりの動作です。
+  - `on`: discover で地形診断、export 水際で compass 照合の警告を出し、検知を drift-log.md に記録します。**いずれも警告のみで、停止はしません**（enforcement の gate とは別概念。誤検知前提のため停止しません）。
+- 切り替えはこのファイルを直接編集して行います。off|on の2値のみで、停止（gate 相当）の値は持ちません。未記載・不正値のときは off として扱われ、停止しません。

package/templates/ja/intent/modes/README.md

@@ -0,0 +1,28 @@
+# Modes — Intent の詰め方アルゴリズムの拡張点
+
+このディレクトリは「モード」を保持します。モードとは、Intent をどう詰めるか（アルゴリズムの組み合わせ）を定義した戦略です。`/intent-discover` がリポジトリ状況からモードを推奨し、確定したモードは `../mode.md` に記録されます。以降のコマンドは `mode.md` を読み、対応するモード定義に従って動きます。
+
+## 3層構造
+
+Intent の詰め方は3層に分離されています。
+
+1. **Mode**（`modes/*.md`）— フェーズ → アルゴリズムの組み合わせ表（このディレクトリ）
+2. **Algorithm**（各 skill の `rules/algo-*.md` / `rules/map-*.md`）— 個別の Intent 抽出・変換技法
+3. **Skill**（`.claude/skills/intent-*/SKILL.md`）— モードを読み込んで実行する実体
+
+## 同梱モード
+
+- `standard.md` — GORE-lite + QOC + Example Mapping + map-cc-sdd。標準（既定）の汎用モード。新規プロダクトに加え、状況特化モードが当てはまらない既存プロジェクトでも使う。
+- `refactor.md` — GORE-lite + Drift Analysis + Migration Slicing + QOC + map-cc-sdd。既存大規模プロジェクトのリファクタ・再設計向け。
+- `behavior-unknown.md` — GORE-lite + Example Mapping + Characterization Test + QOC + map-cc-sdd。振る舞いが不明なレガシー向け。
+- `feature-growth.md` — GORE-lite + Impact Analysis + QOC + Example Mapping + Additive Slicing + map-cc-sdd。既存の稼働中システムへの新機能追加向け。
+- `non-code.md` — GORE-lite + QOC + Example Mapping + map-cc-sdd。非プログラム成果物（文書・業務プロセス・研究/意思決定）向け（cc-sdd/openspec を使わず読める成果物を出す）。
+
+## 新しいモードを追加する
+
+1. このディレクトリに `modes/<your-mode>.md` を1枚追加する。`standard.md` を雛形に、各フェーズ（discover/compass/packets/export）でどのアルゴリズムを使うかの組み合わせ表と適合状況を書く。
+2. 既存のアルゴリズム（GORE-lite/QOC/Example Mapping/map-cc-sdd）で足りる場合は、それらを参照するだけでよい。
+3. 新しいアルゴリズムが必要な場合のみ、対応する skill の `rules/` に `algo-<name>.md` を追加し、モード定義から参照する。
+4. `/intent-discover` のモード推奨ロジック（`intent-discover/rules/mode-selection.md`）に、新モードを推奨する条件を追記する。
+
+`refactor.md` / `behavior-unknown.md` / `feature-growth.md` は同梱済みです。さらに別のモードを足したい場合に、上記の手順で追加してください。

package/templates/ja/intent/modes/behavior-unknown.md

@@ -0,0 +1,57 @@
+# Mode: behavior-unknown
+
+振る舞いが不明なレガシーコードを対象に、観測可能な挙動を例で固定し、未知の振る舞いを characterization で押さえてから意図を起こすモード。
+
+## このモードが組み合わせるアルゴリズム
+
+| フェーズ | アルゴリズム | 目的 |
+|---|---|---|
+| Intent Tree 構築 | **GORE-lite** (Goal-Oriented Requirements Engineering の軽量版) | L0(目的)→L1(成果)→L2(能力)→L3(振る舞い/設計意図)→L4(候補パケット) へゴールを段階分解する。仕様が失われている場合、L3 は確定でなく inferred(推測) として置き、後段の characterization で裏取りする |
+| 判断の記録 | **QOC** (Questions-Options-Criteria) | 設計判断を「問い・選択肢・選択基準」で残し、Compass の Decision Rules / Open Questions に流す |
+| 振る舞いの具体化 / packet 分解 | **Characterization Test** → **Example Mapping** | 未知の挙動はまず Characterization Test で「現状こう動く」を観測点として固定し、その観測事実を Example Mapping でルール・例・疑問・切り出しへ整理して、packet の Expected Behavior と Validation を導く（既知の部分集合のみ Example Mapping 先行可） |
+| spec への橋渡し | **map-cc-sdd** | 選んだ packet を cc-sdd の Project Description / design・tasks ヒントへ変換する |
+
+各アルゴリズムの詳細は、対応する skill の `rules/algo-*.md`（map-cc-sdd は `rules/map-cc-sdd.md`）にあります。このモード定義はそれらを「どのフェーズで使うか」の組み合わせ表です。
+
+## 各コマンドでの適用
+
+### intent-discover (GORE-lite)
+- L0: なぜ存在するか。1〜2文。
+- L1: 誰の・何の状態をどう変えたいか（ユーザー/事業/運用/開発体験）。
+- L2: L1 を支える能力。機能名でなく責務として書く。
+- L3: L2 を成立させる振る舞い・設計意図（境界・依存方向・副作用・整合性・UX制約）。
+- L4: 実装手前の候補作業単位。Issue より上位、spec より手前。
+- 仕様やテストが失われている対象では、現状の挙動が正しいとは限らない。観測から起こした L3 は canonical(確定) ではなく inferred(推測=Assumptions) として置き、絶対に確定と混ぜない。
+- 「現状の挙動が正なのか不明」な分岐は QOC の種として Open Questions に置き、後段の Characterization Test で観測して裏取りする。
+
+### intent-compass (QOC)
+- Intent Tree から North Star を引く。
+- 各 Decision Rule は軽量 ADR として凝縮: Context(問いと状況) / Decision(採る選択肢) / Why(基準) / Consequences(Invariants・Anti-direction への接続)。QOC は選択肢を比較する探索の道具、Decision Rule は将来の実装セッションを拘束する正本。
+- Anti-direction には Claude がやりがちな局所最適を必ず明示列挙する。特に「未確認の挙動を正しいと決めつけて変更する」傾向を明示する。
+- Invariants は壊してはいけない振る舞い/API/データ/UX/運用制約。プロジェクト普遍 / packet 固有 の2層に区別する。振る舞い不明な対象では、まず Characterization Test で観測して確定した挙動だけを Invariant に昇格させる。
+
+### intent-packets (Example Mapping + Characterization Test)
+- **実行順序（重要）**: 振る舞いが不明な対象では、知らない挙動の「例」は書けない。よって **Characterization Test を先に**走らせて現状の生の挙動を観測・固定し、その観測事実を入力に **Example Mapping で後から**ルール・例・疑問・切り出しへ整理する。すでに理解できている挙動の部分集合についてのみ、Example Mapping を先行させてよい。
+- **どちらに振り分けるか（ルーティング）**: ある挙動を「すでにルールとして言語化できる」なら Example Mapping、「経験的に観測してしか押さえられない（仕様が失われ確証がない）」なら Characterization Test。両者とも観測可能な挙動を扱うが、判断軸は「articulate できるか / pin するしかないか」。
+- Characterization Test（先）:
+  - 現状のコードを入力し、「今こう動く」を観測してそのまま観測点に固定する（正しさの判断は保留し、現状を記録する）。意図的な挙動か偶発的な挙動かを仕分け、仕分け不能なものは Open Questions へ送る。
+  - 観測した現状挙動を packet の Expected Behavior / Validation の出発点にし、未知の挙動を回帰の安全網として押さえる。
+- Example Mapping（後／既知部分は先）:
+  - ルール: その能力が従う規則（characterization の観測事実、または既知の挙動から導く）
+  - 例: 観測可能な具体シナリオ → packet の Expected Behavior
+  - 疑問: 未確定 → packet の Open Questions / Compass へ差し戻し
+  - 切り出し: 今回やらないと決めたこと → 黙って落とさず `.intent/packets/plan.md` の Deferred 節に記録し、後続 packet の種 / Open Questions にする
+- 例と characterization 観測点から Validation（テスト/手動/型/ログ）と Rollback を導く。
+- packet は testable / rollbackable を満たす。数は改修見込みの規模に応じて可変とし、数合わせをしない（小規模なら 1 個でよい・1〜7 を緩い目安とする）。各 packet に parent intent と、characterization で押さえた観測点への参照を残す。ここでの **behavior-preserving は「characterization で固定した現状挙動を回帰ベースラインとして保つ」意味**であり、現状の挙動が正しいと主張するものではない（誤った挙動の修正は別途 intent として明示する）。
+
+### intent-export-cc-sdd (map-cc-sdd)
+- packet 1つを cc-sdd の Project Description（凝縮）と design/tasks ヒントへ変換。
+- 入力は対象 packet と Compass の Invariants/Anti-direction に限定する。
+- tasks ヒントには必ず parent intent と invariant への参照を残す。
+
+## 適合する状況
+- 振る舞いが不明なレガシーコードが対象のとき
+- テストがない、または少なく、現状の挙動を保証する安全網が欠けているとき
+- 仕様・設計意図が失われており、コードの観測からしか振る舞いを起こせないとき
+- 現状の挙動が正しいのか不明で、まず「今どう動くか」を固定してから意図を構造化したいとき
+- **refactor との使い分け**: 現状の振る舞いが既知で信頼できる（あるべき設計を言語化できる）なら refactor。現状の振る舞いが不明・信頼できず、観測して固定するところから始める必要があるなら behavior-unknown。

package/templates/ja/intent/modes/feature-growth.md

@@ -0,0 +1,57 @@
+# Mode: feature-growth
+
+既存の稼働中システムに新機能を安全に付加するためのモード。新機能が触れる既存の境界・契約を実装前に棚卸して保護し、接合面（seam）を先に確立してから付加的に積むことで、既存のアーキテクチャ境界を守ったまま機能を育てる。
+
+## このモードが組み合わせるアルゴリズム
+
+| フェーズ | アルゴリズム | 目的 |
+|---|---|---|
+| Intent Tree 構築 | **GORE-lite** (Goal-Oriented Requirements Engineering の軽量版) + **Impact Analysis** | L0(目的)→L1(成果)→L2(能力)→L3(振る舞い/設計意図)→L4(候補パケット) へゴールを段階分解し、新機能の intent を既存の Intent Tree へ追記する。続いて新機能が触れる既存の境界・契約・データフローを読解で棚卸し、影響リスト（触れる境界 / 依存する既存契約 / 影響の種類）を起こす |
+| 判断の記録 | **QOC** (Questions-Options-Criteria) | 設計判断を「問い・選択肢・選択基準」で残し、Compass の Decision Rules / Open Questions に流す |
+| 振る舞いの具体化 / packet 分解 | **Example Mapping** + **Additive Slicing** | 新機能の振る舞いを観測可能な具体例(ルール・例・疑問・切り出し)に落とし、接合面(seam)の確立→付加→結線の3段の付加スライスへ分解して、packet の Expected Behavior と Validation を導く |
+| spec への橋渡し | **map-cc-sdd** | 選んだ packet を cc-sdd の Project Description / design・tasks ヒントへ変換する |
+
+各アルゴリズムの詳細は、対応する skill の `rules/algo-*.md`（map-cc-sdd は `rules/map-cc-sdd.md`）にあります。このモード定義はそれらを「どのフェーズで使うか」の組み合わせ表です。
+
+## 各コマンドでの適用
+
+### intent-discover (GORE-lite + Impact Analysis)
+- 冒頭に**簡易 Impact Mapping**（Adzic: Why→Who→How→What の一方向ツリー）を一枚書き、機能追加と事業成果の接続を確認してから GORE-lite へ移る。機能追加は「何を作るか（What）」が先行して Why が切れやすい。確認した Impact の階層はそのまま GORE-lite の L0–L2 へ深化させる: Why は L0/L1（目的・成果）へ、Who/How は L1（誰の・何の状態をどう変えるか）へ、What は L2 以下の候補の種へ。
+- GORE-lite で新機能の intent を既存の Intent Tree へ**追記**する（インクリメンタル更新）。既存 tree がまだ無い場合は、新機能の範囲で L0–L4 を起こす。
+- L0: なぜ存在するか。1〜2文。
+- L1: 誰の・何の状態をどう変えたいか（ユーザー/事業/運用/開発体験）。
+- L2: L1 を支える能力。機能名でなく責務として書く。
+- L3: L2 を成立させる振る舞い・設計意図（境界・依存方向・副作用・整合性・UX制約）。
+- L4: 実装手前の候補作業単位。Issue より上位、spec より手前。
+- 続いて Impact Analysis で、新機能が触れる既存の境界・契約・データフローを読解で棚卸し、影響リスト（各項目: 触れる境界 / 依存する既存契約 / 影響の種類、証拠付き）を作成する（詳細は `algo-impact-analysis.md`）。影響リストは compass の Invariants 化と packets の接合点設計の入力になる。
+- canonical(確定) と inferred(推測=Assumptions) を絶対に混ぜない。
+- **drift を発見したら直さない**: 調査中に既存設計の構造的問題（drift: feature-growth の目的外の問題）を見つけたら、本モード内で修正せず Open Questions へ記録し、refactor モードでの別作業を推奨する。
+
+### intent-compass (QOC)
+- Intent Tree から North Star を引く。
+- 影響リストの各境界を Invariants 化する（「X の既存契約を変えない」）。Invariants は壊してはいけない振る舞い/API/データ/UX/運用制約。プロジェクト普遍 / packet 固有 の2層に区別する。
+- Anti-direction には Claude がやりがちな局所最適を必ず明示列挙する。feature-growth 固有の典型をプレモータム（先回りの失敗想定）で列挙する: 「ついでに既存をリファクタする」「seam を作らず既存モジュールへ直埋めする」「既存テストを書き換えて辻褄を合わせる」。
+- 各 Decision Rule は軽量 ADR として凝縮: Context(問いと状況) / Decision(採る選択肢) / Why(基準) / Consequences(Invariants・Anti-direction への接続)。QOC は選択肢を比較する探索の道具、Decision Rule は将来の実装セッションを拘束する正本。
+
+### intent-packets (Example Mapping + Additive Slicing)
+- Example Mapping で新機能の振る舞いを具体化する:
+  - ルール: その能力が従う規則
+  - 例: 観測可能な具体シナリオ → packet の Expected Behavior
+  - 疑問: 未確定 → packet の Open Questions / Compass へ差し戻し
+  - 切り出し: 今回やらないと決めたこと → 黙って落とさず `.intent/packets/plan.md` の Deferred 節に記録し、後続 packet の種 / Open Questions にする
+- **入力契約（重要）**: Additive Slicing は discover フェーズの Impact Analysis が出した**影響リストを入力に取る**。薄い影響リストはスライスを推測にする — 接合点を設計できる厚みが無ければ discover に戻って影響リストを厚くする。
+- Additive Slicing で、Example Mapping の例が流れ込んだ新機能を「接合面(seam)の確立 → 新機能の付加的な積み上げ → 既存への結線」の3段の付加スライスへ分解する（詳細は `algo-additive-slicing.md`）。
+- **影響リストのトレーサビリティ（必須）**: 影響リストの各項目は「いずれかのスライスの Safety / Invariants で保護される」か「Open Questions へ送られる」かのいずれかに終端させる。項目を黙って落とさない。
+- 例から Validation（テスト/手動/型/ログ）と Rollback を導き、各 packet に Toggle Plan（どの範囲が off-by-default か / toggle の削除条件）を付ける。
+- packet は behavior-preserving / testable / rollbackable を満たす。数は改修見込みの規模に応じて可変とし、数合わせをしない（小規模なら 1 個でよい・1〜7 を緩い目安とする）。各 packet に parent intent（影響リスト項目の保護なら元の項目も）への参照を残す。
+
+### intent-export-cc-sdd (map-cc-sdd)
+- packet 1つを cc-sdd の Project Description（凝縮）と design/tasks ヒントへ変換。
+- 入力は対象 packet と Compass の Invariants/Anti-direction に限定する。
+- tasks ヒントには必ず parent intent と invariant への参照を残す。
+
+## 適合する状況
+- 既存の稼働中システムに新機能を追加するとき（extend / integrate / add-to 系の要望）
+- 対象の振る舞いが既知で、再設計（drift 解消）が目的でないとき
+- 新しい作業が既存のアーキテクチャ境界・依存方向を壊さないよう、触れる境界を体系的に棚卸して保護したいとき
+- **standard / refactor / behavior-unknown との使い分け**: 既存の構造を変えたい（drift 解消・再設計が目的）なら refactor。現状の振る舞い自体が不明で、まず観測・固定が必要なら behavior-unknown。新規プロダクトや汎用的な意図整理なら standard。既存システムへの機能の付加が目的なら feature-growth。

package/templates/ja/intent/modes/non-code.md

@@ -0,0 +1,46 @@
+# Mode: non-code
+
+非プログラム成果物（文書・業務プロセス・研究/意思決定など）の意図を詰めるためのモード。コードという成果物を前提にせず、文章・手順・判断といった非実行物を成果物として、その意図を段階分解し具体化する。詰め方（how-to-elaborate）の軸のみを担い、最終的な出力フォーマット（target format）は別の軸（format）が担当するため、このモード定義には出力形式の取り決めを書かない。
+
+## このモードが組み合わせるアルゴリズム
+
+非プログラム成果物（文書・業務プロセス・研究/意思決定）の意図をどう詰めるか（how-to-elaborate）の組み合わせ表。standard と同じ基幹 algo を流用し、目的列の語彙だけを非プログラム成果物（文書・業務・研究）向けに読み替える。新しい algo rule ファイルは追加しない（流用）。
+
+| フェーズ | アルゴリズム | 目的 |
+|---|---|---|
+| Intent Tree 構築 | **GORE-lite** (Goal-Oriented Requirements Engineering の軽量版) | L0(目的)→L1(成果)→L2(能力)→L3(振る舞い/設計意図)→L4(候補パケット) へゴールを段階分解する。ここでの「能力・振る舞い」は実装ではなく、文書・手順・判断という非実行物が満たすべき内容・流れ・論点として読み替える |
+| 判断の記録 | **QOC** (Questions-Options-Criteria) | 設計判断を「問い・選択肢・選択基準」で残し、Compass の Decision Rules / Open Questions に流す。非プログラム案件では「どう書くか・どう進めるか・何を決めるか」の判断を残す |
+| 成果物の具体化 | **Example Mapping** | 抽象的な能力を、観測可能な具体例(ルール・例・疑問・切り出し)に落とし、packet の Expected Behavior と Validation を導く。非プログラム成果物では「観測可能」を受容基準で判定可能な記述（読めば合否が分かる例）として扱う |
+| spec への橋渡し | **map-cc-sdd** | 選んだ packet を cc-sdd の Project Description / design・tasks ヒントへ変換する（export 経路。非プログラム向け target format への射影は format 軸が担当） |
+
+各アルゴリズムの詳細は、対応する skill の `rules/algo-*.md`（map-cc-sdd は `rules/map-cc-sdd.md`）にあります。このモード定義はそれらを「どのフェーズで使うか」の組み合わせ表です。新規 algo は導入せず、既存 algo を非プログラム成果物へ流用します。
+
+## 各コマンドでの適用
+
+### intent-discover (GORE-lite)
+- L0: なぜこの成果物（文書・業務プロセス・研究/意思決定）が要るか。1〜2文。
+- L1: 誰の・何の状態をどう変えたいか（読者/業務/意思決定/合意形成）。
+- L2: L1 を支える成果物の責務。章立てや機能名でなく「何を満たすか」として書く。
+- L3: L2 を成立させる内容・流れ・論点（網羅範囲・順序・前提・整合性・読者制約）。
+- L4: 実装手前ならぬ清書手前の候補作業単位（書く章/詰める手順/決める論点）。
+- canonical(確定) と inferred(推測=Assumptions) を絶対に混ぜない。
+
+### intent-compass (QOC)
+- Intent Tree から North Star を引く。
+- 各 Decision Rule は軽量 ADR として凝縮: Context / Decision / Why / Consequences。非プログラム案件では「どう書くか・どう進めるか・何を決めるか」の判断を拘束力ある正本として残す。
+- Invariants は壊してはいけない内容/合意/体裁/運用制約（既存成果物の意味・合意を壊さない）。プロジェクト普遍 / packet 固有 の2層に区別する。
+
+### intent-packets (Example Mapping)
+- 各 L2/L3 能力について Example Mapping を行う（ルール・例・疑問・切り出し）。例は packet の Expected Behavior、疑問は Open Questions、切り出しは `.intent/packets/plan.md` の Deferred 節へ。
+- 非プログラム成果物では Validation/Rollback の検証語彙をコード前提から degrade して読み替える（testable→受容基準で判定可能 / rollback→版管理・差し戻し / behavior-preserving→既存成果物の意味・合意を壊さない）。この読み替えは任意の degrade であり、コード前提の語彙を必須にしない。読み替え語彙の定義は packet-format 側を参照し、ここでは二重定義しない。
+- packets 段はスキップせず、決定スロットの播種を残す。
+
+### intent-export-cc-sdd (map-cc-sdd)
+- packet 1つを cc-sdd の Project Description（凝縮）と design/tasks ヒントへ変換。入力は対象 packet と Compass の Invariants/Anti-direction に限定する。
+- 非プログラム向けの読める成果物体裁への射影は本モード（詰め方）ではなく format 軸（target format）が担当する。
+
+## 適合する状況
+
+- 成果物がコードでない案件（文書・仕様書・業務プロセス・手順・研究/意思決定の記録など）の意図を言語化したいとき
+- 「何を実装するか」ではなく「何を書くか・どう進めるか・何を決めるか」を段階分解して詰めたいとき
+- standard などコード前提のモードでは詰め方が成果物と噛み合わない、非プログラム案件のとき

package/templates/ja/intent/modes/refactor.md

@@ -0,0 +1,56 @@
+# Mode: refactor
+
+既存の大規模プロジェクトを、振る舞いを保ったままリファクタ・再設計するためのモード。設計意図と実装のドリフトを捉え、安全な移行スライスへ落とす。
+
+## このモードが組み合わせるアルゴリズム
+
+| フェーズ | アルゴリズム | 目的 |
+|---|---|---|
+| Intent Tree 構築 | **GORE-lite** (Goal-Oriented Requirements Engineering の軽量版) + **Intent Recovery**（意図不在のコードのみ）+ **Drift Analysis** | L0(目的)→L1(成果)→L2(能力)→L3(振る舞い/設計意図)→L4(候補パケット) へゴールを段階分解する。意図を書かずに作られたコード（vibe coding 等）では Intent Recovery でコードから候補 intent を逆算してから、現状の実装とあるべき設計意図とのドリフトを観測可能に捉える |
+| 判断の記録 | **QOC** (Questions-Options-Criteria) | 設計判断を「問い・選択肢・選択基準」で残し、Compass の Decision Rules / Open Questions に流す |
+| 振る舞いの具体化 / packet 分解 | **Migration Slicing** | あるべき設計と現状の差分を、behavior-preserving / testable / rollbackable な移行スライスへ分解し、packet の Expected Behavior と Validation を導く |
+| spec への橋渡し | **map-cc-sdd** | 選んだ packet を cc-sdd の Project Description / design・tasks ヒントへ変換する |
+
+各アルゴリズムの詳細は、対応する skill の `rules/algo-*.md`（map-cc-sdd は `rules/map-cc-sdd.md`）にあります。このモード定義はそれらを「どのフェーズで使うか」の組み合わせ表です。
+
+## 各コマンドでの適用
+
+### intent-discover (GORE-lite + Intent Recovery + Drift Analysis)
+- GORE-lite で L0–L4 を起こす。特に L3（振る舞い・設計意図）を、既存実装の暗黙の意図として丁寧に言語化する。
+- L0: なぜ存在するか。1〜2文。
+- L1: 誰の・何の状態をどう変えたいか（ユーザー/事業/運用/開発体験）。
+- L2: L1 を支える能力。機能名でなく責務として書く。
+- L3: L2 を成立させる振る舞い・設計意図（境界・依存方向・副作用・整合性・UX制約）。
+- L4: 実装手前の候補作業単位。Issue より上位、spec より手前。
+- **意図が書かれずに作られたコード（vibe coding 等）の場合**は、Drift Analysis の前に Intent Recovery を挟む。コードの構造・振る舞いから候補 intent を逆算し、すべて inferred（推測）として置く（確定と混ぜない）。これが無いと「あるべき設計意図」の基準点が存在せず Drift Analysis が空回りする。意図が明示的に存在するコードでは Intent Recovery は不要。
+- 続いて Drift Analysis で、現状の構造・依存方向・振る舞いを棚卸しし、各 L3（Intent Recovery を経た場合は復元した inferred intent）と突き合わせて「今こうなっている → 本来こうあるべき」の drift を列挙する。突き合わせは Reflexion worksheet（意図された責務・依存 vs 観測された責務・依存）で行い、各要素を整合 / 乖離 / 欠落に分類する（詳細は `algo-drift-analysis.md`）。
+- 各 drift は逸脱 / 腐敗 / 局所最適の蓄積として種類を区別し、対応する parent intent（L1/L2/L3）へ紐づける。
+- canonical(確定) と inferred(推測=Assumptions) を絶対に混ぜない。紐づく intent が曖昧な drift は Open Questions へ送る。
+
+### intent-compass (QOC)
+- Intent Tree から North Star を引く。
+- 各 Decision Rule は軽量 ADR として凝縮: Context(問いと状況) / Decision(採る選択肢) / Why(基準) / Consequences(Invariants・Anti-direction への接続)。QOC は選択肢を比較する探索の道具、Decision Rule は将来の実装セッションを拘束する正本。
+- Anti-direction には Claude がやりがちな局所最適を必ず明示列挙する。リファクタ固有の典型として、最低限「drift を直すついでに無関係な箇所まで触る（スコープ膨張）」「behavior-preserving を口実に実は挙動を変える」を明示する。
+- Invariants は壊してはいけない振る舞い/API/データ/UX/運用制約。プロジェクト普遍 / packet 固有 の2層に区別する。リファクタでは「移行中も保たれる既存の振る舞い」を特に明示する。
+
+### intent-packets (Migration Slicing)
+- **入力契約（重要）**: Migration Slicing は discover フェーズの Drift Analysis が出した **drift リストを入力に取る**。drift リストが薄い・曖昧だとスライスは推測になり質が落ちる。スライスを切る前に drift リストが十分かを確認し、不足なら discover に戻って drift を厚くする。
+- スライスを切る前に **Mikado pre-pass**（Mikado Method = 安全な変更順序を前提の逆算で求める手法）で「これを安全に変えるには先に何が真である必要があるか」を逆算して前提グラフを書き、前提を持たない葉から着手する（机上の逆算であり、試しのコード変更はしない。詳細は `algo-migration-slicing.md`）。
+- あるべき設計と現状の差分（drift リスト）を、振る舞いを壊さずに適用できる最小の移行スライスへ切る。
+- 各スライスは単体でデプロイ可能で、既存の振る舞いを保ったまま設計を一歩進めるものにする。
+- スライスを依存順に並べ、前のスライスが次を unblock する連鎖にする。どこで止めても中間状態が一貫している（behavior-preserving）ことを確認する。
+- 各スライスに characterization / 回帰の検証点（Validation）と、失敗時の巻き戻し（Rollback）を付ける（現状挙動の観測・固定の手順は `intent-packets/rules/algo-characterization-test.md` を流用してよい）。
+- **drift トレーサビリティ（必須）**: 列挙した drift は必ずいずれかに終端させる — (a) 移行スライス(packet)になる / (b) 今回やらないなら Open Questions か明示的な先送り（理由付き）にする。drift を見つけたまま黙って落とさない（局所最適の蓄積を放置しないという North Star の核心）。
+- packet は behavior-preserving / testable / rollbackable を満たす。数は改修見込みの規模に応じて可変とし、数合わせをしない（小規模なら 1 個でよい・1〜7 を緩い目安とする）。各 packet に parent intent（drift 由来なら元の drift も）への参照を残す。
+
+### intent-export-cc-sdd (map-cc-sdd)
+- packet 1つを cc-sdd の Project Description（凝縮）と design/tasks ヒントへ変換。
+- 入力は対象 packet と Compass の Invariants/Anti-direction に限定する。
+- tasks ヒントには必ず parent intent と invariant への参照を残す。
+
+## 適合する状況
+- 既存の大規模プロジェクトのリファクタ・再設計が対象のとき
+- 既存コード規模が大きく、設計意図と実装のドリフトが蓄積しているとき
+- 振る舞いを保ったまま（behavior-preserving に）段階的に設計を進めたいとき
+- 意図を書かずに作られたコード（vibe coding、prototype の本番化など）を、事後的に intent 体系へ取り込みたいとき（discover で Intent Recovery を併用する）
+- **behavior-unknown との使い分け**: 現状の振る舞いがある程度把握できており、あるべき設計を言語化できるなら refactor。現状の振る舞い自体が不明で、まず観測・固定が必要なら behavior-unknown。vibe coding は「振る舞いは観測できるが意図が不在」なケースが多く、refactor + Intent Recovery が適する。

package/templates/ja/intent/modes/standard.md

@@ -0,0 +1,50 @@
+# Mode: standard
+
+意図の言語化を汎用に行う標準（既定）モード。グリーンフィールド専用ではない: 新規プロジェクトに加え、状況特化モード（refactor / behavior-unknown / feature-growth）が当てはまらない既存プロジェクトの意図言語化にも使う。組み合わせるアルゴリズム（GORE-lite + QOC + Example Mapping）は全モードの基幹となる汎用の詰め方である。
+
+## このモードが組み合わせるアルゴリズム
+
+| フェーズ | アルゴリズム | 目的 |
+|---|---|---|
+| Intent Tree 構築 | **GORE-lite** (Goal-Oriented Requirements Engineering の軽量版) | L0(目的)→L1(成果)→L2(能力)→L3(振る舞い/設計意図)→L4(候補パケット) へゴールを段階分解する |
+| 判断の記録 | **QOC** (Questions-Options-Criteria) | 設計判断を「問い・選択肢・選択基準」で残し、Compass の Decision Rules / Open Questions に流す |
+| 振る舞いの具体化 | **Example Mapping** | 抽象的な能力を、観測可能な具体例(ルール・例・疑問・切り出し)に落とし、packet の Expected Behavior と Validation を導く |
+| spec への橋渡し | **map-cc-sdd** | 選んだ packet を cc-sdd の Project Description / design・tasks ヒントへ変換する |
+
+各アルゴリズムの詳細は、対応する skill の `rules/algo-*.md`（map-cc-sdd は `rules/map-cc-sdd.md`）にあります。このモード定義はそれらを「どのフェーズで使うか」の組み合わせ表です。
+
+## 各コマンドでの適用
+
+### intent-discover (GORE-lite)
+- L0: なぜ存在するか。1〜2文。
+- L1: 誰の・何の状態をどう変えたいか（ユーザー/事業/運用/開発体験）。
+- L2: L1 を支える能力。機能名でなく責務として書く。
+- L3: L2 を成立させる振る舞い・設計意図（境界・依存方向・副作用・整合性・UX制約）。
+- L4: 実装手前の候補作業単位。Issue より上位、spec より手前。
+- canonical(確定) と inferred(推測=Assumptions) を絶対に混ぜない。
+- 分解中に出た判断の分岐は QOC の種として Open Questions に置く。
+
+### intent-compass (QOC)
+- Intent Tree から North Star を引く。
+- 各 Decision Rule は軽量 ADR として凝縮: Context(問いと状況) / Decision(採る選択肢) / Why(基準) / Consequences(Invariants・Anti-direction への接続)。QOC は選択肢を比較する探索の道具、Decision Rule は将来の実装セッションを拘束する正本。
+- Anti-direction には Claude がやりがちな局所最適を必ず明示列挙する。
+- Invariants は壊してはいけない振る舞い/API/データ/UX/運用制約。プロジェクト普遍 / packet 固有 の2層に区別する。
+
+### intent-packets (Example Mapping)
+- 各 L2/L3 能力について Example Mapping を行う:
+  - ルール: その能力が従う規則
+  - 例: 観測可能な具体シナリオ → packet の Expected Behavior
+  - 疑問: 未確定 → packet の Open Questions / Compass へ差し戻し
+  - 切り出し: 今回やらないと決めたこと → 黙って落とさず `.intent/packets/plan.md` の Deferred 節に記録し、後続 packet の種 / Open Questions にする
+- 例から Validation（テスト/手動/型/ログ）と Rollback を導く。
+- packet は behavior-preserving / testable / rollbackable を満たす。数は改修見込みの規模に応じて可変とし、数合わせをしない（小規模なら 1 個でよい・1〜7 を緩い目安とする）。
+
+### intent-export-cc-sdd (map-cc-sdd)
+- packet 1つを cc-sdd の Project Description（凝縮）と design/tasks ヒントへ変換。
+- 入力は対象 packet と Compass の Invariants/Anti-direction に限定する。
+- tasks ヒントには必ず parent intent と invariant への参照を残す。
+
+## 適合する状況
+- 新規プロダクト/サブシステム
+- 意図が暗黙知のまま膨らんだ機能群を言語化したいとき
+- 既存プロジェクトでの汎用的な意図整理で、状況特化モード（refactor / behavior-unknown / feature-growth）が当てはまらないとき。既存システムへの機能追加が目的なら feature-growth を使う

package/templates/ja/intent/nl-spec/README.md

@@ -0,0 +1,18 @@
+# 自然言語 Spec 出力派生ビュー置き場
+
+> `/intent-to-spec` が canonical な意図（`.intent/intent-tree.md` / `.intent/intent-compass.md` など）と packet を読み、外向きに人間可読な自然言語の仕様書としてこの配下に書きます。この README 以外は **Git 非追跡（ローカル専用）** です。ここに置かれるビューは **派生（derived）であり正本ではありません**。正本は canonical な意図ファイルのままで、本ビューは生成時点での射影（スナップショット）です。
+
+## 構造
+
+```
+.intent/nl-spec/
+├── README.md         # この説明（Git 追跡対象）
+└── nl-spec.md        # /intent-to-spec が生成する自然言語 Spec 本体（非追跡・全置換で再生成）
+```
+
+## このディレクトリの性質
+
+- **派生・再生成可能**: `nl-spec.md` は `/intent-to-spec` を実行するたびに canonical な意図から**全置換**で再生成されます。手で編集しても次回実行で上書きされます（編集禁止）。
+- **正本ではない**: 設計意図の正本は canonical な `.intent/intent-tree.md` / `.intent/intent-compass.md` です。本ビューは意図を外向きに射影した**読み物（自然言語 Spec）**であり、ここを書き換えても canonical には反映されません。仕様を変えたい場合は、利用者が discover / compass の対話へ戻って意図を更新し、再度 `/intent-to-spec` を実行してください（ビューから canonical への自動の継ぎ目はありません）。
+- **Git 非追跡**: `nl-spec.md` をはじめ、この README 以外はローカル専用で Git に追跡されません（追跡対象はこの README のみ）。これによりチームでのマージ衝突や上書きによる喪失は設計上起きません。
+- **read-only な射影層 + 限定 Write**: `/intent-to-spec` は canonical な意図を変更せず（読み取りのみ）、生成物の書込み先はこの `.intent/nl-spec/` 配下に限定されます。

package/templates/ja/intent/openspec/proposal.md

@@ -0,0 +1,15 @@
+# OpenSpec Proposal 下書きテンプレ
+
+> `/intent-export-openspec` が packet ごとの下書きをこの書式で `.intent/openspec/<packetスラッグ>/proposal.md` に書き出します。このファイルは出力の書式テンプレ（見出し + 用途説明）であり、ここに具体的な内容は書きません。マッピングの正は export skill の rule（map-openspec）にあります。読み手は OpenSpec へ受け渡す利用者と、続行時に起動される `/opsx:propose` です。
+
+## Why
+
+この変更を行う理由。packet の intent / Why を写し、parent intent（この packet が仕える上位の狙い）を明示する。なぜ今この変更が必要かを OpenSpec の change-proposal が引き継げる形で述べる。
+
+## What Changes
+
+この変更で何を足す・変える・やめるか。packet の deliverables / Scope を箇条書きで列挙する。compass の Anti-direction はこの節の中で out-of-scope（やらないこと）として明示する。
+
+## Impact
+
+この変更が影響する spec / 契約と、守るべき制約。compass の Invariants を写し、normative（SHALL / MUST）で表現できるものはその形で残す。OpenSpec が生成する成果物へ invariant が取り込まれるようにする。

package/templates/ja/intent/openspec/spec-delta.md

@@ -0,0 +1,25 @@
+# OpenSpec Spec Delta 下書きテンプレ
+
+> `/intent-export-openspec` が packet の受け入れ条件を OpenSpec の delta spec ヒントとしてこの書式で `.intent/openspec/<packetスラッグ>/spec-delta.md` に書き出します。これは本体を完成させない **ヒント skeleton** です（OpenSpec 本体生成・突き合わせは `/opsx:propose` 以降に委ねる）。`### Requirement:` / `#### Scenario:` の見出し構文を正確に seed し、OpenSpec の validate に通る構造へ誘導します。振り分け規則（ADDED 既定 / 条件付き MODIFIED・REMOVED）の正は export skill の rule（map-openspec）にあります。
+
+## ADDED Requirements
+
+新たに追加する能力・振る舞い。既定では packet の受け入れ条件をすべてここに置く。
+
+### Requirement: <name>
+
+normative な要件文（SHALL / MUST）。compass の Invariants が関わる場合はその制約をここへ落とす。
+
+#### Scenario: <name>
+
+- **GIVEN** 前提
+- **WHEN** 起きること
+- **THEN** 期待する結果
+
+## MODIFIED Requirements
+
+既存の能力・振る舞いを変更する場合のみ置く（packet の Scope または compass の Anti-direction が既存能力の変更を明示参照する場合）。「変更対象の能力名 + 変更方向」のヒントに留め、突き合わせは OpenSpec 側に委ねる。
+
+## REMOVED Requirements
+
+既存の能力・振る舞いを廃止する場合のみ置く（同上の条件）。廃止対象の能力名をヒントとして示す。