CALMの使い方を説明する。「使い方を教えて」「どう使えばいい？」などで発動。記録モデルの使い分け・環境変数の既定値・スナップショット復元手順を記憶だけで断定しそうなときも自分の判断で参照してよい。
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.
以下の情報を元に、ユーザーの質問に合わせてCALMの使い方を説明してください。 全部を一度に説明する必要はありません。ユーザーが知りたいことに焦点を当ててください。 ユーザーが漠然と「使い方教えて」と言った場合は、基本サイクルから始めてください。
なお、Claude自身が状況判断のためにこのファイルを参照する場合は、基本サイクル・主要スキル・その他のスキル・記録の構造・goal機構、および「長く使っていくあなたに」内の環境変数表とスナップショット復元手順を情報源として使ってください。「熟練度別アドバイス」はユーザーへの語りかけ文体で書かれた説明用の文章であり、自分の行動判断の根拠にはせず、ユーザーに説明する際の材料としてのみ参照してください。
Claude自身は、次の瞬間にユーザー発話を待たず本ファイルを参照してよい。
次の場合は参照しない。
manは索引・説明用のskillであり、該当する【必須】skillが担う判定・手順（保存先の判定はremember、決定事項の記録はdecision-record等）を代替しない。
CALMは「着手 → 記録 → 完了 → 同期」のライフサイクルで文脈を維持する。
/activity-start（/as）でアクティビティを作成する。既存の作業を再開するときは /check-in で選ぶ/activity-finish（/af）でアクティビティを完了にする/sync-memory を打つ → AIがセッション全体を振り返って記録を補完する。自動実行はされないため、必ず手動で打つユーザーがやることは基本的に3つ: 作業を始めたら /activity-start、再開するなら /check-in、セッションを終える前に /sync-memory を打つ。
/sync-memory の習慣化/sync-memory はセッション終了前に手動で打つ必要がある（自動では実行されない）。
習慣化することを推奨する。記録が蓄積されれば、目に見えてAIの作業効率が上がることを実感できるはず。
/setup — セットアップ・設定変更の入口settings.jsonに書く（env-config）/setupの振り分け先）— 新しいプロジェクト・取り組みを始めるとき（一度だけの前準備）coding-project-setup（リポジトリのREADME・docs等の走査を伴う）へ引き継がれる/activity-start（/as）— 新しい作業を始めるとき/activity-finish（/af）— 作業が完了したとき、または中断するとき/check-in — 作業再開時に打つ/sync-memory — セッション終了前に打つ/postmortem — 完了したアクティビティを振り返り、うまくいったこと・いかなかったことを整理して、教訓をtag-notesやhabitsに永続化する。大きめの作業が終わったあとに/scribe — CALMに蓄積された記録（決定事項・ログ・資材など）からドキュメントを生成する。ADR、議事録、設計ドキュメントなどを書き起こしたいときに/tag-cleanup — タグの共起分析を実行して、似たタグの統合や不要タグの整理を提案してくれる。記録が増えてきたら不定期に/remember — 「覚えて」「保存して」と言ったときに、保存先（tag-notes/habits/auto-memory等）をAIが判定して振り分けてくれる/rule-placement — メタask裁定で発効した一般化ルールを、rules/habits/tag-notes/pin/判例decision/skill/ツールdocstring/server instructionsのどこへ配信するかを評価軸に基づいて判定する。/rememberの判定木で迷ったときや、1つの裁定に性質の異なる複数ルールが混ざっているときにも使う/audit — 過去の決定事項との矛盾や方針のブレを疑ったときに、経緯を掘り下げて正しい記録場所に整理し直す/recompose-context — アクティビティやトピックに散らばった関連情報を整理・統合し、次回のcheck-inを軽くする。整理範囲のアクティビティのgoal・親への結びつけも整える。「情報整理して」「まとめて」でも発動。--all（全体モード）ではアクティビティ(active/shelved/snoozed)全域を棚卸しし、実態確認のうえでcompleted化・shelved化・description訂正・重複統合・裁定待ちのいずれかに処遇する。「アクティビティ棚卸しして」で発動/db-recovery — SessionStart hookがDBデータ異常減少を検知したときに、スナップショット所在確認から復元実行・再検証までを自律的に進める。DB件数の異常な少なさに自分で気づいたときも対象/decision-record — ユーザーとの合意が成立したとき、または論点が未決のまま話題が移ったときに、決定事項の記録をガイドする/digest — 直近の記録を期間横断で俯瞰するダイジェストを生成する。「最近何やったっけ」「今週のまとめ」など期間ベースの振り返りに/overview — 今動いているもの・最近終わったもの・人間の裁定待ち・残りの内訳を一望表示する。「今何が進んでる」「全体状況見せて」などで発動/forget — 過去の記録が現状と矛盾・陳腐化していると判断したときに、撤回候補を提示してユーザー確認後に撤回する/recording — セッション中に発生した経緯（log）や成果物（material）を、判断基準に沿って記録する/ask-compose — add_askを呼ぶ前に、question/contextをテンプレートに沿って構成する。「これ聞いといて」「離席するから後で確認して」のように非同期の判断委譲を指示したときにも発動する/ask-distill — add_askのsimilar_asksを見て、同型の問いが繰り返され裁定が一貫していると気づいたときに、判例をまとめてメタask（kind="meta"）を起票する/memory-export / /memory-import — CALMの記録（トピック・決定事項・ログ・資材・アクティビティ）を他のCALMインスタンスとやり取りする。exportは書き出し、importは受け取ったバンドルの取り込み。知識を別環境・別の相手と共有したいときに/calm:restart — プラグインを更新し、calmのローカルMCPサーバーを強制再起動する（embeddingサーバーも先に停止され、新しいサーバーの起動直後に自動で立ち上がる）。コード変更や設定変更を反映させたいときに、Claudeが自分でrestart skillを呼んで実行する。ユーザーが打ってもよい/ask-watch — Ask storeをMonitorツールでイベント駆動監視し、同型の問いが繰り返されていないか確認する。「ask storeを監視して」「asksを見張って」等で発動/board — Claude同士の非同期のやり取り（質問・周知・意見募集・事前の声かけ）を、掲示板トピックへの投稿としてガイドする。相手が今生きていてすぐ返事が欲しいときはSendMessageで直接話しかける（このスキルの対象外）/peer-nudge — セッション台帳の宛先候補へSendMessageで直接話しかける前に、担当範囲の確認手順・書き方・配慮・返事が来ないときの扱いをガイドする。相手が今生きていない、または往復が1回で済まない意見募集はboardの担当/orch — 仕事を複数の子に分けてbgに振り、まとめ役として追う・引き継ぐ・終わらせる手順をガイドする。「orchとして進めて」「orchの状況見せて」「○○のorch終えて」などで発動/activity-start で作業アクティビティを作成/activity-finish でアクティビティを完了にする/sync-memory でセッション終了/check-in 、もしくは「〇〇の作業の続きをしていこう」→ 前回の決定事項を把握して実装開始/check-in でアクティビティを選択get_mapでさらに探索できる~/.claude/rules配下の自動生成ファイルに投影され、毎セッション開始時にシステムプロンプトへ自動的に読み込まれる。intelligentlyタイプは同じファイルに重要度順のタイトル一覧（マニフェスト、既定30件まで。CALM_PROJECTION_MANIFEST_MAX_ITEMSで変更可）だけが載り、超過分は本文を切断せず「他N件 → get_habits で確認」の1行に縮退する。本文が必要になればget_habitsをhabit_id指定で呼んで取得する。「materialの書き方」「コミット前の確認事項」など、常に従ってほしいルールを登録できる。AIに「覚えといて」と言えばOKgoal機構は、アクティビティの終了条件を構造化し、いつ・誰が終わりを判定するかを明示するための仕組み。
set_goal: activityにgoalを新規作成して紐づける、既存の未判定goalに紐づける、不要印を付ける、紐づけ・不要印を外す、のいずれかupdate_goal: 条件の追加・状態変更（open/satisfied/waived）・担い手や束縛の変更・statementの修正。判定済みgoalを未判定に戻す差し戻し（reopen_reason）もこのツールjudge_goal: goalを閉じる唯一の手段。achieved（達成）かfailed（未達のまま終了）を記録し、紐づく未完了activityを同じ書き込みでcompletedにするget_goal: 読み取り専用。充足済みを含む全条件を返す（check_inのgoalブロックは要約と直近3件までしか返さない）不要印（set_goalの不要印）と未定義（何も書かない）は、どちらも正当な状態。常駐の活動や同じセッションで閉じる小作業には不要印、終わり方を考える判断材料がまだ無い作業や、聞いても定まらなかった作業は未定義のまま進めてよい。書くことは強制されず、check_inの次の一手が促すだけにとどまる。
goal_rollbackの行が自動で残る（手でreport_signalを呼ぶものではない。kindの詳細はreferences/signals.md）CALM_GOAL_RECHECK_HOURS（既定6時間）: 担い手がhuman/externalのopen条件を「要確認」とみなすまでの時間Ask storeは、だいたいこういうデータフローを提供する仕組み。
作業中のAIがあなたに聞きたいことがあるけど、すぐに答える必要はない——そういうときにAIはその問いをAsk storeに登録する。次にどのセッションを開いても、起動した瞬間にその問いが自然と目に入る。答えると、元の作業をしていたセッションにその判断が伝わり、AIはそれを踏まえて作業を続ける。
つまり「今すぐ答えなくていい判断」を、あなたの好きなタイミングで拾えるようにする仕組み。
Ask storeの読み書き（add_ask・answer_ask・triage_ask・withdraw_ask）と完了通知ファイルの書き込みは、いずれもrelayと無関係に動作する。relay未接続時はrelay経由のクロスセッション通知が静かに省略されるだけで、ask自体の作成・回答・トリアージの成否には影響しない。
/ask-answerで一覧して1件ずつ答えられるtriage_ask（promote/dismiss）またはwithdraw_askが実行されたときのみで、AIの自走裁定や次回のcheck-in等で拾われるまで待つ形になる「これくらいなら聞かなくていい」「これは必ず聞いてほしい」の線引きは人によって違う。自分なりの運用ルールをAIに伝えておくと、Askの粒度がその通りになっていく。
calmのMCPツールを介さなくても、relayが提供するHTTP APIを直接叩けば、スマホやWebhookなど別の手段から回答を投げ込める。
CALMは、セッション間で文脈を保持するためのツール。 セッションが終われば会話は消えるが、CALMに記録された情報は次のセッションに引き継がれる。
やることは基本的に3つ: 作業を始めたら /activity-start、前回の続きなら /check-in、そして セッション終了前に /sync-memory を打つ（自動実行はされないので手動で）。
これだけで、AIがセッション中の議論・決定事項・進捗をまとめて記録する。 次のセッションでは、AIが自動的に過去の記録を取得して文脈を把握した状態で会話を始められる。
/sync-memory を毎セッション終了前に打つ。これが一番重要/check-in でアクティビティを選ぶと、関連する決定事項や経緯を一括取得できるCALMは情報を構造的に管理している。 主な記録単位は トピック（話題）、決定事項（合意）、ログ（経緯）、アクティビティ（行動の塊）、資材（生情報のオフロード先）の5つで、タグがそれらに横断的な特徴を付与する。
このうちトピック・決定事項・ログ・資材はAIが比較的うまく記録してくれる。 しかしアクティビティの切り方とタグの付け方は、AIだけでは精度に限界がある。 アクティビティとは行動の単位であり、「何をやるか」だけでなく「何をやらないか」を暗に定義する。 その境界を引くにはプロジェクト全体の文脈や優先度の判断が必要で、これはAIが持ち合わせていない知識に属する。
だから、ユーザーが能動的にAIに指示を出すことで記録の質が大きく変わる。
domain:backendをつけて」「sprint-3タグで管理したい」のように、自分の整理軸をAIに伝える。domain:タグはアクティブコンテキスト（SessionStart hookの注入情報）のグルーピングに直結するので、複数プロジェクトを扱うなら早めに設計しておくと効くintent:タグ（discuss / design / implement）を付けてくれるupdate_tagで書くCALMは使い続けるほど価値が出るツールだが、放っておいて勝手に良くなるわけではない。 AIが自力では知りえない情報をユーザーが教えてあげることで、記録の質と活用精度が根本的に変わる。
時間を取って、以下のような情報をAIに伝えてみてほしい。一度伝えれば、tag-notesやhabitsとして永続化され、以降のセッションで自動的に参照される。
domain:タグと紐づけておくと、check-in時の文脈取得が的確になる。ここに書ける情報は、リポジトリ内の相対パス・remoteのURLやowner/repo形式の識別子・サービス名など、書いた本人以外のマシン・セッションからも解決できる参照に限る（上の2例はどちらもこれに該当する）。tag-notesはcheck-in時に他セッションへ自動注入され、export機能で別インスタンスにも渡りうるため、自分のマシンでしか通じないローカル絶対パス（~/・/Users/...等）は書かない。そうした情報を残したい場合は/rememberの判定に委ねるCALMはセッション開始時（SessionStart hook）にDBの自動スナップショットを取得する。デフォルトでは12時間間隔で、最新5世代を保持する。スナップショットはDBと同階層の snapshots/ ディレクトリに保存される。
自動検知と警告:
セッション開始時にヘルスチェックが実行され、前回スナップショットと比較してテーブルの行数が100件以上減少している場合、AIに緊急警告が注入される。この場合はdb-recoveryスキルが検知確認から復元実行・再検証までを自律的に進める。以下の手順はその中で参照される詳細であり、db-recoveryを経由せず本節の手動手順だけを案内して終わらせてはならない。
スナップショットからの復元手順:
/healthエンドポイントの応答で検知）のままだと復元コマンド自体が中断する。停止は uv run --no-sync --directory "${CLAUDE_PLUGIN_ROOT}" python "${CLAUDE_PLUGIN_ROOT}/scripts/restart_server.py" --stop を実行する（復元コマンドが中断した場合も同じコマンドを案内する。停止済みを確認済みで続行したい場合のみ restore に --force を付ける）uv run --directory "${CLAUDE_PLUGIN_ROOT}" python "${CLAUDE_PLUGIN_ROOT}/scripts/snapshot.py" restore --latest
uv run --directory "${CLAUDE_PLUGIN_ROOT}" python "${CLAUDE_PLUGIN_ROOT}/scripts/snapshot.py" restore <snapshot_db_path> を使う（パスは次項の一覧コマンドで確認する）prerestoreスナップショット）ため、復元操作自体を誤っても退避先からやり直せるスナップショット一覧の確認:
uv run --directory "${CLAUDE_PLUGIN_ROOT}" python "${CLAUDE_PLUGIN_ROOT}/scripts/snapshot.py" list
全kind横断のスナップショット一覧（kind・作成日時・サイズ・整合性チェック結果・パス）が表示される。復元先を選ぶ際の参考にできる。
CALMには「壊れてもエラーにならず、静かに機能が縮退する」種類の故障がいくつかある。データ消失（前項のスナップショット異常検知）とは別に、以下の3つは気づかないまま使い続けてしまいやすい。
embeddingサーバーの起動失敗
検索・check-in等でベクトル検索を使う際、embeddingサーバー（52836番ポート）が初回encode時に遅延起動する。起動に失敗しても例外は投げず、warningログのみを出して検索がキーワード一致（FTS5）のみに縮退したまま動き続ける。
uv run --no-sync --directory "${CLAUDE_PLUGIN_ROOT}" python "${CLAUDE_PLUGIN_ROOT}/scripts/restart_server.py" --status の embedding_server.running が false のまま。または後述のdegradedフラグが立ち続けるrestart_server.pyやkill・起動コマンドを直接は打たない検索応答のdegraded: true
searchツールの応答に含まれるdegradedは、その呼び出し時点でベクトル検索（embeddingサーバー）が利用不可だったことを示す。trueのときの結果はFTS5キーワード一致・タグ名一致のみに基づき、意味的には関連するが字面が異なる項目を取りこぼしている可能性がある。「類似する情報が見つからない」と判断する前に、AIはこのフラグを確認すべきである。
search応答のdegradedキーを見る（バリデーションエラー等でベクトル検索を試す前に結果が確定した場合はキー自体が無い）hookが黙って失敗する
CALMの全hookはfail-open設計（1つのhookの失敗が他の操作を止めない）。この設計自体は意図的だが、失敗が既定では標準エラー出力にしか残らず、記録ナッジやSessionStart注入の一部セクションが黙って消えても「何も起きていない」ように見える。
signal_eventsへkind: machine_errorとして記録する。get_signals()で確認できるほか、1件でもあればSessionStart注入の「未トリアージのシグナル」行にも現れる
sourceがhook:section:<セクション名>）sourceがhook:session_start）sourceがhook:stop）・記録ナッジ判定（sourceがhook:stop:logs_sparse）sourceがhook:preblock）sourceがhook:user_prompt_submit）sourceがhook:deny_nested_bg）get_signals(kind="machine_error")でdetail・summaryを確認し、原因（依存モジュールの欠落・DBスキーマ不一致等）を調査する。記録は失敗の発生を示すだけで、自動修復はしないmain()に到達する前に）落ちた場合は記録されず、標準エラー出力のみに残る。MessageDisplay等の表示専用hook・transcript sanitize系hook（別途citation_event_logへ失敗を記録済み）も現状この記録の対象外~/.claude/rules配下の自動生成ファイル経由でセッション開始時に読み込まれる（詳細は「記録の構造」参照）。AIに「覚えといて」と言えばOKintent:タグのtag-notes: 議論・設計・作業の各フェーズでAIにどう振る舞ってほしいかを定義できる。初期状態でdiscussとdesignが登録されている~/.claude/settings.jsonのenvフィールドで以下の値をオーバーライドできる。未設定ならデフォルト値で動作する。/setupから設定変更を選ぶと、一覧の表示と書き込みをAIが手伝う。変更後はClaudeがrestart skill（/calm:restart。プラグイン更新と再起動を行う）でMCPサーバーを再起動する。ユーザーが打ってもよい| 環境変数名 | デフォルト | 説明 |
|---|---|---|
CALM_DB_PATH | ~/.claude/.claude-code-memory/discussion.db | データベースファイルのパス |
CALM_HEARTBEAT_TIMEOUT | 20 | ホットアクティビティ判定の閾値（分） |
CALM_TIER2_MAX_AGE_DAYS | 7 | SessionStart一覧の階層2にin_progressアクティビティを載せるupdated_at上限（日） |
CALM_PIN_SURFACE_DECAY_DAYS | 60 | pinnedアクティビティが階層2表示を維持できるupdated_at上限（日） |
CALM_TIER2_MAX_ITEMS | 5 | SessionStart一覧の『優先』に出す件数の上限。hookが読むため~/.claude/settings.jsonのenvで設定する。増やすときはCALM_INJECTION_BUDGET_ACTIVITIESも上げる（各セクションの予算の合計がCALM_TOTAL_INJECTION_BUDGET_CHARSを超えるとcomposeがValueErrorを出す。既定の合計は10500字で、総予算12000字との差は1500字） |
CALM_RECENCY_DECAY_RATE | 0.0119 | 検索の時間減衰率 |
CALM_PRECEDENT_BUDGET_CHARS | 24000 | pull_precedentsが本文展開（decision＋reason）に使う文字数予算 |
CALM_SYNC_DISABLE_RETROSPECTIVE | false | /sync-memoryのふりかえりセクションを非表示にする |
CALM_SNAPSHOT_INTERVAL | 12 | スナップショット取得間隔（時間） |
CALM_SNAPSHOT_MAX_COUNT | 5 | スナップショット最大保持数 |
CALM_SNAPSHOT_ANOMALY_THRESHOLD | 100 | 行数減少の異常検知閾値（件） |
CALM_SEARCH_HEALTH_WINDOW_DAYS | 7 | 検索縮退・クエリ拡張停止検知の集計対象ウィンドウ（日） |
CALM_SEARCH_HEALTH_MAX_SAMPLE | 100 | 同集計で見る最大件数（timestamp降順） |
CALM_SEARCH_HEALTH_MIN_SAMPLE | 20 | 同集計の判定に必要な最小サンプル数（未満なら常に健全扱い） |
CALM_SEARCH_HEALTH_DEGRADED_RATIO | 0.2 | 検索の縮退率がこの値以上なら異常とみなす閾値 |
CALM_SEARCH_HEALTH_QE_FIRE_FLOOR | 0.0 | クエリ拡張の発火率がこの値以下なら異常とみなす閾値 |
CALM_PROJECTION_MANIFEST_MAX_ITEMS | 30 | intelligently habitsマニフェストの掲載件数上限 |
CALM_GOAL_RECHECK_HOURS | 6 | goalの条件のうち担い手がhuman/externalのopen条件を「要確認」とみなすまでの時間（時間） |
CALM_PROJECT_ROOT | 自動解決（CLAUDE_PLUGIN_ROOT → git rev-parse --git-common-dir） | embedding_serverを起動するプロジェクトルート。優先順位は 明示設定 → プラグイン実行時はCLAUDE_PLUGIN_ROOTの値から自動設定 → embedding_server自身のgit rev-parse --git-common-dir解決 → いずれも失敗した場合はRuntimeError。加えて/calm:restart（強制再起動）実行時は、上記のいずれでも未設定であればrestart_service自身も同じgit-common-dir解決（gitリポジトリでなければ実行時のプロジェクトルート）で先回りして設定する。通常は自動解決されるため設定不要だが、いずれの自動解決にも失敗する環境（gitリポジトリ外かつCLAUDE_PLUGIN_ROOTも未設定）では明示設定が必要 |
環境変数は CALM_ 接頭辞に統一されている。旧名（CCM_ / CC_MEMORY_）も当面はフォールバックとして読まれるが、新名が設定されていればそちらが優先される。
現在の設定値はget_config()ツールで確認できる。
記録が増えてくると、タグが散らかったり似たようなタグが乱立したりする。
不定期に /tag-cleanup を実行して、タグの共起分析と整理をしておくと、検索精度と分類の質を維持できる。
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.