Menu
セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。
ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する
設計確定後、実装前に使用。設計をタスクに分解し、実装順序と依存関係を明確にする。
大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。
機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。
要件確定後、実装前に使用。メインセッションで人間パートナーと対話しながら設計を深掘りし、合意した設計を design.md にまとめる。
| name | retrospective |
| description | セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。 |
セッションで何が起きたかを振り返り、ハーネスを自己改善する。 感覚ではなく、成果物とユーザ指摘に基づいて改善ループを回す。
入力: セッションの成果物（git log、作成ファイル、テスト結果）+ セッション中のユーザ指摘 出力: ワークフロー遵守レポート + 自己改善提案 + リグレッション確認結果（変更があった場合）
原則: 振り返らないチームは同じ失敗を繰り返す。
振り返りなしにセッションを終えるな
「今回はうまくいったから振り返り不要」→ うまくいった理由がわからなければ次も再現できない。
常に:
トリガー:
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/harness/session-feedback.jsonl に記録する（feedback-recording ルール（.claude/rules/ で自動適用） で規定）{"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/run-eval.mjs で実行振り返り完了前に確認:
| 問題 | 解決策 |
|---|---|
| ワークフローのどこまでやったか追えない | git log のコミットメッセージから再構成する |
| ユーザ指摘が多すぎて整理できない | 種別ごとにグループ化し、影響の大きいものから提案する |
| 改善提案が大量になる | 1セッションで3件以内に絞る。残りは次回以降 |
| eval cases が存在しないスキルがある | リグレッション確認はスキップし、eval cases の作成を提案する |
あなたはこのスキルのプロセスを自分で実行しない。以下のエージェントに順にディスパッチする。
前提: セッションの情報を収集する。ディスパッチ前に以下を取得しろ:
git log --oneline（直近セッション分）git diff --name-only（変更ファイル一覧）session-verifier エージェントをディスパッチする（① セッション検証）
type: manual-edit として .claude/harness/session-feedback.jsonl に記録する.claude/scripts/collect-feedback.mjs を Bash で実行する（② 指摘収集）
node .claude/scripts/collect-feedback.mjs を実行する.claude/harness/session-feedback.jsonl の status: open をフィルタtype: manual-edit）の判定（Claude が同じファイルを触っていたか）applied との再発チェック（種別 + 反映先の一致）needs_classification に含まれるフィードバック（category 未設定）は ③ で LLM が分類するimprovement-proposer エージェントをディスパッチする（③ 自己改善提案）
needs_classification のフィードバックがあれば、まず種別を分類するあなたが結果を判断し、人間パートナーに提示する
applied に更新するeval/run-eval.mjs を Bash で実行しリグレッションを確認する4.5. 観察レビュアーのディスパッチ（Phase 2.5 連携）
.claude/ 配下のファイルを変更した場合harness-user-reviewer エージェントをディスパッチする.claude/ 配下の構造（ディレクトリツリー）meta-observer エージェントをディスパッチする（メタ監視、Phase 4 連携）
.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 集計前提スキル:
必須ルール:
次のステップ:
トリガー:
.claude/hooks/scripts/session-end-retrospective.mjs）このスキルの出力を参照するもの: