Skip to content
cccskills
FreePublished on GitHub

rule-placement

一般化ルール(今後の振る舞いを変える規範・判断基準・手順)をどの配信経路に置くか4軸で判定する。メタaskの裁定をpromoteする直前、rememberの判定木で迷ったとき、性質の違う複数ルールが混ざるときに発動。

The English summary is being prepared. Showing the original description.

isizono/calm4 stars(GitHub 4 + cccskills 0)

Run score Not tested

See how to install

Files included (2)

  • SKILL.md16.8 KB
  • references/precedent-format.md9.4 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

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-notestag-notes(要旨+参照)+判例decision(定型節を持てる判例側が正)tag-notes(1行ポインタ。全文の正典はコード/docs/資材)tag-notes(1行ポインタが既定。そのタグ固有の環境知識のみ全文可)
ファイル文脈rules(パス付き)rules(パス付き、要旨+参照)+判例decision(定型節を持てる判例側が正)rules(パス付き)rules(パス付き)
作業単位pinpin(判例decisionをpinで指す)pin(手順materialをpinで指す)pin
字面で照合できる瞬間フィードバックエントリ(実行直前ならblock)フィードバックエントリ(要旨+参照)+判例decisionフィードバックエントリ(bodyに参照先)フィードバックエントリ
ツール呼び出しdocstringdocstring(要旨+参照)+判例decisiondocstringdocstring
定型手順の実行skillskill(要旨+参照)+判例decisionskillskill
自覚的な迷い型の再検査(迷いが発生するなら無条件ではない)判例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行ポインタ、状態ジャーナルは不可)
pinpin元へのcheck_inのたび毎回、指す先の本文ごと(ただしpinned合計が全体予算の枠を超えると小さい順に優先され、溢れた分は先頭を残して切られポインタが付く縮退が起きる)高(push契機付き)ツールで即時全型(既存エンティティを指す)
フィードバックエントリ人間の発話・ツール失敗・実行直前の字面が一致したとき(実行直前はblockのみ)高(契機つきpush)。ただし同時に届くのは最大3件で、idの若い順に打ち切るため、後から作ったものほど落ちやすいツールですぐ直せる本文だけで意味が通る100字の要旨。どの型でもよい
判例decisionsearch / pull_precedents / add_ask時の類似判例同梱中(pull。add_ask同梱は強制発火点)supersedeで置換条件付き判断基準(定型節の書式は本スキル同梱の references/precedent-format.md)
skillそのskillの発動場面中(発動条件の記述精度に従属)PR+デプロイ手順
ツールdocstringツール呼び出しの瞬間高(push。契機が最も鋭い)PR+デプロイ短文の規範・判断基準
server instructionsMCP接続中の全セッションに常時最高(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の配置フローは通らない)

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

【必須】現在のアクティビティを完了にする、または完了にせず中断して寝かせる。「/af」「この作業完了」「クローズして」「一旦ここまで」「今日はここで止める」「いったん置いておく」など終える・中断する意図で発動。このスキルを経由せずにupdate_activityでcompleted・pending・snoozed・shelvedにしない。

The English summary is being prepared. Showing the original description.

isizono/calm4Updated Oct 16, 2026

【必須】新しいアクティビティを作成してcheck-inする。「/as」「新しい作業始める」「アクティビティ作って」「これやる」など新規作業の開始で発動。このスキルを経由せずにadd_activityを呼ばない(orchの起票はorch skillに従う)。

The English summary is being prepared. Showing the original description.

isizono/calm4Updated Oct 16, 2026

【必須】open askを1件ずつ人間に提示し、回答をanswer_askで記録する。「askに答える」「open ask消化して」「溜まってるask片付けたい」などで発動。このスキルを経由せずにanswer_askを呼ばない。

The English summary is being prepared. Showing the original description.

isizono/calm4Updated Oct 16, 2026

【必須】add_askでaskを起票する前に、question/contextをテンプレートで組み立てる。離席中・セッション跨ぎでしか答えられない判断が出たときや、「これ聞いといて」「判断委譲しといて」「後で確認して」などで発動。このスキルを経由せずにaskの文面を書かない(メタaskを除く)。

The English summary is being prepared. Showing the original description.

isizono/calm4Updated Oct 16, 2026

add_askの応答のsimilar_asksを見て、同型の問いが繰り返され裁定が一貫していると気づいたとき、判例をまとめてメタask(kind="meta")を起票する。

The English summary is being prepared. Showing the original description.

isizono/calm4Updated Oct 16, 2026

人間の判断待ちaskの受け箱をMonitorで監視し、判断構造が同じopen askが溜まっていればメタaskを起票する。「ask storeを監視して」「asksを見張って」「open askの滞留をチェックして」などで発動。

The English summary is being prepared. Showing the original description.

isizono/calm4Updated Oct 16, 2026

See all skills by isizono

Report a problem with this skill