| name | retrospective |
| description | セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。 |
Retrospective（振り返り）
概要
セッションで何が起きたかを振り返り、ハーネスを自己改善する。
感覚ではなく、成果物とユーザ指摘に基づいて改善ループを回す。
入力: セッションの成果物（git log、作成ファイル、テスト結果）+ セッション中のユーザ指摘
出力: ワークフロー遵守レポート + 自己改善提案 + リグレッション確認結果（変更があった場合）
原則: 振り返らないチームは同じ失敗を繰り返す。
Iron Law
振り返りなしにセッションを終えるな
「今回はうまくいったから振り返り不要」→ うまくいった理由がわからなければ次も再現できない。
いつ使うか
常に:
- コミット・PR（[11]）が完了した後
- セッション終了時
トリガー:
- SessionEnd フックがリマインダーを表示（スキル自体の自動実行ではない）
プロセス
digraph retrospective {
rankdir=TB;
input [label="セッション完了", shape=ellipse];
verify [label="① セッション検証\nワークフロー遵守チェック", shape=box, style=filled, fillcolor="#cce5ff"];
collect [label="② 指摘収集\nユーザ修正の棚卸し", shape=box, style=filled, fillcolor="#ccffcc"];
propose [label="③ 自己改善提案\nスキル・ルールへの反映案", shape=box, style=filled, fillcolor="#ccccff"];
apply [label="人間承認\n→ 改善を適用", shape=box, style=filled, fillcolor="#ffffcc"];
validate [label="④ 改善評価\neval cases で\nリグレッション確認", shape=box, style=filled, fillcolor="#e6ccff"];
done [label="振り返り完了", shape=ellipse];
input -> verify;
verify -> collect;
collect -> propose;
propose -> apply;
apply -> validate;
validate -> done;
}
① セッション検証（「ワークフローを守ったか？」）
git log とセッションの成果物から、ワークフロー [1]〜[11] の各ステップを実施したかを確認する。
| ステップ | 確認方法 |
|---|
| [1] 要件理解 | requirements/REQ-*/requirements.md が存在するか |
| [2] 設計 | docs/design/ に設計書が存在するか |
| [3] 計画 | docs/plans/ に実装計画が存在するか |
| [4][5] 実装・テスト | テストファイルが存在し、全 GREEN か |
| [6] リファクタ | simplify の実施痕跡（コミット履歴） |
| [7] 品質テスト | TQ-* テストが追加されているか |
| [8] レビュー | 3観点レビューの実施痕跡 |
| [9] 検証 | 検証報告書の存在 |
| [10] 整理 | デバッグコード・一時ファイルが残っていないか |
| [11] コミット | コミットメッセージが適切か |
例外の扱い: 人間パートナーが明示的にスキップを承認したステップは「スキップ（承認済み）」として記録する。未承認のスキップだけを問題として報告する。
② 指摘収集（「ユーザが何を直したか？」）
.claude/harness/session-feedback.jsonl に記録されたフィードバックのうち、status: open のものを収集・分類する。
フィードバックの記録方式
セッション中のフィードバックは 2つの方式 で自動記録される:
- ルールによる自己記録 — ユーザに指摘・修正されたことを Claude 自身が認識し、即座に
.claude/harness/session-feedback.jsonl に記録する（feedback-recording ルール（.claude/rules/ で自動適用） で規定）
- hook による自動検知 — ツール拒否（PreToolUse で deny）、同一ファイルの再編集（PostToolUse で追跡）を自動で記録する（将来実装）
フィードバックの形式
{"id":"fb-001","timestamp":"2026-04-01T08:30:00Z","status":"open","type":"correction","category":"scope","summary":"cleanup-agentのスコープにlint除外を追記","user_said":"コード整理はlintの仕事でしょ？","affected":".claude/agents/cleanup-agent.md","session_id":"..."}
| フィールド | 説明 |
|---|
id | フィードバック ID（fb-XXX） |
status | open → proposed → applied |
type | correction（修正）/ rejection（拒否）/ clarification（明確化） |
category | scope（責務越境）/ spec（仕様漏れ）/ assumption（前提ミス）/ design（過剰設計）/ naming（命名） |
summary | 指摘の要約 |
user_said | ユーザの発言（原文） |
affected | 反映先のファイルパス |
フィードバックのライフサイクル
open → feedback-collector が収集対象にする
proposed → improvement-proposer が改善提案を作成済み
applied → 改善が適用・コミットされた（applied_commit を付与）
open のみ retrospective の対象applied は蓄積し、同じ種別の再発検知に使う- 溜まりすぎたら
applied を .claude/harness/session-feedback-archive.jsonl にアーカイブ
指摘の種別
| 種別 | 例 |
|---|
スコープ誤り（scope） | 「コード整理は lint の仕事でしょ？」→ 責務の越境 |
仕様漏れ（spec） | 「REQ の値渡されてる？」→ 入力仕様の欠落 |
前提ミス（assumption） | 「claude code でやりや」→ 実行環境の前提ミス |
設計判断の修正（design） | 「それは重すぎる、シンプルにして」→ 過剰設計 |
命名の修正（naming） | 「eval じゃなくて retrospective にして」→ 命名の不適切 |
③ 自己改善提案（「次から自動で守れるようにする」）
収集した指摘を、スキル・ルール・エージェントへの具体的な変更提案に変換する。
## 改善提案
### 提案1: cleanup-agent のスコープに lint 除外を明記
- 種別: スコープ誤り
- 指摘: 「コード整理は lint の仕事」
- 反映先: .claude/agents/cleanup-agent.md
- 変更内容: lint/formatter が扱う項目を除外リストに追加
- 根拠: lint で自動矯正できるものは AI が扱わない（coding-style.md 準拠）
### 提案2: 全スキルの入力に REQ パスを明示
- 種別: 仕様漏れ
- 指摘: 「REQ の値渡されてる？」
- 反映先: 全スキル・全エージェントの入力セクション
- 変更内容: REQ パス（例: requirements/REQ-001/）を入力の先頭に追加
人間承認が必要。 提案を人間パートナーに提示し、承認を得てから適用する。
④ 改善評価（「変更で壊れていないか？」）
③ で変更を適用した場合のみ実施する。
- 変更したスキル・ルールに対応する eval cases を
eval/run-eval.mjs で実行
- 変更前後の遵守率を比較
- リグレッションがあれば報告
検証チェックリスト
振り返り完了前に確認:
行き詰まった場合
| 問題 | 解決策 |
|---|
| ワークフローのどこまでやったか追えない | git log のコミットメッセージから再構成する |
| ユーザ指摘が多すぎて整理できない | 種別ごとにグループ化し、影響の大きいものから提案する |
| 改善提案が大量になる | 1セッションで3件以内に絞る。残りは次回以降 |
| eval cases が存在しないスキルがある | リグレッション確認はスキップし、eval cases の作成を提案する |
委譲指示
あなたはこのスキルのプロセスを自分で実行しない。以下のエージェントに順にディスパッチする。
前提: セッションの情報を収集する。ディスパッチ前に以下を取得しろ:
git log --oneline（直近セッション分）git diff --name-only（変更ファイル一覧）
-
session-verifier エージェントをディスパッチする（① セッション検証）
- プロンプトに git log + 変更ファイル一覧を含める
- セッション中に Claude が Edit/Write したファイルと git diff の差分を突き合わせ、人手修正を検知する
- 人手修正があれば
type: manual-edit として .claude/harness/session-feedback.jsonl に記録する
- ワークフロー [1]〜[11] の遵守状況を確認し、遵守レポートを出力する
-
.claude/scripts/collect-feedback.mjs を Bash で実行する（② 指摘収集）
node .claude/scripts/collect-feedback.mjs を実行する- スクリプトが決定的処理を行う:
.claude/harness/session-feedback.jsonl の status: open をフィルタ- 人手修正（
type: manual-edit）の判定（Claude が同じファイルを触っていたか）
- 過去
applied との再発チェック（種別 + 反映先の一致）
- 結果は JSON で stdout に出力される
needs_classification に含まれるフィードバック（category 未設定）は ③ で LLM が分類する
-
improvement-proposer エージェントをディスパッチする（③ 自己改善提案）
- プロンプトに ① の遵守レポート + ② のスクリプト出力（JSON）を含める
needs_classification のフィードバックがあれば、まず種別を分類する- 最大3件の改善提案を作成する
- コンテキストはプロンプトに全文埋め込む。 エージェントにファイルを読ませるな
-
あなたが結果を判断し、人間パートナーに提示する
- 遵守レポート + 改善提案を提示し、承認を得る
- 承認された改善を適用し、フィードバックの status を
applied に更新する
- 変更があった場合、④ 改善評価として
eval/run-eval.mjs を Bash で実行しリグレッションを確認する
4.5. 観察レビュアーのディスパッチ（Phase 2.5 連携）
- 条件:
.claude/ 配下のファイルを変更した場合
harness-user-reviewer エージェントをディスパッチする- プロンプトに以下を含める:
.claude/ 配下の構造（ディレクトリツリー）- 直近のセッションで発生したフィードバック（session-feedback.jsonl の open/applied）
- harness-user-reviewer の finding は observation-log.jsonl に自動追記される
meta-observer エージェントをディスパッチする（メタ監視、Phase 4 連携）
- 条件: 直近3セッション以内に meta-observer を実行していない場合のみ。毎セッション実行しない
- プロンプトに以下を含める:
.claude/harness/observation-points.yaml の現在内容.claude/harness/observation-log.jsonl の直近 50 件.claude/agents/product-user-reviewer.md と .claude/agents/harness-user-reviewer.md の「観点」セクション.claude/harness/session-feedback.jsonl の直近 20 件の category 集計
- meta-observer の提案を人間パートナーに提示する
- 承認された提案は observation-points.yaml と対応 L2 エージェントに反映する
Integration
前提スキル:
- commit — コミット完了後（通常フロー）
- なしでも実行可（セッション途中の振り返りも可能）
必須ルール:
- feedback-recording — セッション中のフィードバック記録（データソース）
次のステップ:
- harness-contribute — 改善をハーネスリポジトリに還元する場合
トリガー:
- SessionEnd フック — セッション終了時にリマインダーを表示（
.claude/hooks/scripts/session-end-retrospective.mjs）
このスキルの出力を参照するもの:
- improvement-proposer エージェント — 改善提案の作成
- 改善提案は次セッション以降のスキル・ルール・エージェントに反映される
- ワークフロー遵守レポートはチームの改善指標として蓄積される
