Claude Codeでまとまった作業をしたあと、セッションの中に出てきた学びやissueが埋もれがちだったので、close-out-retroというスキルを作った。
やること
3つ。
- セッション中の学びを、Claudeの記憶かプロジェクトのドキュメント（
CLAUDE.md等）のどちらかに振り分ける - 見つけたが直していないバグ・課題をissueトラッカーと突き合わせて、起票を提案する
- 同じ手順を何度も手でやっていた場合など、実際にシグナルがあったときだけ新しいスキル/エージェントを提案する
1. 学びの振り分け
「このユーザー・プロジェクトとの協働の仕方」に関する話は記憶へ、「コードやシステムそのもの」の話はプロジェクトのドキュメントへ、という基準で振り分ける。ドキュメントに書いた内容を記憶側に古いまま残さないようにもしている。
2. 未着手issueの棚卸し
作業の副産物として見つかったが直していないバグや課題を、issueトラッカーと突き合わせる。新規で確認が取れたものだけ起票を提案する。
確信の持てないものは確定した不具合として書かない。「たぶんバグかもしれない」くらいのものは、そう伝えるだけにして、起票するかどうかはユーザーに任せる。
3. スキル/エージェントの提案
以下のようなことがあったときだけ提案する（作成はしない）。
- 同じ手順を2回以上手で繰り返した
- ユーザーが「毎回面倒」と言った
- 既存のスキルが本来当てはまるはずなのに発火しなかった
毎回「スキルを作りますか?」と聞くようなことはしていない。
実行例
架空のAPI acme-widgets にレート制限を追加した後、というシナリオ。
> /close-out-retro
## 1. 学び
- [記憶] レート制限の設定は環境変数ではなく`config/limits.yml`に置くのが好み、との指摘。
理由は運用チームが再デプロイ無しで制限値を変更できるようにするため。
- [ドキュメント → CLAUDE.md] ワーカーの再起動順序が重要。設定パッチを当ててから
`worker restart`する必要がある。逆順だと1サイクルの間だけ古い制限値が残る。
## 2. 未着手issue
- `test/quota_test.py::test_burst`が1回失敗。今回の変更とは無関係で、タイミング起因の
不安定テストに見えるが未確認。起票はせず判断はお任せする。
## 3. スキル/エージェントの兆候
- 「クォータ確認→設定パッチ→ワーカー再起動→検証→リリースタグ付け」を3回手動で繰り返した。
`acme-widgets`固有のツールに依存するので、プロジェクトスコープのスキル`quota-rollout`を
提案する。
架空の例で、実プロジェクトのデータは使っていない。
似たものは既にあった
調べたところ、以下のようなものが既にあった。
-
netresearch/retro-skill: セッションの学びを記憶/プロジェクトルール/スキルPRに振り分ける
/retroコマンド。1番目にかなり近い。issueの棚卸しは無い。 -
melodykoh/learning-loop-skill:
CLAUDE.md/MEMORY.md/「Judgment Ledger」に振り分けるscan/wrap-up構成。こちらも1番目に近い。 -
echolimitless氏のQiita記事: セッションのログからパターンを抽出し、
CLAUDE.mdや新規スキルへ昇格させる3層の記憶アーキテクチャ。1番目とかなり重なる。
1番目（学びの振り分け）自体は新しくないと思う。調べた範囲で見当たらなかったのは2番目（issueトラッカー側からの棚卸し）だった。close-out-retroはこの2番目と、提案止まりの3番目を組み合わせたもの。
使い方
mkdir -p ~/.claude/skills/close-out-retro
curl -o ~/.claude/skills/close-out-retro/SKILL.md \
https://raw.githubusercontent.com/ryo823/close-out-retro/main/SKILL.md
作業の終わりに/close-out-retroと呼びかけるか、「これで締めよう」のように話しかければ発火する。仕様はSKILL.mdを参照。MITライセンスなので自由に改変してもらって構わない。
以上です。