decision-record

セッション中に成立した「合意」と、結論が出ないまま残った「未決論点」を add_decisions で記録する。判断基準・品質基準をここに集約しているため、add_decisions を呼ぶ前に本スキルの判定を必ず通す。

適用範囲

このスキルは初回 load 時に発動するが、判断基準は本セッション内のすべての後続ターンに適用される。以降のターンで下記の合意条件・未決条件に該当する出来事が起きたら、明示的に skill を再発動せずとも add_decisions を呼ぶこと。

対象

• add_decisions（決定事項・未決論点の記録）

add_logs（経緯）/ add_material（成果物）は本スキルの案内対象外。両者は recording skill が担当する。

合意判定基準

以下のいずれかに該当する場合のみ、合意成立の decision として記録する。

• ユーザーが「OK」「それでいこう」「その方針で」「了解」「いいね」等で明示的に承認した
• AI の提案に対してユーザーの明示的な同意があった
• 「〜で決定」「〜に決めた」等、決定を宣言する表現があった

ユーザー合意のないものを decision として記録しない。片方（AI）だけが結論だと思っている内容や、まだ検討中の案は次項の未決論点として扱う。

未決論点の記録: [議論中]

結論が出ていない論点も、合意なしに記録してよい（決定の記録ではなく、議論の状態の記録だから）。

• 対象: 議論に出たが結論が出ていない論点、複数案が並んだまま収束していない検討事項
• 書き方: decision 本文の先頭に [議論中] プレフィックスを付ける。reason には検討中の選択肢と、どこまで詰まったかを書く
• 発動タイミング: その論点のまま話題が移る、またはセッションが終わりに近づいたタイミング
• 待っているアクティビティの紐付け: その論点が決まるのを待って止まっているアクティビティがあれば、add_relation("decision", <議論中のdecisionのid>, [{"type": "activity", "ids": [<アクティビティid>]}]) で紐付ける（add_decisions に related 引数は無い）。以後、[議論中] の decision に紐づいたアクティビティは「その決着を待っている」と読む（結論の decision から問いへ supersedes を張って決着させる）

作業・話題が途中で終わった状態そのものの追跡は主にアクティビティ側の関心事であり、セッション終了時の一括記録（sync-memory）が [未完] を含めた整理を扱う。本スキルが扱うのは議論の論点であり、そこには [議論中] を使う。

呼び出し時の品質基準

• title: 付与を強く推奨する。check-in・timeline・search 等の一覧表示で decision 本文の代わりに見出しとして使われ、可読性が大きく上がる。文字数上限は add_decisions のdocstringに従う。tags に layer:direction を含める場合は title が必須になる（省略・空文字はエラー）
• topic_id: 必須。適切な topic が無ければ、まず add_topic で作成してから紐づける
• tags: domain: を必ず付け、内容を表す素タグも追加する。省略した場合は topic のタグを継承するが、内容が topic より具体的なら明示的に追加する
• reason: 「なぜそう決めたか」を書く。decision（結論）と reason（理由）を混ぜずに分離する
• PRの表記: PRに言及するときは owner/repo#123 のようにリポジトリ名を付ける。番号だけでは、複数リポジトリを扱う記録から読み手がどのPRか解決できない

precedent定型節（任意）

reason の末尾には、任意で 却下案: / 適用条件: / 適用外: / 検証: / 隣接確認: の5種の定型節を書ける。書くと add_decisions のレスポンスに precedent として構造化されて返る（読み出し面 get_decisions / get_by_ids にも反映される）。

書式の正本は docs/precedent-format.md である（パーサ実装 src/services/precedent_pure.py と一致させる運用）。配布先のCWDではdocs/配下のパスが解決しないため、本スキル同梱の references/precedent-format.md に同一内容を保持している（内容の正誤に食い違いがあれば整合性テストで検知する）。定型節を書く前に references/precedent-format.md の2章（書式）を参照すること。

呼び出し時に外してはならない運用ルールのみ以下に挙げる:

• 節はすべて任意。「該当なし」を埋めるための空項目・ダミー項目は書かない（却下案が無い裁定に却下案節は不要）
• 実装状態（実装済み/未実装）は本文に書かない。状態は検証行の有無で読み手が判定する

呼び出し後の確認手順: 定型節を書いたら、レスポンスの precedent（rejected_alternatives 件数・scope bool・verification_anchors・adjacent_check）を見て、書いたつもりの節が反映されているか確認する。反映されていない、または precedent_warnings が付いている場合は書式ゆれの可能性がある。よくある原因: 行頭に無い、コロンが無い、箇条書きの - が無い、references/precedent-format.md 4章の近似見出し（却下例/棄却案/不採用案/適用範囲/対象外/検証済み/rejected/scope/近接確認/隣接チェック/周辺確認）を正規の見出しと誤って使った、等。precedent_warnings は soft validation であり、warning があっても decision 自体は作成済みで拒否はされない。warning は次回以降の書式修正の参考にする。

隣接確認:節（intent:design タグ推奨）

tags に intent:design を含む decision では 隣接確認: 節の記入を推奨する。書式は却下案と同じ「見出し行のみ + - 軸名: 内容 の箇条書き」で、対象は以下の2軸:

• 実行時: 誰が起動・デプロイする主体か
• 関連既決との整合: 既存の decision と矛盾・前提依存はないか

節が無くても記録は拒否されない（soft validation）が、precedent_warnings に intent:design decision missing '隣接確認:' section という警告が付く。intent:design を含まない decision には適用されない。

決定記録の直後にgoalの条件を満たす場合

add_decisions で記録した内容が、手元のgoalブロックの未終端の条件を満たすなら、続けて update_goal を呼ぶ。changes に {"op": "set", "id": <条件id>, "state": "satisfied", "note": "..."} を積み、同じ changes に {"op": "edit", "id": <条件id>, "bound": {"type": "decision", "id": <この決定のid>}} を並べて束縛する。

update_goal の応答の goal.label が judge_ready（全条件が終端し判定待ち）になったら、そのまま持ち越さずその場で判定する。goal.open_questions に未決があれば畳むか1ターン聞き、そのうえで goal.terminal の充足が1件以上あれば judge_goal(goal_id, verdict="achieved", note=...)、0件なら judge_goal(goal_id, verdict="failed", note=理由) を呼ぶ。人間の判断は待たず、判定したことの報告もしない。

この判定の分岐（open_questionsの扱いからjudge_goalの呼び分けまで）はcheck-inの「goalフィールドの扱い」節を正本とする。判定条件が変わる場合はそちらを確認する。

[議論中] の論点を結論の decision で決着させる場合は書き方が違う。決着する論点自体が条件の束縛先なら、結論の decision から問いの decision へ add_relation(relation_type="supersedes") で置き換えの関係を張る（既存の運用）だけでよく、update_goal は呼ばない（したがって上記の判定待ちの確認も発生しない）。この置き換えが張られた時点で、束縛した条件は次の読み出しから済と読まれる。決着前に条件を satisfied に書き換えると、束縛先がまだ済でないため崩れとして扱われる。

矛盾・重複への対処

add_decisions のレスポンストップレベルには related_decisions（呼び出し全体で同 topic 内の類似 decision 上位3件）が付く。既存 decision と矛盾する、または同一内容の重複だと気づいたら、その場で report_signal(kind="contradiction") を呼んで報告する。retract や supersede の判断そのものは本スキルの対象外。

tags に layer:direction を含めた場合はレスポンスに existing_direction_decisions（同 domain の有効な方向性 decision 全件）と direction_note も付く。既存の方向性判断と食い違う場合は、そのまま並存させるかの判断が必要になる。

recording との境界

• recording: セッション中の「経緯」（add_logs）と「成果物」（add_material）を担当。合意が不要な記録
• decision-record（本スキル）: 「合意」と「未決論点」（add_decisions）を担当。合意の有無を判定してから記録する

同じ出来事から log と decision の両方が生まれることがある（例: 3案比較の末に1案採択した場合、比較の経緯は recording が log として残し、採択という結論は本スキルが decision として残す）。両方に該当する場合はどちらもスキップしない。

sync-memory との関係

sync-memory はセッション終了前に transcript 全体を解析し、decision を含む記録漏れを一括で拾う安全網である。本スキルがセッション中に適切なタイミングで発動していれば、sync-memory 側の decision 記録ステップで新たに見つかる内容は少なくなるはずだが、本スキルは「セッション中の見逃し低減」が役割であり、完全網羅を保証するものではない。判断に迷ったら記録する側に倒す。

sync-memory のステップ2（未記録区間の記録）には、本スキルと同内容の要約（決定事項の判定基準・[議論中] の記録基準）が意図的にインラインで残っている。sync-memory は本スキルの発動を前提とせず単体で完結する必要があるためであり（docs/recording-taxonomy.md が採る「各 skill 本文は自己完結」の方針と同じ）、重複自体は許容する。ただし判定基準の記述が食い違った場合は、本スキル（decision-record）の「合意判定基準」「未決論点の記録: [議論中]」節を正本とする。