| 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 > ドキュメント
