Menü
セッション完了後の振り返りに使用。ワークフロー遵守の検証、ユーザ指摘の収集と自己改善提案、改善後のリグレッション確認を行う。
Mit Codex oder Claude installieren Kopieren Sie diesen Prompt, fügen Sie ihn in Codex, Claude oder einen anderen Assistant ein und lassen Sie die Skill-Seite prüfen und installieren.
Basierend auf der SOC-Berufsklassifikation
| 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）このスキルの出力を参照するもの:
実装完了後のコードレビューに使用。仕様準拠・コード品質・セキュリティの3観点を並列レビューし、指摘を依存解決して修正する。
ワークフローを開始する。ユースケースを選択し、適切なステップを順に実行する
設計確定後、実装前に使用。設計をタスクに分解し、実装順序と依存関係を明確にする。
大規模プロジェクト（複数機能・フェーズ分割が必要）で使用。全体をフェーズに分割し、マイルストーンとリスクを定義する。各フェーズは planning スキルに渡す。
機能開発・バグ修正の着手前に使用。メインセッションで人間パートナーと対話し、要件を構造化する。コード調査は Explore エージェントに委譲。
要件確定後、実装前に使用。メインセッションで人間パートナーと対話しながら設計を深掘りし、合意した設計を design.md にまとめる。