backlog(atoms/pipeline/outputs)と skill ヘルス(usage/duration/unused)を統合分析し 1 レポートで提示する。kawai 氏型 analytics ループの起点。「次に何やる?」「atom 整理」「放置案件」「stale」「振り返り」「retro」「skill 使用統計」「unused skill」「atom-suggest」で発動。
handoff
EC2 など別マシンへのセッション引き継ぎが第一用途。現セッションの Recap(LLM 要約)と Next Actions を VCS 共有可能な `.claude/journal.md` の先頭に追記する。ローカル端末固有で他マシンから見えない built-in `/recap` の限界を補う。
同一マシン内のセッション区切りにも使える。「EC2 に引き継ぎ」「別マシンに渡したい」「handoff」「ハンドオーバー」「journal に残して」「新セッションに渡したい」「新しい会話を始めたい」「セッションを区切りたい」で発動。
含まれるファイル(1)
- SKILL.md6.7 KB
SKILL.md(原文)
インストールする前に、エージェントに与えられる指示の中身を確認できます。
Handoff - EC2 / 別マシン引き継ぎの中核
このスキルは EC2 A → EC2 B のような跨マシン引き継ぎのための中核機能。
現セッションの Recap と Next Actions を .claude/journal.md に追記し、
VCS(jj / git)で別マシンに同期する。
Claude Code built-in /recap は優秀だが ローカル端末固有(別マシンからは見えない)。
このギャップを埋めるのが handoff。journal.md は .gitignore で無視される chronicle / context
と違い、明示的に VCS で共有 される唯一のセッション履歴。
同一マシン内の「セッションを区切りたい」用途でも使えるが、その場合は /recap と
併用する前提(journal は跨マシン共有のソースオブトゥルース)。
いつ使うか
第一用途(跨マシン引き継ぎ):
- EC2 A で作業中にリソース切れ・時間切れ → EC2 B で続きを再開
- 自宅 PC → 会社 PC に作業を渡す
- チームメンバーに状況を引き継ぐ(VCS で共有可能)
副次用途(同一マシン):
- 長いセッションでコンテキストが圧迫されてきた(compaction を待たずに区切りたい)
- タスクの区切りで新しいセッションに切り替えたい
- 後から参照したい「判明した事実 + 次の一手」をアーカイブ化したい
Step 1: Recap + Next Actions の要約(自己内省)
これまでの会話を振り返り、2 つの情報 を要約する。transcript パースには 依存せず、あなた自身の会話理解で書く。
1A: Recap(2〜4 文)
- 現セッションで 何をしたか / 何が判明したか / どこで止まっているか
- built-in
/recap相当のクオリティ。Intent / Outcomes / Blockers を自然文で - 別マシンから Read しても文脈が分かるレベルで書く
- 「作業を進めた」のような抽象表現は避ける。具体的なファイル名・発見を入れる
1B: Next Actions(1〜5 件、箇条書き)
- 次のセッションでやるべき具体的アクション
- ファイル名・関数名・コマンド名レベルで具体的に書く
- 「あれをやる」ではなく「
hooks/foo.shのbar関数を X に書き換える」 - 該当なし(本当に何もない)場合は AskUserQuestion で確認。
AskUserQuestion が使えない環境では
- (未指定)1 行で記録して進む
Step 2: タイムスタンプとホスト名の取得
date '+%Y-%m-%d %H:%M'
hostname -s
hostname -s が失敗 or 空の場合はホスト識別を省略して続行(EC2 識別は nice-to-have)。
Step 3: journal.md の先頭に追記
ファイルパス: .claude/journal.md
新エントリのフォーマット
ホスト名が取得できた場合:
## <timestamp> [<hostname>]
### Recap
<Recap 本文>
### Next
- <action 1>
- <action 2>
ホスト名が取れなかった場合:
## <timestamp>
### Recap
<Recap 本文>
### Next
- <action 1>
- <action 2>
ファイルが存在しない場合
以下のヘッダー + 新エントリで新規 Write:
# Journal
> セッション間の引き継ぎ。最新が上。Recap を時系列アーカイブとして保持し、
> 次のアクションを明示する。詳細なセッション内要約は built-in `/recap` も併用。
## <timestamp> [<hostname>]
### Recap
...
### Next
- ...
ファイルが存在する場合
.claude/journal.mdを Read する- 最初に現れる
##行(既存エントリの先頭)の位置を探す - その行の 直前 に新エントリブロックを挿入する
- 結合後の全文で Write する
既存エントリは削除・編集しない。単に上に積み上げる。
実装上の注意
- ヘッダー(
# Journal+> ...+ 空行)がファイルに存在しない(手動編集された)場合、 先頭に##行があればそのまま prepend、なければヘッダーから作り直す - 空ファイルは「存在しない」と同じ扱いで新規作成
- サイズ上限・ローテーションはしない。VCS で管理する想定
### Recapと### Nextの順序は固定(この順で書く)
Step 4: ユーザーへの出力
以下のメッセージを表示:
✅ Handoff 完了
📋 .claude/journal.md の先頭に Recap + Next Actions を追記しました。
同一マシンでの再開:
cd <current working dir>
claude
- SessionStart hook が journal.md の最新エントリを自動表示
- セッションを resume する場合は built-in `/recap` も併用可
別 EC2 / マシンでの再開:
1. VCS で journal.md を同期(jj git push → 別マシンで jj git pull)
2. cd <current working dir>
3. claude を起動 → SessionStart が最新 Recap + Next を表示
💡 未コミットの変更がある場合は、handoff 前に jj describe を推奨。
<current working dir> は pwd の結果で置換。
Gotchas
- Recap は LLM 要約の品質で: /recap レベルで書く。「作業を進めた」ではなく 「X ファイルの Y 関数に Z のバグを発見し〇〇で対応した」
- Next Actions は具体的に: 「あれをやる」ではなく「ファイル X の関数 Y を Z に変える」
- transcript パースに依存しない: 自分の会話理解で書く。jq 等は使わない
- 既存エントリは保持: マージせず prepend するだけ。上書きしない
- 0 件 Next での呼び出し: AskUserQuestion で確認。使えない環境では
- (未指定)で記録 - hostname 取得失敗時: ホスト識別なしで進む。EC2 識別は EC2 間連携の補助情報
- Recap と Next の役割分担: Recap は過去志向(何をしたか)、Next は未来志向(何をするか)
Step 1 の自己内省から開始してください。
レビュー
まだレビューはありません。使ってみた感想をお寄せください。
同じリポジトリのスキル
概要と使いどころ
要件が曖昧なとき、ソクラテス式に1問ずつ質問して要件を掘り下げる。十分に明確になったら discovery-council にハンドオフ。「要件が曖昧」「何を作ればいいか」「掘り下げて」「インタビューして」で発動。※ 完成した plan/design を詰問するなら grill、非対話で一括批判するなら critic。
designer エージェントによるアーキテクチャ設計。requirements.md を基に design.md を作成。「設計して」「アーキテクチャ設計して」「アーキテクチャを考えて」「設計書を作って」で発動。
3エージェント(researcher, analyst, scout)による並列要件分析 Council。peer-to-peer で相互検証し requirements.md を確定。「要件を整理して」「要件定義して」「現状分析して」「要件をまとめて」で発動。
技術記事の並列レビュー Council。anti-ai-slop / fact-checker / narrative-critic / reader-advocate を並列 spawn、severity 付き findings を最大3ラウンドで収束。Zenn などのドラフト完成後に使う。「記事レビュー」「editorial swarm」「編集会議」「記事推敲」「記事添削」で発動。
スキルの自己進化。auto-memory と実行履歴から学びを抽出し、各スキルの Gotchas セクションに自動追記する。セッション終了前、定期的な改善サイクル、問題に遭遇した後に使う。「スキルを進化させて」「学びを反映して」「Gotchas を更新」「evolve」で発動。