intent-packets

name	intent-packets
description	Intent Tree と Intent Compass から、仕様作成または直接実装へ進む前の Packet Plan を作る。各 packet は parent intent を持ち、behavior-preserving / testable / rollbackable。実装はしない。

intent-packets Skill

Core Mission

• Success Criteria:
  • 改修見込みの規模に応じた数の packet 候補があり（数合わせをしない・小規模なら 1 個でよい・1〜7 を緩い目安とする）、各 packet が parent intent を参照している
  • 各 packet が .intent/packets/active/ 配下の個別ファイル（1 packet = 1 ファイル）として起案されている
  • 各 packet が Scope / Non-scope / Expected Behavior / Decisions / Safety(Invariants) / Validation / Evidence / Rollback / 次の進め方 を持つ（Evidence は結果が無ければ空節で保持）
  • 各 packet の ## Decisions 節で、decision-slots.md の共通コアスロット（+ mode 別差分）が4ステータス（回答済み / 未定 / 非該当 / ADR候補）のいずれかで閉じている（既定値を埋めない・黙って飛ばさない）
  • 各 packet が behavior-preserving / testable / rollbackable な粒度である
  • 既存の packet ファイルを破壊していない（差分更新案として提示している）
  • アプリケーションコードを一切変更していない

Execution Steps

Step 1: 前提を読む

• .intent/intent-tree.md と .intent/intent-compass.md を読む。どちらか無ければ「先に該当コマンドを実行」を案内して停止する。
• packets の開始時に確認する: Tree と Compass から持ち越された重要判断を、CONTRACT.md の重要判断契約に従って確認する。別セッションが既存の packet から開始する場合も、この開始時確認を省略しない。許された結果を得ていない判断があれば、根拠が示す影響範囲の packet だけを停止し、無関係な packet の起草・確認は継続する。
• 読み取り時、compass / intent-tree の確定文体に紛れた未確定動詞（想定 / 流用 / 予定 / TBD / 暫定 等）を見たら、推測で確定させず Open Questions または未定スロット（理由・再訪条件（Revisit when）併記）への変換案として提示する。確定値への昇格は利用者の確認に委ねる。既に Open Questions / Deferred / 未定スロットへ記録済みの箇所は重複変換しない。
• 引き継がれた発行ディレクトリの discovery/<スラッグ>-<rand>/mode.md（A34・discover が出力した発行名を引き継ぐ）→ 無ければ単一 .intent/mode.local.md（legacy）→ 無ければ旧 .intent/mode.md の順で mode 状態を読む（CONTRACT.md の read fallback 規約）。無ければ standard を既定とし Open Questions に告知する（停止しない）。
• .intent/packets/index.md と、既存の .intent/packets/active/ 配下の packet ファイルを読む（差分更新の基礎にする）。
• 旧 install 対応: .intent/packets/・plan.md・index.md・README.md が不在なら、skill が自ら作成してから処理を行う（scaffold の再インストールを待たない）。
• 事後起草の判別（実装が先行していた場合）: 起動の文脈や利用者の申告から「対応する Packet が無いまま実装が進んだ／完了した」ことが分かる場合は、これを通常の起草と同じ手順で扱う（事後でも Packet を起こす。実装済みであることは起草を省く理由にしない）。このとき:
  • 確定している事実（既に実装されたつなぎ込み・挙動）は what + constraints + oracle として packet ファイルに記録する。
  • まだ固定できない仕様（起動契機・閾値・判定手段など、実装に踏み切れていない／暫定で置いている決定）は、推測で埋めず、作成するpacketファイルの Open Questions または Deferred に記録する。Deferredには 未定（遅延中・再訪条件付き） と記し、再確認する条件を必ず併記する。「仕様が固定できないからPacketを作らない」は誤りであり、未確定の事項を未確定のまま記録することもPacketの役割である。
  • 起草の順序を案内する: まず本スキルで Packet を起こし（起草フェーズ）、そのあと /intent-writeback で実装の現実から得た学びを delta 経由で canonical へ戻す（実装後フェーズ）。この2つは方向が逆であり、Packet 起草を飛ばして writeback だけを行わない（フェーズ境界は writeback-protocol.md §3 を正とする）。

Step 2: モード定義のアルゴリズムを適用する

• .intent/mode.local.md（無ければ .intent/mode.md）の definition が指すモード定義を開き、Packet 分解フェーズに割り当てられた algo rule（rules/algo-*.md）を読み、適用する（standard なら rules/algo-example-mapping.md、refactor なら rules/algo-migration-slicing.md、behavior-unknown なら rules/algo-example-mapping.md + rules/algo-characterization-test.md）。例は網羅ではない。常にモード定義の表を正とする。

Step 3: Packet を分解する

• Example Mapping に従い、各 L2/L3 能力を「ルール・例・疑問・切り出し」に展開する。
• 例から Expected Behavior、Validation、Rollback を導く。
• 改修見込みの大きさに応じた数の packet にまとめる（数を目標に数合わせをしない・小規模なら 1 個でよい・1〜7 を緩い目安とする）。大きさは「触れる concern の数 × 既存境界への波及の広さ」で質的に測り、切る基準に工数見積もり等の数値を持ち込まない（切った後の packet に任意で書く見積もりは rules/packet-format.md の「見積もり」節の規律＝幅+算出根拠+実装主体のセットに従う）。各 packet に parent intent（L0/L1/L2/L3 への参照）を必ず持たせる。
• 各 packet を .intent/packets/active/<packet_id>.md の個別ファイルとして起案する。ID 付与・frontmatter キーの記入・本文セクション構成（## Decisions 節・## Evidence 節を含む）は rules/packet-format.md を読み、従う（キー一覧・値域は正本が単一の真実源）。
• updated_at の打刻（書き手の責務）: packet ファイルを書き込んだら、その更新時点を frontmatter の updated_at（ISO 8601）に記録する。新規作成時は created_at と同一時点を updated_at に記入し、既存 packet の内容を変更したときはその時点を updated_at に更新する。内容変更を伴わない再実行では updated_at を変えない（冪等。無変更で打刻しない）。日時は created_at と同じくシェルの date で取得する。日時を取得できない場合は推測の日付を書かず、その旨を報告する。打刻は書き手（本スキル）の責務であり、read-only の検証層（intent-validate）には持たせない。
• rules/decision-slots.md を読み、completeness schema のスロットを各 packet の ## Decisions 節へ播く（スロット定義・値域・ID の正本は decision-slots.md。本節はその投影）。
  • 共通コアスロット（全モードで播く8 ID）を全 packet に播き、.intent/mode.local.md（無ければ .intent/mode.md）の mode に応じた差分スロットを加算する（standard / refactor / behavior-unknown / feature-growth）。スロット定義は decision-slots.md の表が正であり、SKILL 本体にハードコードしない。
  • 各スロットを4ステータス（回答済み / 未定 / 非該当 / ADR候補へ送る）のいずれかで必ず閉じる（「黙って飛ばす」を構造的に防ぐ）。「妥当な既定値」「推奨値」を埋めない（anchoring 回避）。スロットの該当性・値を成果物から推論・自動充填しない（人が宣言する）。
  • discover が tree L3 直下に「決定が要る点（④）」として記録した posture を反映する（具体値が無くても、当該スロットの存在は閉じ対象にする）。
  • 既存成果物が既にカバーするスロットは作り直さず、その閉じ先を参照する（例: decision-fit-criterion は ## Validation、decision-exception-flow は ## Expected Behavior、decision-characterization は algo-characterization-test.md）。## Decisions には値を二重に書かず「既存節で閉じている」旨を宣言する（重複定義しない）。
  • 未定 のスロットは理由・downstream への注意書き・再訪条件（Revisit when）を併記する。非該当 のスロットは該当しない根拠を併記し、黙って落とさない。
• 投与量の仕分け（前倒し / 遅延）: 各決定を「人間が前倒しで固定する（visible rule）」か「エージェントに委譲して遅延する（hidden / discretion）」かに仕分ける。
  • 前倒し5基準（不可逆・後からの変更が高コスト／複数モジュール・外部利用者へ波及（外部影響）／曖昧だと受入テスト・観測が弱くなる（受入オラクル）／セキュリティ・法規制の床／複数 packet を拘束する）のいずれかに該当する決定はする。2つ以上を満たす architecture-significant な決定は ADR 候補として compass の Decision Rules へ送る。

Step 4: 終端判定・優先順位・分割を提示する

• 分解の終端判定（複合停止条件）: 各 packet が次の6条件をすべて満たした時点で、それ以上の分割を止める。①一 packet が一つの主要 concern に対応する ②受入基準が観測可能な入力・条件・期待結果に落ちている ③解法空間の境界（固定 / 裁量 / 禁止）が明示されている ④cheap-to-reverse（後戻りが安い） ⑤トレース先が明確（parent intent / spec_refs を辿れる） ⑥単体完結: packet 単体の done が、利用者/呼び出し側から見て中途半端でない一貫した挙動の区切りになっている（half-done な振る舞いの done を作らない）。⑥は④とは別の独立条件である — ④は「作る側のロールバック安全性（中間状態が戻せる）」、⑥は「呼び出し側から見た完了形の意味的一貫性」で観測の主体が違う（④へ吸収しない）。満たすまでは粗い、満たした後の細分化は過剰。
• 検証可能性の床は discriminative testability とする: 単に「テストが書ける（testability）」では足りず、「誤った実装を落とせるオラクルがある」ことを満たす。落とせるオラクルが見当たらない packet は受入基準が未成熟と判定し、Validation / Expected Behavior を観測可能な形へ詰め直す。
• 受入基準が複数の concern または複数の品質属性トレードオフをまたぐ packet は「まだ粗い」と判定し、concern 単位への分割を提案する（一 packet 一 concern へ寄せる）。
• 作業単位を実装手順（how の完全指定）まで細分化しない。what + constraints + oracle（何を / 境界制約 / 誤実装を落とすオラクル）の指定に留め、規則の内側はエージェントの裁量に委ねる。
• 既存の粒度規律（behavior-preserving / testable / rollbackable・数は規模に応じて可変で 1〜7 を緩い目安・数合わせをしない）を維持し、「一 packet = 一 concern」と⑥単体完結を終端判定に明示的に用いる。
• packet の優先順位を示す。
• rules/walking-skeleton.md を読み、rule の適用条件に従って適用する。
• rules/first-packet.md を読み、適用する。
• rules/journey-plan.md を読み、適用する（複数 packet 案件でのみ、ジャーニー〔複数 packet を束ねる単位〕の起案を利用者に提案する。単発 packet 案件・journeys/ の規約が無い環境では発火せず従来どおり）。
• 大きすぎる packet には分割案を提示する。
• 利用者確認を得た packet の state を draft から ready（着手可・依存解決済み）へ宣言的に更新し、index.md を再生成する（値域・再生成手順は rules/packet-format.md 参照）。ただし、重要判断に当たる未定スロットが残る packet は ready にしない。対象 packet と、その判断が影響する根拠を利用者へ提示し、decision-slots.md が定める許された結果を得てから、影響する成果物を再確認して影響範囲だけを再開する。重要判断ではない未定スロットは、それだけを理由に ready 化や工程進行を止めない。実装中/検証待ち/完了への進行（implementing/verifying/done）は人または検査ゲートに基づく後続の宣言で行う。
• 起草の割当宣言を消す（起草の終わり＝packet が生まれた瞬間・DR164/INV91）: packet を起こしたら、引き継いだ発行ディレクトリ（issue_dir）に対応する起草の宣言 .intent/assignments/discovery-<発行ディレクトリ名>-<session-rand>.md を、このセッション自身が削除する（起草の占有はここで役目を終える）。宣言が無ければ何もしない（既に消えている・そもそも作られていない＝冪等・エラーにしない）。.intent/assignments/ が不在のときも何もしない（後方互換）。経過日数などの機械閾値で自動削除しない（契機は工程の節目だけ・放置された宣言の掃除は読み手の観測に委ねる＝INV91・既存契約のまま）。1つの起草から複数 packet が生まれても、宣言は packet ごとへ引き継がない（起草の宣言と実装の着手宣言は別レイヤ。実装の宣言は着手するセッションが別途出す）。
• supersede: 計画見直しで既存 packet を後続 packet で置き換える場合、後続 packet の起案と同時に旧 packet へ superseded_by を記入し、archive/<年>/ へ移動して index を再生成する。
• in-flight ガード: 置換対象が export 済み（ に行あり）かつ終端状態（promoted / closed）の delta が無い場合、実装進行中の可能性を警告し、利用者確認なしに移動しない。

Output Description

読み手: 作業単位を切り出して実装フローへ渡す人間開発者。 この出力で最初に掴ませること: 「最初に着手すべき packet はこれ（＝次に export すべき packet）。次の一手は案件種別に応じた出口」。packet 一覧・優先順位・分割案はその根拠となる詳細。

出力は結論（着手 packet と次のコマンド）を先頭に立てる。

• 最初に着手すべき packet（先頭・理由付き）: 推薦 packet ＝ 次に export すべき packet（同一）。なぜそれを先頭にするかの理由を添える。
• 次の一手（1行・案件種別で分岐）: rules/export-route.md（出口判定レーン）を read-only で適用し、案件種別から出口を選んで提示する。cc-sdd を無条件で推さない（決め打ち禁止）:
  • target format（.intent/mode.local.md の format 行）が有効値で明示されていれば、その出口を推薦する: cc-sdd → /intent-export-cc-sdd / openspec → /intent-export-openspec / speckit → /intent-export-speckit / to-spec → /intent-to-spec / direct → 直接実装（出口コマンドなし）。
  • format 未指定（不在/プレースホルダ/値域外）なら、mode（non-code / standard 系）と下流 spec ツールの導入目印（.kiro/ / repo 直下 openspec/ / repo 直下 .specify/ の有無・read-only 観測）から推論して候補を提示する。実装案件では導入済みのツールを先に・未導入は「導入が要る」注記付きで後ろに並べ、各出口に案件適合の一言を添える。non-code は /intent-to-spec を候補筆頭に置く。
  • 導入状況は観測と注記であって gate ではない（未導入を候補から消さない・止めない）。複数が導入済みでも優先順位を発明せず候補列挙のまま人が選ぶ。一意に決まらないときも単一の出口に畳まない（出口は利用者の意図次第・目印/並び/注記/適合一言の規約と判定の詳細は rules/export-route.md が単一正本＝本ファイルへ複製しない）。
• 詳細: .intent/packets/active/ 配下の packet ファイル群（新規起案・既存への差分更新案。規模に応じた数の packet・1〜7 が緩い目安、各 parent intent 付き）、.intent/packets/plan.md と .intent/packets/index.md の更新、packet の優先順位、大きすぎる packet の分割案。
• 引き継ぎの案内（任意・末尾1行・INV82-(2)/DR143）: packets は工程の切れ目なので、出力の末尾に「このまま実装（出口）へ続けることも、ここで新しいセッションへ引き継ぐこともできます」という趣旨の read-only の案内を1行だけ添えてよい（任意・結論〔選択肢〕を先に置く＝bluf）。ただし添えるのは「文脈が長い」という定性的な自己感覚があるときだけ（工程の切れ目 × 長さの自覚の AND・短いセッションでは黙る）。さらに、出す前に損得を自問する（DR159）: (1) 残作業の性質＝設計判断が残るか・書いてある通りにやるだけか (2) 引き継ぎで失われるセッション固有の暗黙知の量 (3) この切れ目の自然さ。「引き継がない方が得」と見積もったら推奨せず黙る（または「続ける方が得」と一言添える）。見積もれないときも黙る側に倒す。推奨するときは見積もりの一言（定性・数値なし）を案内に添える。会話ログ・トークン量は読まず数値も出さない（INV82-(2)・INV22 の制約）。現在の agent 面で互換確認済みの handoff-bridge skill が利用できる場合だけ、「handoff-bridge で引き継ぎ文書を作る」と依頼できる旨を案内する。未配置・非互換・確認失敗の場合は生成の案内を出さないで静かに縮退し、内部 generator や overview へ fallback しない。自動でセッションを切らず・ブリーフを勝手に書き出さず・「続ける」を矯正しない（次の一手＝出口の案内は変えない）。

報告の平易さ点検（利用者向け報告・出力直前・共通）

利用者へ向けた報告（進捗・完了・確認事項の提示。ターン末尾の要約を含む）を出す直前に、次を点検する（INV105・DR208）。対象は利用者向けの報告文だけで、内部の記録（.intent/ 配下の canonical・ログ）の書き方には適用しない。

• 内部文書の文をそのまま転写しない: 直前に読んだ・書いた内部成果物（tree・compass・packet・Open Questions）の文面は内部の語彙で書かれている。報告では、その内容を初見の読み手に通じる言葉で言い直す（事実・意味は変えない）。
• 識別子を本文の主語にしない: 確認事項・作業単位を示すときは、まず「何を・なぜ」が単体で通じる一文を置き、識別子（Open Question 番号・packet 名・記号・工程名）はその後ろに参照として添える（例: 「…を確かめてから始めてください（整理番号: OQ-xxx-1）」）。平易化のために識別子・記録への参照を削らない（記録へ辿れなくなる）。
• 通じるかの合図: 1文に未説明の内部語が3つ以上並んだら詰め込みすぎの合図（機械カウントではなく意味の読みで）。単体で通じなければ、平易に書き直してから出す（事実・意味は変えない）。
• 比喩・曖昧な言い方だけで意味を渡さない: 報告の土台は正確さ（意味が一意に読める記述。平易さはそれを保ったまま易しく書く手段）。基準のない程度語（「かなり」「うまく」等）だけで結果を伝えず、観測できる事実で書く。比喩を使うなら直後に正確な言い直しを必ず併記する（確立された専門用語・世間の意味のままの一般語は無理に開かない）。
• この点検は事後の記録と対で働く（予防だけで閉じない）: 報告が通じなかった実例は、drift-watch が on のとき drift-log へ症例として残し、次の予防に使う。

Safety & Fallback

• Intent Tree / Compass が無ければ停止して該当コマンドを案内する。
• mode.md 不在は停止せず standard 既定で続行し告知する。
• packet を実装タスクに落としすぎない（Issue より上位、spec より手前）。
• packet ファイルは削除しない（移動のみ）。
• シェルコマンドの用途は、日時取得・.intent/packets/ 配下のディレクトリ作成（mkdir）と移動に限る（アプリケーションコードを変更しない invariant は維持）。
• アプリケーションコードは変更しない。