retrospective

name	retrospective
description	開発サイクル完了時（実装・レビュー・追加修正まで済んだ後）に使用。教訓の抽出・残タスクの振り分け・RETROSPECTIVE.md 更新を行う。
disable-model-invocation	true
argument-hint	[対象ブランチ名や作業の概要（省略時は現在のブランチの差分を使用）]
allowed-tools	["Bash(git *)","Bash(gh *)","Read","Edit","Write","Grep","Glob"]

開発サイクルの振り返りを行う。質問せず自律的に進めること。

対象: $ARGUMENTS

Step 1 — サイクルの全体像を把握

git log main..HEAD --oneline
git diff main..HEAD --stat

• 変更したファイル・コミット履歴からサイクルの全体像を把握する
• workspace/plan.md があれば読み、当初の計画と実際の実装を比較する
• PR のコメントやレビュー指摘があれば gh pr view で確認する

Step 2 — 振り返りの分析

以下の3観点で分析する:

よかったこと

• 計画通りに進んだ点、うまくいった判断
• 効果的だったパターンや手法

伸びしろ

• 手戻り・追加修正が発生した箇所とその原因
• 見落としていた影響範囲やエッジケース
• 次回同じ状況で改善できる点

構造的パターンの抽出（「どのトリガーで必要になるか」で分類する）

各教訓について「これは何をした瞬間に必要になるか」を問う（実際の配置先は Step 3 の階梯で決める）。既定で AGENTS.md に足さない——トリガーを持つ教訓は、そのトリガーに紐づく文書へ置く:

• 機械判定できる違反（型・compile・出力形式の逸脱） → 機構（compile-fail・#[must_use]・hook・test）の候補
• 特定ファイル/パスを触るときの注意 → .claude/rules/ の候補
• 特定の作業局面（対称ペア変更・網羅列挙・状態追加・永続形式変更 等）の注意 → 該当スキルの候補
• 汎用の設計・デバッグ判断基準 → docs/development-principles.md の候補
• どのトリガーにも紐付かない、書く・判断するたびに効く横断原則 → AGENTS.md「検証の作法」の候補
• ワークフローステップ自体が機能しなかった・足りなかった → スキルの更新候補（実際に更新するかはユーザーと相談する）

Step 3 — 教訓の配置（トリガーに括り付ける）

Step 2 で抽出した構造的パターンのうち、今後のサイクルで繰り返し参照する価値があるものを、その教訓が必要になるトリガーに紐づく文書へ置く。AGENTS.md 常時ロードへの追加は既定でも第一候補でもなく、最後の手段である——真に横断的でトリガーを持たない原則だけがそこに値する。単発の出来事ではなく、再発しうるパターンのみ配置する。

上の段から順に検討する（docs/development-principles.md「構造的設計原則と強制の階梯」と AGENTS.md 冒頭の組織原理に対応）:

1. 機構が吸収できるか（最上段）: compile-fail・#[must_use]・hook・テストで違反を検出、または構造で不能にできるなら、教訓は「注意書きの追加」ではなく**「機構の追加・強化」**にする。AGENTS.md・各 CLAUDE.md に専用チェックリストや注意書きが要る箇所は「構造が規則を吸収できていない」診断信号である。カナリアで守るのは沈黙する経路だけでよい（放っておいても明示的に失敗するものに見張りは要らない）
2. 特定ファイル/パスを触ると効くか → .claude/rules/<X>.md（対象を読むと自動配送される）。既存 rule の paths: に該当するなら本文へ追記、しなければ新設（新設時はカナリア要否を判断）
3. 特定の局面・作業で効くか → 該当スキル（/symmetric-check・/plan-review・/state-check・/cache-check・/persistence-check・/dry-check・/race-check 等）の本文へ。AGENTS.md には「条件別チェック」表に「トリガー → 参照先」の 1 行だけ足す（本文の SSOT は skill 側）
4. 汎用の設計・デバッグ原則か → docs/development-principles.md
5. モジュール固有 → 各サブディレクトリ CLAUDE.md（src-tauri/・snotra-core/・snotra-settings/・snotra-egui-runtime/）／Claude Code 固有（コミュニケーション原則・スキル表・委譲/worktree 運用） → ルート CLAUDE.md
6. どのトリガーにも紐付かない、書く・判断するたびに効く横断原則だけ → AGENTS.md「検証の作法」コア。ここだけが常時ロードに値する

検収条件: AGENTS.md が重くなる方向の変更は smell として扱う。ドキュメントが軽くなることを設計改善の検収条件とする（構造が規則を吸収したら対応するチェックリストは削除する）。既存ルール・既存のトリガーで包含できるなら追記しない。同じ教訓の本文を 2 箇所に書かない——AGENTS.md はポインタ、本文はトリガーに紐づく文書に 1 つ（ドリフト防止）。

Step 4 — 残タスクの振り分け（issue / PR）

RETROSPECTIVE.md は上書きファイルであり、サイクルを越えて生き残るタスクを置くと次サイクルの上書きで失われる。Step 2 で洗い出した「実行が必要な項目」のうち、Step 3 で教訓として配置しきれなかったもの（＝ドキュメント化でなく実行を要するもの）を、以下の追跡先へ振り分ける（RETROSPECTIVE.md には残さない）:

• PR のライフサイクル内で閉じるタスク（push・ラベル付与・CI グリーン確認・手動マージ 等）→ 対象 PR 本文のチェックリストに追記する（gh pr edit --body 等）。PR が merge されれば自然に閉じる
• サイクル/PR を越えて生き残るタスク（follow-up・別リファクタ・繰越・要設計）→ GitHub issue を起票する（gh issue create）。迷ったら永続側＝issue を選ぶ

既に完了済みのタスク（merge 済み PR の手順など）は振り分け不要。振り分けた issue 番号 / PR チェックリストは出力に記録する。

Step 5 — RETROSPECTIVE.md の上書き（教訓のみ）

Step 3・Step 4 が完了してから、RETROSPECTIVE.md を以下の 2 セクションフォーマットで上書きする。タスク（ネクストアクション）は Step 4 で振り分け済みのため含めない:

# Retrospective — <サイクルの概要>

## よかったこと

### <見出し>
<説明>

---

## 伸びしろ

### <見出し>
<説明>

• 前回の内容は上書きする（追記しない）
• 実行タスク・未完了項目は書かない（Step 4 で issue / PR へ振り分け済み）
• 他文書の見出しを引くときは正準形 `<対象>`「<見出し>」 で書く（.claude/rules/governance-docs.md）。RETROSPECTIVE.md は G11 の母集団に入っており、上書きのたびに参照の形が決め直される——ここで散文形に戻すと、着地の照合が毎サイクル失われる

Step 6 — メモリの鮮度チェック

サイクルで変更した内容に関連するメモリが MEMORY.md に存在するか確認する。

MEMORY.md はリポジトリ外にある（所在と委譲規約は .claude/skills/health-check/SKILL.md の Check 7 を SSOT とする）。

1. MEMORY.md を読み、各メモリファイルの説明を確認する
2. サイクルの変更内容と関連するメモリを探す。索引の description で関連性を判断してはならない — 今サイクルで覆した前提・変更した設定・仕様変更のキーワードと概念名で、メモリ本文を grep する（description は本文の派生要約であり、古びた一文がそこに現れるとは限らない。手順の SSOT は health-check の Check 7d）
3. 該当したメモリはファイルを読み、内容が現在のコードベース・ドキュメントと矛盾していないか検証する
4. 矛盾するメモリは更新または削除する（MEMORY.md のインデックスも同期）
5. サイクルで得た知見のうち、将来の会話で有用なものがあればメモリに追加する

判断基準: メモリは「コードやドキュメントから読み取れない、セッション横断で有用な情報」のみ保持する。コードの構造やパターンは AGENTS.md / 各 CLAUDE.md の責務。

Step 7 — サイクル末の health-check

サイクル末の衛生チェックを実施する（実行責任は /retrospective が負う）。/health-check は user 起動専用（disable-model-invocation）でスキルからは起動できないため、その定義 .claude/skills/health-check/SKILL.md に従い、npm run governance:check の実行（赤は発見事項）と、機械化されていない検査（Check 5 の残置部分・Check 7）を本スキルの責任で実施する（＝/health-check を起動しない、という意味である。実行方式はインライン／サブエージェントへの委譲のいずれでもよい）。

サブエージェントへ委譲する場合、Check 7 にはメモリ領域の絶対パスをプロンプトへ明示的に渡す（サブエージェントは system prompt を継承しないため、渡さなければ MEMORY.md を見つけられない）。渡さないなら Check 7 は [Skipped] であり、Skipped が残るまま「All checks passed」と報告しない（#489）。

health-check は「報告のみ・修正しない」定義のため、発見事項の処理は本スキルが担い、Step 3・Step 4 の方針に従って振り分ける:

• doc ドリフト（CLAUDE.md モジュール構成・参照リンク・SPEC.md 番号・スキル表 等）→ その場で該当ドキュメントを修正する（Step 3 と同じ方針）
• 実装・大規模対応が要るもの → GitHub issue を起票する（Step 4 の振り分け）
• PR 内で閉じられるもの → 対象 PR 本文へ追記する（Step 4 の振り分け）

出力

以下を報告:

1. サイクルの概要（1〜2行）
2. ドキュメントに反映した教訓（あれば、どのファイルに何を追加したか）
3. 振り分けたタスク（起票した issue 番号 / 追記した PR 本文チェックリスト）
4. メモリの更新（あれば、追加/更新/削除したメモリ）
5. health-check の結果サマリ（発見事項・Skipped とその処理・根拠）。カテゴリ定義は health-check の出力形式（.claude/skills/health-check/SKILL.md）を SSOT とする——根拠は発見事項でも Skipped でもない実行の証跡で、governance:check の出力（照合母集団の件数行）・Check 7 の実在列挙などが該当する（発見事項カウント・All checks passed 判定には算入しない）