| name | process-retro |
| description | エージェント協働開発の「進め方」のポストモーテム。日次は軽く、週次はフルで、その期間の開発プロセス・委譲・レビュー・アーキテクチャ判断を振り返り、仕組み化まで落とす。`/process-retro [daily|weekly]` のほか「今日の進め方を振り返って」「ポストモーテムして」でも起動。成果物そのものの振り返り(何を作ったか)ではなく進め方が対象。 |
process-retro
「何を作ったか」ではなく「どう進めたか」を振り返るポストモーテム。出力は感想ではなく、次の期間に効く仕組みの変更(skill / CI / テンプレート / memory / issue)。
原則
- 事実から始める。印象より先にログを引く。git log・PR / issue・デプロイ履歴・レビュー結果・会話中のユーザー介入を材料にする
- 自分(エージェント)の失敗を最優先で挙げる。ユーザーの指示の問題より、自分の見落とし・確認不足・shrug(謎を通り過ぎた箇所)を先に
- 感想 3 行より仕組み 1 個。「気をつける」で終わる項目は禁止。仕組みに落ちないなら書かない
- brain(外部化された脳)が使える環境では、関連する既存原則を先に引き、矛盾・更新・新規を区別する
材料集め(daily: 会話の記憶で可 / weekly: 必ずログを引く)
git log --oneline --since="<期間>"
gh pr list --state merged --search "merged:>=<日付>"
gh run list --limit 20
加えて会話から: ユーザーが途中で口を挟んだ箇所(方向修正・バグ報告・摩擦の表明)をすべて列挙する。これが最重要の一次データ。
検査レンズ(この順で問う)
- 検出の所在 — この期間の誤り・バグ・手戻りは「誰が / どの層が」見つけたか(人間の目 / テスト / probe / 実機 / 偶然)。人間しか見つけられなかったものは、次の機械化候補。逆に機械が見つけたものは、その投資が正しかった証拠として記録
- レビューの重心 — 人間のレビューはどこで実質的に働いたか(コード diff か、動く成果物か、文章か)。0 コメント承認が続く儀式はないか。人間の注意という最希少資源が、いちばん効く面に向いているか
- 可逆性の使い分け — 速く出したものは本当に安く戻せたか。戻れない変更(認可・データ・公開)に速いレーンを使った瞬間はなかったか
- 委譲の境界 — メイン / 実装エージェント / 調査エージェントの分担でロスした箇所(同一ファイルの競合待ち、過剰・過少委譲、コンテキスト不足の手戻り)
- 制度化の回収率 — 期間中に表明された摩擦(ユーザーの「〜だといいのに」を含む)のうち、仕組みに落ちた割合。落ちなかったものはどこに消えたか
- 未解明の謎 — 原因不明のまま通り過ぎた異常(消えたファイル、二重実行、飛んだ番号)。shrug は事故の前兆として必ず再掲する
- 散文の検証 — コードはテストが守るが、ドキュメント・ガイド・issue の「挙動の記述」は誰が検証したか。実装と食い違った記述はなかったか
出力
- keep / change 各 3 個以内。change は必ず具体的な仕組み(issue 起票 / skill 追加・修正 / CI・テンプレ変更 / memory 追記)とセット
- 記録先の振り分け: プロジェクト固有 → repo の issue か docs、横断的な進め方 → skill / memory、再利用される判断基準・原則 → brain-capture を提案(勝手に書かず提案する)
- daily は 15 分・レンズ 2〜3 個に絞ってよい。weekly は全レンズ + 前回の change の追跡(やったか / 効いたか)から始める
アンチパターン
- KPT の Problem に「時間が足りなかった」系の環境要因だけ並べる
- エージェントの成功列挙(自己満足)。成功は keep 判断に必要な分だけ
- 仕組み化 action が「ドキュメントに書く」に偏る(読まれない)。順序は CI・lint > テンプレ・skill > memory > ドキュメント