rule-placement

一般化ルールの配信先をfull評価で決める。remember skillの判定木はこの評価体系から導出された高速表であり、本skillはその一般解。分解 → 4軸評価 → 承認要否の仕分け → 承認不要分の実行と報告 → 配置計画の提示（承認が要る分のみ） → ユーザー確認 → 実行、の順で進める。

• 入力: メタask裁定のanswer_body、またはremember/forget/auditから持ち込まれたルール群
• 出力: 承認が要る配置だけの配置計画表（ルール × 配置先 × 根拠となる軸の値）。承認が要らない配置は先に実行し、まとめて1行で報告する

発動契機

以下で発動する。

• メタask（kind="meta"）の裁定をtriage_askでpromoteする直前（必須）
• remember skillの判定木の末端で迷った場合
• 1つの裁定・依頼に性質の異なる複数ルールが混ざっている場合
• forget/audit中に既存配置の再配置を検討する場合
• remember skillの再発の手順で、照合できない再発の行を追記し（再発1回）格上げを検討する場合

以下では発動しない。

• remember skillのfast pathで判定できる日常の単純な「覚えて」
• 議論の合意事実の記録（decision-record skillの担当）

Step 0: 分解する

裁定・依頼の本文を読み、撤回単位ごとにルールへ切り出す。切り出し基準は「このルールだけを撤回したくなる場面があるか」。あるなら別ルール。人間の裁定は自然言語の一続きで返るため、性質の異なる複数ルールが1本に同居しているのが通常である（1件の裁定が7ルール・5配置先に分かれた実例がある）。以降のStepは各ルールに対して個別に実行する。

Step 1: 配信するか（0次分岐）

判定	出口
一回性の判断で、同型の再来が想定できない	何もしない（askのanswer_bodyに残っていれば十分）
将来の別用途の素材で、今のエージェントの振る舞いを変えない	add_materialで保存のみ（配信経路に乗せない）
今後のエージェントの振る舞いを変える	Step 2へ

Step 2: 4軸を評価する

軸1: 契機 — 何が起きたらこのルールが要るか、その出来事に名前を付けられるか

上から順に（具体的な契機から）試し、どうしても名指しできないものだけを「無契機」に落とす。「重要だから常時」は契機の名指しの失敗であり、重要度は軸3で扱う。

値	見分けの問い
自覚的な迷い	エージェントが「これでいいのか」と詰まって検索・確認する場面か
定型手順の実行	「ある決まった作業を始めた瞬間」と言い切れ、対応するskillが実在するか
字面で照合できる瞬間	人間の発話・ツール失敗のエラー文・実行直前の引数のどれかの字面で、validatorを通る条件式（tool一致＋regex/len_gt、最大3要素）を書けるか
ツール呼び出し	「あるツールを呼ぼうとした瞬間」と言い切れるか
作業単位	特定のactivity/topicに取り組む間だけ要り、終われば不要か
ファイル文脈	「特定のファイル/パスパターンに触れる時」と言い切れるか
タグ文脈	要る場面に共通して付くタグ（domain:等）を1つ挙げられるか
無契機	上のどれも名指しできない

作業単位の枝は寿命も判定するので、判定木では先に切る。

軸2: 型 — このルールを1文で書くとどの文型か

値	文型	罠
無条件規範	「〜する/〜しない」	「XをやるならYを先に」という順序制約は手順ではなくこれ。例外条項付きの禁止もこれ（例外は規範本文に含める）
条件付き判断基準	「〜な状態なら〜してよい」	適用条件と適用外を書き分けられ、隣接文脈への誤適用に害がある型のみ。判断そのものを条件に委ねる型を指す
手順	「まず〜、次に〜」	順序に意味があり、1ステップ抜き出すと意味を失うもの
事実・参照	「〜である/〜にある」	行動を指示しない知識

軸3: リスク — 見逃しコスト × 無自覚性

• 見逃しコスト: 高 = 外部にpushされる・データが消える・他セッションを巻き込む・不可逆 / 中 = やり直しに人手と時間がかかるが復旧可能 / 低 = その場の修正で済む
• 無自覚性: 自覚あり = 踏む直前に立ち止まる型（pullでも届く）/ 無自覚 = 良かれと思って・ついでに踏む型（pushでないと届かない）。過去に「本人が問題と思わず踏んだ」事故記録があれば無自覚と判定してよい

軸4: 改訂見込み — 半年後も同じ文面か

高 = 例外条項が増えそう・数値/閾値/パス/ツール名を含む・実装の現状を記述している / 中 = 方針は安定、表現調整はありうる / 低 = 原理レベルで書き換える理由が想像できない。初回裁定は「高」と見るのが安全側（同型N件が根拠なら、N+1件目で例外が見つかる余地が残る）。

Step 3: 一次候補を引く（軸1 × 軸2）

軸1＼軸2	無条件規範	条件付き判断基準	手順	事実・参照
無契機	habits always（100字未満なら）/ rules	矛盾のサイン（エッジ表E1へ）	rules（順序制約だけ切り出す）	habits intelligently / auto-memory（重要度低い）/ ユーザーCLAUDE.md（重要度高い）
タグ文脈	tag-notes	tag-notes（要旨+参照）＋判例decision（定型節を持てる判例側が正）	tag-notes（1行ポインタ。全文の正典はコード/docs/資材）	tag-notes（1行ポインタが既定。そのタグ固有の環境知識のみ全文可）
ファイル文脈	rules（パス付き）	rules（パス付き、要旨+参照）＋判例decision（定型節を持てる判例側が正）	rules（パス付き）	rules（パス付き）
作業単位	pin	pin（判例decisionをpinで指す）	pin（手順materialをpinで指す）	pin
字面で照合できる瞬間	フィードバックエントリ（実行直前ならblock）	フィードバックエントリ（要旨+参照）＋判例decision	フィードバックエントリ（bodyに参照先）	フィードバックエントリ
ツール呼び出し	docstring	docstring（要旨+参照）＋判例decision	docstring	docstring
定型手順の実行	skill	skill（要旨+参照）＋判例decision	skill	skill
自覚的な迷い	型の再検査（迷いが発生するなら無条件ではない）	判例decision	判例decision＋material	判例decision

ツール呼び出し→docstringは、ツールの契約そのものに限る（それ以外は上の「字面で照合できる瞬間」の行を使う）。

条件付き判断基準の複合配置（「X＋判例decision」のセル）はすべて同じ規則の適用である: 全文の正は定型節を持てる判例decision側に置き、契機側の経路には要旨と判例への参照を書く。ファイル文脈のrules配置は、注入自体はセッション起動時の常時pushであり、パスは適用判断のスコープ注記である（発火条件ではない）。

タグ文脈×手順・事実参照のセルは、tag-notes自体には全文を置かない。demote_tag_notesが正典として持つ記述規約（教訓・落とし穴と環境知識のみ全文、仕様スナップショット・運用手順・歴史記録は1行ポインタ、状態・進行ジャーナルは0行）に従う。

Step 4: 軸3で強度を補正する

状況	補正
一次候補がpull系（判例decision / habits intelligently）で、軸3が高×無自覚	push系へ格上げ。契機を名指しできるならその契機のpush経路（tag-notes/pin/docstring）、できないなら常時push（habits always / rules）
一次候補が常時pushで、軸3が低	降格を検討。常時枠は最も高価な資源であり、契機の名指しをやり直す
一次候補がtag-notesで、軸3が高	pinへの格上げを検討（tag-notesはセッション内初回のみ、pinは毎check_in再配達）
契機の字面が照合できる	フィードバックエントリを格上げ先にする。実行直前の引数で照合でき、リスクが高いならblockを最上位にする

「迷ったら弱い経路（判例decision）へ」という既定は軸3が中以下のときのみ使える。高×無自覚のルールは、契機を名指しできなくても常時pushへ置く。pull経路が実際には引かれていなかった実測があるため、高リスクをpull任せにしない。

Step 5: 軸4と容量で除外する

状況	対応
一次候補がskill / docstring / server instructionsで、軸4が高	不可。安定するまでtag-notesまたは判例decisionで運用し、改訂が止まってからPR経路へ移す。移動時に元の配置を撤回する（両方に残さない）
一次候補がhabits alwaysで、100字未満に収まらない	rulesへ。撤回・監査が手動になる負債を配置台帳に明記する
一次候補がhabits alwaysで、alwaysプールに空きがない	既存always habitの降格とセットで検討。降格候補が無ければrulesへ（昇格ゲートと容量の実装値はhabit_service/configを参照）
改訂見込みが高く、ツールを契機とするルール	docstringではなくフィードバックエントリで運用する（実行直前はblockのみ）

経路カタログ（判定の参照用）

経路	発火点	確実性	改訂コスト	向く型
rules	セッション起動時に全文注入	最高（push常時）	ファイル編集で即時。ただしDB外で監査対象から漏れやすい。パス付き見出しでファイルスコープを表現する慣行がある（適用判断は本文の対象パス記述で行う）	全型
habits always層	同上（投影ファイル経由）	最高（push常時）	ツールで即時	無条件規範のみ（1件100字未満）
habits intelligently層	タイトルのみ投影、全文はon-demand	低（pull。引かれない実測あり）	ツールで即時	弱い行儀
auto-memory	索引が文脈に見え、本文はpullで読む	低（pull）	ファイル編集で即時	重要度の低い事実・tips
tag-notes	タグに触れるツール呼び出し時（セッション内初回のみ）	高（push契機付き）	全文置換で即時（天井超過時の縮小はdemote_tag_notesでセクション単位に退避）	全型（ただし全文可は教訓・落とし穴と環境知識のみ。手順・仕様・歴史は1行ポインタ、状態ジャーナルは不可）
pin	pin元へのcheck_inのたび毎回、指す先の本文ごと（ただしpinned合計が全体予算の枠を超えると小さい順に優先され、溢れた分は先頭を残して切られポインタが付く縮退が起きる）	高（push契機付き）	ツールで即時	全型（既存エンティティを指す）
フィードバックエントリ	人間の発話・ツール失敗・実行直前の字面が一致したとき（実行直前はblockのみ）	高（契機つきpush）。ただし同時に届くのは最大3件で、idの若い順に打ち切るため、後から作ったものほど落ちやすい	ツールですぐ直せる	本文だけで意味が通る100字の要旨。どの型でもよい
判例decision	search / pull_precedents / add_ask時の類似判例同梱	中（pull。add_ask同梱は強制発火点）	supersedeで置換	条件付き判断基準（定型節の書式は本スキル同梱の references/precedent-format.md）
skill	そのskillの発動場面	中（発動条件の記述精度に従属）	PR+デプロイ	手順
ツールdocstring	ツール呼び出しの瞬間	高（push。契機が最も鋭い）	PR+デプロイ	短文の規範・判断基準
server instructions	MCP接続中の全セッションに常時	最高（push常時）	PR+デプロイ	無条件規範の要約

エッジケース

状況	扱い
E1: 無契機なのに条件付き判断基準	矛盾のサイン。条件の成立を判定する場面が契機になるはずで、名指しし直す。出てこないなら条件節が飾りで実質は無条件規範であることを疑う
E2: 契機は鋭いが、その契機を持つ経路が無い（Bash実行の瞬間等）	字面で照合できるならフィードバックエントリ。実行直前はblockに値するときだけ。照合できなければ従来どおり（軸3が高なら常時push（rules）、低〜中なら判例decisionでpull任せ）。新規の配信機構は提案しない
E3: 複数の契機に等しく該当する	分解を疑う。分解できないなら狭い契機を採り、広い方は参照で繋ぐ
E4: 既存の配置物と同趣旨がある	新規配置せず既存へ合流する。重複配信は撤回時に片方が残る事故を生む
E5: 判定に確信が持てない	既定は判例decision（誤配置の害が最小で後から昇格できる）。ただし軸3が高×無自覚なら使わない。確信度が低いことをreasonの適用条件節に残し、再来時に見直す
E6: 裁定が「今は決めない」型	配信しない。[議論中]decisionとして残す

実行

1. 各配置を承認要否で仕分ける。rules・habits・CLAUDE.md・判例decision・新しいdecisionは承認が要る。フィードバックエントリ（ノートを含む）・auto-memory・tag-notes・pinは承認が要らない
2. 承認が要らない配置は、各配置の実行前に配置先の既存内容に同趣旨の記述が無いか確認したうえで（あれば合流。この確認が中断からの再実行時の冪等性も兼ねる）、先に実行する。実行し終えたら、まとめて1行で報告する
3. 承認が要る配置だけを配置計画表（ルール要約 × 配置先 × 根拠となる軸の値）にまとめ、ユーザーに提示して確認を取る
4. 確認が取れた配置を、既存内容の合流確認を経て実行する。即時反映経路（habits / tag-notes / pin / 判例decision / rules / CLAUDE.md / フィードバックエントリ）はその場で実行する。PR経路（skill / docstring / server instructions）が結論になった場合は、その場で書かず実装タスクとして切り出しユーザーに委ねる
5. メタask裁定の発効の場合は、配置完了後にtriage_askのpromoteで締める（次節）。promote自体は、個々の配置の承認要否によらず必ずユーザーの確認を挟む

メタask発効時のtriage_ask接続

kind="meta"のaskをpromoteする場合:

• 配置の実行を先に済ませ、triage_ask(action="promote")を最後に呼ぶ。promoteが発効のコミットに相当する（先にpromoteすると、中断時に配置漏れがpromoted表示の裏に沈黙する）
• promoteで生成するdecisionは「発効の裁定記録」1件とする
  • decision: 発効した一般化ルールの型（「◯◯型の問いは今後、判例に従って自己裁定してよい」等）
  • reason: 裁定の根拠（判例N件の一貫性等）に続けて配置台帳を書き、そのあとに定型節（適用条件:等）を置く。台帳は定型節より前に置く（定型節の後ろに置くと箇条書きが直前の節の項目として解釈される）

    配置:
    - <ルール要約> → <配置先>（<識別子またはパス>）
    - <ルール要約> → 非配信（material保存のみ）
    

• 個別ルールのうち判例decision行きのものは、promote前にadd_decisionsで個別に作成し、そのIDを台帳に記載する
• rules / CLAUDE.mdなどDB外への配置は台帳に必ずパスを残す（forget/auditの棚卸しはこの台帳を手がかりにする）
• dismissする場合は現行運用のまま（本skillの配置フローは通らない）