免费在 GitHub 公开

man

CALMの使い方を説明する。「使い方を教えて」「どう使えばいい？」などで発動。記録モデルの使い分け・環境変数の既定値・スナップショット復元手順を記憶だけで断定しそうなときも自分の判断で参照してよい。

中文简介正在准备中。当前显示原文说明。

isizono/calm星标 4(GitHub 4 + cccskills 0)

实测评分未实测

查看安装方法

包含的文件（2）

SKILL.md37.6 KB
references/signals.md6.7 KB

SKILL.md（原文）

安装前可以查看交给 AI 代理的指令内容。

man

以下の情報を元に、ユーザーの質問に合わせてCALMの使い方を説明してください。全部を一度に説明する必要はありません。ユーザーが知りたいことに焦点を当ててください。ユーザーが漠然と「使い方教えて」と言った場合は、基本サイクルから始めてください。

なお、Claude自身が状況判断のためにこのファイルを参照する場合は、基本サイクル・主要スキル・その他のスキル・記録の構造・goal機構、および「長く使っていくあなたに」内の環境変数表とスナップショット復元手順を情報源として使ってください。「熟練度別アドバイス」はユーザーへの語りかけ文体で書かれた説明用の文章であり、自分の行動判断の根拠にはせず、ユーザーに説明する際の材料としてのみ参照してください。

Claude自身は、次の瞬間にユーザー発話を待たず本ファイルを参照してよい。

CALMの記録モデル（トピック/decision/log/activity/material/tag-notes/habits/goal）の使い分け、環境変数の既定値、スナップショット復元手順など、本ファイルにしかない情報を確認せず記憶だけで断定しようとしている
ユーザーがCALMの機能・挙動を前提に話しているのに、自分がその機能を把握できていないと気づいた

次の場合は参照しない。

どのskillを呼ぶべきか判断がつかないだけの場合（各skillのdescriptionはskill一覧で渡されている。ただし一覧の文字数予算を超えると、説明文が落ちて名前だけになることがある）
同一セッション内で既に参照済みの内容を再確認するためだけの場合
単一ツールの引数仕様など、そのツール自身のdocstringで足りる疑問

manは索引・説明用のskillであり、該当する【必須】skillが担う判定・手順（保存先の判定はremember、決定事項の記録はdecision-record等）を代替しない。

基本サイクル

CALMは「着手 → 記録 → 完了 → 同期」のライフサイクルで文脈を維持する。

作業に着手するとき: /activity-start（/as）でアクティビティを作成する。既存の作業を再開するときは /check-in で選ぶ
作業中: AIがトピック・決定事項・ログを記録する（ユーザーが意識する必要はない）
作業が完了したとき: /activity-finish（/af）でアクティビティを完了にする
セッション終了前: /sync-memory を打つ → AIがセッション全体を振り返って記録を補完する。自動実行はされないため、必ず手動で打つ
次のセッション開始時: AIが過去の記録を取得して文脈を把握する

ユーザーがやることは基本的に3つ: 作業を始めたら /activity-start、再開するなら /check-in、セッションを終える前に /sync-memory を打つ。

重要: `/sync-memory` の習慣化

/sync-memory はセッション終了前に手動で打つ必要がある（自動では実行されない）。習慣化することを推奨する。記録が蓄積されれば、目に見えてAIの作業効率が上がることを実感できるはず。

主要スキル

`/setup` — セットアップ・設定変更の入口

やりたいことを判断して、中のスキルに振り分ける。ユーザーが打つのはこのスキルだけ
- インストール直後: 前提条件（uv・sqlite拡張・embeddingサーバー）の確認、ペルソナのヒアリング、使い方の案内（initial-setup）
- 新しいプロジェクト・取り組みを始めるとき: 下記のproject-setup
- 環境変数による設定変更: 一覧を見せ、確認を取ってsettings.jsonに書く（env-config）

project-setup（`/setup`の振り分け先）— 新しいプロジェクト・取り組みを始めるとき（一度だけの前準備）

新しいプロジェクト・取り組み（新しいdomain）の知識フレーム（プロジェクト識別子・主要な関心事・既に決まっている方針・直近やること・参照ポインタ）を対話的にセットアップする
コード開発が目的なら、自動的にcoding-project-setup（リポジトリのREADME・docs等の走査を伴う）へ引き継がれる
一度作れば、以降は基本サイクルで運用していく
タイミング: 新しいプロジェクト・取り組みでCALMを使い始める最初の一度

`/activity-start`（`/as`）— 新しい作業を始めるとき

新規アクティビティを作成し、そのまま着手状態にする
「このissueの調査をアクティビティにして」のように、自分が管理したい粒度を指示できる
タイミング: 新しい作業・議論・設計を始めるとき

`/activity-finish`（`/af`）— 作業が完了したとき、または中断するとき

現在のアクティビティをcompleted状態にする
完了ではなく、「一旦ここまで」「今日はここで止める」のように後で戻る前提で離れるときは、再開メモを添えて寝かせる（pending・snoozed・shelvedのいずれか）
タイミング: 一つの作業のまとまりが終わったとき、または完了させず一旦離れるとき

`/check-in` — 作業再開時に打つ

スキルを起動すると、AIが記録しているアクティビティの一覧が表示されるので、再開したいものを選ぶだけ
選択すると、関連する決定事項やこれまでの経緯を一括で取得してくれる
もし期待していたアクティビティが一覧にない場合は、それはAIが自動生成に失敗しているということなので、AIに明示的に作成を依頼してみるとよい
タイミング: 前回の続きの作業を再開するとき

`/sync-memory` — セッション終了前に打つ

セッション中の議論・決定事項・ログをAIが自動で整理・記録する
AIが記録し忘れた内容も、セッション全体のtranscriptを見て補完する
タイミング: セッションを終える前。長いセッションでは途中で打ってもOK。自動実行はされないため必ず手動で打つ
2回目以降に打っても、前回の記録と重複して記録されることはないので安心して使える

その他のスキル

/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終えて」などで発動

よくあるパターン

設計議論 → 実装の流れ

新機能の議論を始める → AIがトピックを作成
議論の中で方針が決まる → AIが決定事項（decision）を記録
設計が固まったら /activity-start で作業アクティビティを作成
作業が完了したら /activity-finish でアクティビティを完了にする
/sync-memory でセッション終了
次のセッションで /check-in 、もしくは「〇〇の作業の続きをしていこう」→ 前回の決定事項を把握して実装開始

途中で中断した作業の再開

/check-in でアクティビティを選択
AIが関連のコンテキストを取得してくる
前回どこまでやったか把握して続きから再開

記録の構造

トピック: 1つの関心事・問題・機能（話題が変わったら新しく作る）
決定事項（decision）: 双方が合意した結論。「何を・なぜ」を記録
ログ（log）: 議論の経緯・生情報。決定に至るプロセスを保存
アクティビティ: ある程度の活動の塊。デフォルトで議論・設計・作業の3つのフェーズを用意している
リレーション: トピック・アクティビティ間の関連。check-inで2親等まで自動取得され、get_mapでさらに探索できる
資材（material）: 長い生情報のオフロード先。独立エンティティとしてタグ付きで保存され、リレーションでトピック・アクティビティと関連付けられる
タグノート: タグに紐づく常備情報。関連作業時にAIへ自動注入される
振る舞い（habits）: 全セッション共通で従ってほしいルール。alwaysタイプは全文が~/.claude/rules配下の自動生成ファイルに投影され、毎セッション開始時にシステムプロンプトへ自動的に読み込まれる。intelligentlyタイプは同じファイルに重要度順のタイトル一覧（マニフェスト、既定30件まで。CALM_PROJECTION_MANIFEST_MAX_ITEMSで変更可）だけが載り、超過分は本文を切断せず「他N件 → get_habits で確認」の1行に縮退する。本文が必要になればget_habitsをhabit_id指定で呼んで取得する。「materialの書き方」「コミット前の確認事項」など、常に従ってほしいルールを登録できる。AIに「覚えといて」と言えばOK

goal機構

goal機構は、アクティビティの終了条件を構造化し、いつ・誰が終わりを判定するかを明示するための仕組み。

何を保存し何を導出するか

保存するのは、goal本体（handle・statementと判定記録）、条件（真偽の付く1文・担い手・状態・束縛）、activityとの紐づけ（不要印を含む）の3種類だけ
check_inやgoalツールの応答に載るgoalブロック（label・進捗・次の一手など）は保存しない。読み出しのたびに条件の状態から都度計算して返す導出値

4つのツール

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件までしか返さない）

運用の勘所がどの瞬間に効くか

起票（activity-start）: 終了条件を書く／不要印を付ける／何も書かない、の3択にする。雛形で埋めない。条件は真偽の付く1文で書き、Claudeが推した条件も追認を待たずそのまま書く。候補が複数で定まらない、または終わりがあるはずだが何なのか推せないときだけユーザーに聞き、定まれば書く
記録の直後（recording・decision-record）: 条件を満たしたら、その場でupdate_goalに書く。根拠のdecisionなどがあれば、同じ呼び出しで束縛も張る。それで判定待ちになったら、そのまま判定に続く
待ち（ask-compose・activity-finishの中断）: 会話や記録から満たされたと分かるなら確認せずsatisfiedに書く。分からない人間の判断待ちだけ、その場で聞けるなら聞いてdecisionにする。離席中・セッション跨ぎならaskにして、条件をそのaskに束縛する
判定（recording・decision-record・check-in・activity-finish・recompose-contextの全体モード）: 全条件が終端になった判定待ちの状態を見たら、そのセッションがその場でjudge_goalを呼ぶ。判定したことの報告はしない。未決（openなask・[議論中]のdecision）があれば、判定の前に畳むか1ターン聞く
整理のついで（recompose-context）: 整理範囲に出てきた未完了のアクティビティのうち、goalが未定義のものに記録から推せる終了条件を書く（推せなければ書かない。不要印は触らない）。振ったまとめ役が推せるなら、確認なしに親のgoalへ子を束縛先にした条件を足す。推定では条件を満たさず、判定もしない
事後の記録（sync-memory）: transcriptから推せる終了条件は確認なしで書く。候補が複数で定まらない、または推せないときは書かない（事後の一括処理でユーザーに聞けないため未定義のまま残す）。外部の完了はghなど実際の手段で確かめられればsatisfiedに書き、確かめた結果で終端すればjudge_goalも呼ぶ。確かめられない推測はsatisfiedにも判定にも使わない

終了条件を書かない選択

不要印（set_goalの不要印）と未定義（何も書かない）は、どちらも正当な状態。常駐の活動や同じセッションで閉じる小作業には不要印、終わり方を考える判断材料がまだ無い作業や、聞いても定まらなかった作業は未定義のまま進めてよい。書くことは強制されず、check_inの次の一手が促すだけにとどまる。

差し戻しと環境変数

判定済みgoalを差し戻すと、signal_eventsにgoal_rollbackの行が自動で残る（手でreport_signalを呼ぶものではない。kindの詳細はreferences/signals.md）
CALM_GOAL_RECHECK_HOURS（既定6時間）: 担い手がhuman/externalのopen条件を「要確認」とみなすまでの時間

Ask store

Ask storeとは

Ask storeは、だいたいこういうデータフローを提供する仕組み。

作業中のAIがあなたに聞きたいことがあるけど、すぐに答える必要はない——そういうときにAIはその問いをAsk storeに登録する。次にどのセッションを開いても、起動した瞬間にその問いが自然と目に入る。答えると、元の作業をしていたセッションにその判断が伝わり、AIはそれを踏まえて作業を続ける。

つまり「今すぐ答えなくていい判断」を、あなたの好きなタイミングで拾えるようにする仕組み。

Ask storeの読み書き（add_ask・answer_ask・triage_ask・withdraw_ask）と完了通知ファイルの書き込みは、いずれもrelayと無関係に動作する。relay未接続時はrelay経由のクロスセッション通知が静かに省略されるだけで、ask自体の作成・回答・トリアージの成否には影響しない。

基本の使い方

判断待ちが溜まっていないか気になったら「asks見せて」とAIに聞くか、/ask-answerで一覧して1件ずつ答えられる
回答するときは、そのまま会話であなたの判断を伝えればAIが記録してくれる
回答しただけではその問いが元のactivityをブロックしている状態は解除されない。解除されるのは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 を毎セッション終了前に打つ。これが一番重要
記録が貯まるほどAIの初手精度が上がることを実感できるはず
前回の続きの作業があるときは /check-in でアクティビティを選ぶと、関連する決定事項や経緯を一括取得できる

使いこなしたいあなたに

CALMは情報を構造的に管理している。主な記録単位は トピック（話題）、決定事項（合意）、ログ（経緯）、アクティビティ（行動の塊）、資材（生情報のオフロード先）の5つで、タグがそれらに横断的な特徴を付与する。

このうちトピック・決定事項・ログ・資材はAIが比較的うまく記録してくれる。しかしアクティビティの切り方とタグの付け方は、AIだけでは精度に限界がある。アクティビティとは行動の単位であり、「何をやるか」だけでなく「何をやらないか」を暗に定義する。その境界を引くにはプロジェクト全体の文脈や優先度の判断が必要で、これはAIが持ち合わせていない知識に属する。

だから、ユーザーが能動的にAIに指示を出すことで記録の質が大きく変わる。

アクティビティの範囲を指示する: 「このissueの調査をアクティビティにして」「設計と実装は別アクティビティに分けて」のように、自分が管理したい粒度で切るようAIに伝える。AIに任せると1セッション＝1アクティビティになりがちだが、実際には1セッションで複数の話題を扱うことも、複数セッションで1つの作業を続けることもある
タグを指示する: 「domain:backendをつけて」「sprint-3タグで管理したい」のように、自分の整理軸をAIに伝える。domain:タグはアクティブコンテキスト（SessionStart hookの注入情報）のグルーピングに直結するので、複数プロジェクトを扱うなら早めに設計しておくと効く
議論→設計→作業のフェーズを意識する: 急いで作業に入らず、議論と設計を丁寧にやるとAIの引き継ぎ品質が上がる。「まず議論フェーズで進めて」「設計が固まったら作業アクティビティを作って」のように、フェーズ遷移も明示するとAIが適切なintent:タグ（discuss / design / implement）を付けてくれる
繰り返し伝えていることをtag-notesに永続化する: 同じフィードバックを2回以上したら登録のサイン。「AIに毎回言い直している指示」があれば、それはtag-notesに書くべき情報。「このタグのnotesに追記して」と頼めばAIがupdate_tagで書く

長く使っていくあなたに

CALMは使い続けるほど価値が出るツールだが、放っておいて勝手に良くなるわけではない。 AIが自力では知りえない情報をユーザーが教えてあげることで、記録の質と活用精度が根本的に変わる。

AIに教えるべき情報

時間を取って、以下のような情報をAIに伝えてみてほしい。一度伝えれば、tag-notesやhabitsとして永続化され、以降のセッションで自動的に参照される。

取り組んでいるプロジェクトの概要: 何を作っていて、なぜ作っているのか。AIはコードは読めるが、プロジェクトの目的やビジネス上の文脈は知らない
プロジェクトとディレクトリの対応: 「このリポジトリは〇〇プロジェクトのバックエンド」「△△はこのmonorepo内のpackages/appにある」など。domain:タグと紐づけておくと、check-in時の文脈取得が的確になる。ここに書ける情報は、リポジトリ内の相対パス・remoteのURLやowner/repo形式の識別子・サービス名など、書いた本人以外のマシン・セッションからも解決できる参照に限る（上の2例はどちらもこれに該当する）。tag-notesはcheck-in時に他セッションへ自動注入され、export機能で別インスタンスにも渡りうるため、自分のマシンでしか通じないローカル絶対パス（~/・/Users/...等）は書かない。そうした情報を残したい場合は/rememberの判定に委ねる
ユビキタス言語: プロジェクト固有の用語や略語。AIが勝手に別の言い回しで記録すると、後から検索で引っかからなくなる

データ保護（スナップショット）

CALMはセッション開始時（SessionStart hook）にDBの自動スナップショットを取得する。デフォルトでは12時間間隔で、最新5世代を保持する。スナップショットはDBと同階層の snapshots/ ディレクトリに保存される。

自動検知と警告:

セッション開始時にヘルスチェックが実行され、前回スナップショットと比較してテーブルの行数が100件以上減少している場合、AIに緊急警告が注入される。この場合はdb-recoveryスキルが検知確認から復元実行・再検証までを自律的に進める。以下の手順はその中で参照される詳細であり、db-recoveryを経由せず本節の手動手順だけを案内して終わらせてはならない。

スナップショットからの復元手順:

全てのClaude Codeセッションを閉じ、稼働中のMCPサーバーを停止する（DBへの書き込みを停止するため）。サーバーが稼働中（lock fileまたは/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> を使う（パスは次項の一覧コマンドで確認する）
復元前の現行DBは自動で退避される（prerestoreスナップショット）ため、復元操作自体を誤っても退避先からやり直せる
Claude Codeを再起動する

スナップショット一覧の確認:

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 skillで再起動する（embeddingサーバーも一緒に入れ替わる）。restart_server.pyやkill・起動コマンドを直接は打たない

検索応答のdegraded: true

searchツールの応答に含まれるdegradedは、その呼び出し時点でベクトル検索（embeddingサーバー）が利用不可だったことを示す。trueのときの結果はFTS5キーワード一致・タグ名一致のみに基づき、意味的には関連するが字面が異なる項目を取りこぼしている可能性がある。「類似する情報が見つからない」と判断する前に、AIはこのフラグを確認すべきである。

気づき方: search応答のdegradedキーを見る（バリデーションエラー等でベクトル検索を試す前に結果が確定した場合はキー自体が無い）
直し方: 少し時間を置いて再検索する、または上記のembeddingサーバー再起動を行う

hookが黙って失敗する

CALMの全hookはfail-open設計（1つのhookの失敗が他の操作を止めない）。この設計自体は意図的だが、失敗が既定では標準エラー出力にしか残らず、記録ナッジやSessionStart注入の一部セクションが黙って消えても「何も起きていない」ように見える。

気づき方: 以下のhookは、hook本体のコードが実行された後に起きた例外をsignal_eventsへkind: machine_errorとして記録する。get_signals()で確認できるほか、1件でもあればSessionStart注入の「未トリアージのシグナル」行にも現れる
- SessionStart注入の各セクション（sourceがhook:section:<セクション名>）
- SessionStart hook本体（sourceがhook:session_start）
- Stop hook本体（sourceがhook:stop）・記録ナッジ判定（sourceがhook:stop:logs_sparse）
- PreToolUseの内部IDリークブロックhook（sourceがhook:preblock）
- UserPromptSubmit hook（sourceがhook:user_prompt_submit）
- PreToolUseのネストbg起動拒否hook（sourceがhook:deny_nested_bg）
直し方: get_signals(kind="machine_error")でdetail・summaryを確認し、原因（依存モジュールの欠落・DBスキーマ不一致等）を調査する。記録は失敗の発生を示すだけで、自動修復はしない
限界: この記録機構自体がDB層のimportに依存するため、venvの破損や依存パッケージの欠落でhookがimport時点で（main()に到達する前に）落ちた場合は記録されず、標準エラー出力のみに残る。MessageDisplay等の表示専用hook・transcript sanitize系hook（別途citation_event_logへ失敗を記録済み）も現状この記録の対象外

カスタマイズできるもの

tag-notes: タグに紐づく常備情報。そのタグに関連する作業が始まったときにAIへ自動注入される。「タグノート見せて」「このタグのnotes更新して」とAIに頼めば確認・更新できる
振る舞い（habits）: 全セッション共通のルール。alwaysタイプは全文、intelligentlyタイプはタイトル一覧（マニフェスト）が~/.claude/rules配下の自動生成ファイル経由でセッション開始時に読み込まれる（詳細は「記録の構造」参照）。AIに「覚えといて」と言えばOK
intent:タグの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 を実行して、タグの共起分析と整理をしておくと、検索精度と分類の質を維持できる。

查看 isizono 的全部技能

报告此技能的问题

安装

用命令安装

npx skills add https://github.com/isizono/calm --skill man

粘贴到终端中运行（需要 Node.js）。可以选择安装到 Claude Code、Codex 等代理。

让代理安装

请安装以下 Agent Skill。
https://github.com/isizono/calm/tree/main/skills/man

请先检查 SKILL.md 和附带文件的内容，确认没有可疑的处理（向外部发送数据、读取认证信息等）后，再放到 ~/.claude/skills/man/（Claude Code）或 ~/.agents/skills/man/（Codex）。

把这段文字直接发给 Claude Code 或 Codex，它会先检查内容再安装。

在 GitHub 查看源代码

仓库: isizono/calm
星标: 4
复刻: 1
分类: 其他
许可证: MIT
原文语言: 日语
最后更新: 2026年10月16日

技能是给 AI 代理的指令和脚本的集合。cccskills 不保证其内容的安全性，安装前请务必确认内容。