【必須】セッション中の経緯と成果物を記録する。複数案からの採択、詰まりの解決、PRレビューでの複数修正、バグの観察、指示による方針転換、ドラフト・調査レポート・比較表の完成などで発動。このスキルを経由せずにadd_logs・add_materialを呼ばない。
The English summary is being prepared. Showing the original description.
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
セッション中に発生した「経緯（log）」と「成果物（material）」を記録する。判断基準と発動例をここに集約しているため、add_logs / add_material を呼ぶ前に本スキルの判定を必ず通す。
このスキルは初回 load 時に発動するが、判断基準は本セッション内のすべての後続ターンに適用される。以降のターンで下の例（L1-L5 / M1-M4）に該当する出来事が起きたら、明示的に skill を再発動せずとも add_logs / add_material を呼ぶこと。
sync-memory による漏れの救済は、ユーザーが /sync-memory を明示的に実行した場合に限られる（自動実行はない）。recording skill はトリガー例に基づく検知であり元々「完全網羅」を保証する仕組みではないため役割は「セッション中の見逃し低減」のままだが、事後の自動救済が無くなった分、判断に迷ったら記録する側に倒す姿勢がこれまで以上に重要になる。
add_logs（経緯記録）add_material（成果物保存）add_decisions / add_topic / add_habit は本スキルの案内対象外。
掲示板トピックへの投稿（board skillが扱うadd_logs呼び出し）も対象外。目的が自分の作業の経緯・成果物の記録ではなく他セッションへの伝達であるため、判断基準はboard skill側が持つ。add_logsツールのdocstringにある「呼び出し前にrecording skillの判断ガイドを通すこと」は、掲示板投稿以外の通常のadd_logs呼び出しに対する指示であり、この例外を妨げない。
CALM 自身の故障・使用感不満・既存記録との矛盾は add_logs ではなく report_signal を使う（下記「report_signal との切り分け」参照）。
| # | トリガー | 量の目安 | 残す内容 |
|---|---|---|---|
| L1 | 議論で 3 案以上比較 → 1 案採択（or 却下） | 議論で N 往復 / 案 3+ | 採択案・却下案・却下理由 |
| L2 | 実装/作業で blocked → 解決経緯 | blocked 1 回でも | 詰まった状況・解決手段・教訓 |
| L3 | PR レビュー対応で複数 fix した経緯 | bot 指摘 2 件以上 | 指摘内容・対応 commit・残課題 |
| L4 | ユーザー明示指示で方針が変わった | 1 回でも | 元方針・新方針・指示理由 |
| L5 | バグ観察（本題作業中の脇道発見） | 観察 1 件 | 現象・再現条件・影響範囲 |
| # | トリガー | 量の目安 | 残す内容 |
|---|---|---|---|
| M1 | 設計たたき台 / ドラフト v0 / v1 完成 | 1 ドラフト | 生データそのまま（要約しない） |
| M2 | 調査・試算レポート完成 | 1 レポート | 試算式・結果・条件 |
| M3 | 未コミットのWIP差分・中間成果物 | 1 件 | diff・WIP 状態の説明 |
| M4 | 比較・分析結果（案 N 件の比較表など） | 表 1 つ | 比較項目・スコア・採択理由 |
「など」: 上記に当てはまらなくても、後続セッションが文脈を引き継ぐために要る経緯や成果物が出たら同等に扱う。例: 仕様確定議論の脇で出た代替案メモ、調査の途中で得た一次資料の抜粋、設計レビューで指摘された未解決リスト、外部記事の要旨など。
L5（バグ観察）はユーザーが取り組んでいる対象システムのバグが対象。CALM 自身の故障・使用感不満・既存記録との矛盾を観測したときは add_logs ではなく report_signal を呼ぶ（合意不要の生の観測データであり、topic 紐付けや文脈タグは不要）。
| kind | 発火例 |
|---|---|
machine_error | ツールエラー・hook 失敗・サーバー異常を観察した |
friction | 検索で引けるべき記録が引けなかった等、CALM の使い勝手への不満・違和感を感じた |
contradiction | 設計・実装中に既存 decision と矛盾する結論に達した / add_decisions の related_decisions、add_logs/add_material の related_records で矛盾に気づいた |
上記3種は頻出例であり、report_signal の kind は全9種ある（precedent_miss /
precedent_misapplied / boundary_case / rollback / goal_rollback /
guard_block を含む）。goal_rollback は update_goal の reopen_reason
（goal 判定の差し戻し）が、guard_block はhookのdeny判定が書く専用の kind で、
いずれも手で報告するものではない。全種の定義は report_signal ツールの
docstringを正とする。同一内容の再報告は report_signal 側で自動集約されるため、
迷ったら報告してよい。
より詳しい発動例・判断に迷う場合の追加基準は本スキルディレクトリ内の
references/taxonomy.md（1章・2章・4章）に整理してある。本ページの表と
食い違う場合は references/taxonomy.md を正とする。
add_logs / add_material を呼んだ内容が、手元のgoalブロック（check_in等で読んで持っている場合）の未終端の条件を満たすなら、続けて update_goal を呼ぶ。changes に {"op": "set", "id": <条件id>, "state": "satisfied", "note": "..."} を積み、根拠になった decision や子 activity があれば同じ changes に {"op": "edit", "id": <条件id>, "bound": {"type": "decision"|"activity", "id": <id>}} を並べて束縛する（1回の呼び出しでまとめてよい）。
外部の事実（PRのマージ状況など）を根拠にする場合は、書く前にgh等で実際に確かめる。確かめたことが分かるように、その事実自体を add_material か add_logs として別途残す。推測のまま satisfied にしない。
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フィールドの扱い」節を正本とする。判定条件が変わる場合はそちらを確認する。
「多めに残す > 少なく残す」。
迷ったら記録する。漏れの最終救済はユーザーが /sync-memory を実行した場合の sync-memory が担うが、それは保証された安全網ではない。本スキルの役割は「セッション中の見逃し低減」であり、ここで取りこぼすと /sync-memory が実行されない限り文脈は失われたままになる。
add_logs の content / add_material の content は要約せず生データを残すadd_material の content 先頭 1-2 文は内容の説明・要約を書く（check-in 時に snippet として表示される）add_material は add_decisions と違って「双方の合意」が不要。成果物が出た時点でユーザーに確認せず呼ぶadd_material の content に事実と推論が混在する場合は明示的に区別する（例: 「【事実】」「【推論】」見出しを付ける）tags には domain: を必ず付け、内容を表す素タグも追加する。intent: namespace の例: intent:discuss / intent:design / intent:implement / intent:investigaterelated で関連する activity / topic / decision / log / material と紐付けるadd_logs は topic_id 必須。tag だけでは紐付かないadd_logs / add_material のレスポンスには related_records（類似する既存記録の上位3件。同一セッションで一度提示した記録は再提示されない）が付く。既存記録と矛盾・重複に気づいたら report_signal(kind="contradiction") を呼ぶNo reviews yet. Tell others what you thought.
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.
【必須】現在のアクティビティを完了にする、または完了にせず中断して寝かせる。「/af」「この作業完了」「クローズして」「一旦ここまで」「今日はここで止める」「いったん置いておく」など終える・中断する意図で発動。このスキルを経由せずにupdate_activityでcompleted・pending・snoozed・shelvedにしない。
The English summary is being prepared. Showing the original description.
【必須】新しいアクティビティを作成してcheck-inする。「/as」「新しい作業始める」「アクティビティ作って」「これやる」など新規作業の開始で発動。このスキルを経由せずにadd_activityを呼ばない（orchの起票はorch skillに従う）。
The English summary is being prepared. Showing the original description.
【必須】open askを1件ずつ人間に提示し、回答をanswer_askで記録する。「askに答える」「open ask消化して」「溜まってるask片付けたい」などで発動。このスキルを経由せずにanswer_askを呼ばない。
The English summary is being prepared. Showing the original description.
【必須】add_askでaskを起票する前に、question/contextをテンプレートで組み立てる。離席中・セッション跨ぎでしか答えられない判断が出たときや、「これ聞いといて」「判断委譲しといて」「後で確認して」などで発動。このスキルを経由せずにaskの文面を書かない（メタaskを除く）。
The English summary is being prepared. Showing the original description.
add_askの応答のsimilar_asksを見て、同型の問いが繰り返され裁定が一貫していると気づいたとき、判例をまとめてメタask（kind="meta"）を起票する。
The English summary is being prepared. Showing the original description.
人間の判断待ちaskの受け箱をMonitorで監視し、判断構造が同じopen askが溜まっていればメタaskを起票する。「ask storeを監視して」「asksを見張って」「open askの滞留をチェックして」などで発動。
The English summary is being prepared. Showing the original description.