reflect

振り返り

成功基準

• すべてのミスや摩擦点について、発生した具体的な場面とその影響を示します
• 調査結果には、レビューした証拠の限界を明記します。不足している観察から、成功や網羅性が確立されたとは判断しません
• 改善策は実行可能で、優先順位が付けられています（上限はステップ 4 で定義）
• 各スキル監査では、測定可能な変更を提案します（曖昧な提案はしません）
• メモリへの永続化は既存の承認に従うか、書き込み前にユーザーが具体的な提案項目を選択します
• レビュー作業を行った場合は、レビューの落とし穴となる候補を報告します。承認を得てから永続化するか、候補がないことを明示します

プロセス

1. セッションレビュー

確認可能な会話と関連する成果物を調査します。不足または途中で切れている証拠と、実際にレビューした範囲を明示します。各所見について、具体的なやり取りまたは成果物（引用または言い換え）を示し、その影響を説明します。記録に欠落があるからといって、問題のないセッションだったと推測してはいけません。

カテゴリ	シグナル
ミス	誤った出力、不正確な前提、事実の捏造
摩擦	繰り返しの確認、冗長な応答、意図の読み違い
無駄な労力	破棄された作業、最初に試した誤ったアプローチ
成功	繰り返す価値のあるアプローチ、円滑なやり取り

一度限りのタイプミス、外部ツールの障害、エージェントの制御外の問題は除外します。

推測した行動から永続的な指針を提案する前に、capture-and-routing.md にある再発判定基準と例外を適用します。

2. レビュー活動のスキャン（該当する場合）

候補を応答に記載します。振り返りだけでは、メモリへの書き込みやスキルの編集は承認されません。ステップ 4 と 5 ですでにユーザーから承認された変更、または承認を得た変更のみを適用します。

セッション中に、どちらの立場であっても PR または MR のレビュー活動があった場合は、先に進む前にこのスキャンを実行します。レビューがなかった場合に限り、スキップします。

受けたレビュー（自分のコードがレビューされた場合）： 受け取った各レビューコメントについて、次を確認します。

• 指摘を受け入れましたか？受け入れた場合、レビュー担当者は自分が見落としたどのようなパターンに気付きましたか？それは繰り返し発生する盲点ですか？ステップ 4 向けに、1 行のメモリ候補を提案します。
• 反論しましたか？自分が正しくレビュー担当者が誤っていた場合、記録することはありません。自分が誤っており、スレッドの途中で訂正した場合は、学んだことを記録します。

行ったレビュー（他者のコードをレビューした場合）： 自分が投稿した各コメントについて、次を確認します。

• コメントは受け入れられましたか？記録することはありません。適切な指摘でした。
• 有効な反論を受けて却下されましたか？それはレビューの落とし穴です。誤ったコメントにつながったヒューリスティックと、そのパターンを記録します。

「収集対象なし」も妥当な結果です。その場合は明示してください。このステップを黙って省略してはいけません。

3. 運用上の学び

改善点を列挙する前に、セッションを確認し、残しておく価値のある運用上の知見がないか調べてください。5分フィルターを適用します。これを知っていれば今後のセッションで5分以上節約できますか？ できる場合は含めてください。たとえば、プロジェクト固有の癖、プロジェクト固有の理由で失敗したプロジェクトのコマンド、予想以上に効果があった方法などです。

確認した記録にコマンドの実行と関連する成功結果が含まれている場合に限り、そのコマンドを動作確認済みとして記載してください。その結果を再現するために必要なリビジョンと環境条件を残してください。出力のない成功の主張は、未検証として扱ってください。

ハーネスレベルのノイズ（「File has not been read yet」、トークン制限による途切れ、Bash のクォートミス、その他のツール由来のアーティファクトなど）は除外してください。これらはプロジェクトの学びではありません。エージェントの動作ではなく、プロジェクトの挙動を記録してください。

さらに、情報へのアクセス不足も確認してください。エージェントが人間なら確認できたはずのもの（開発サーバーのログ、サードパーティのダッシュボード、ステージングデータベース、CI の出力など）を読み取れず、セッションが停滞したり、推測したりした箇所を探します。これは前述のハーネスノイズとは異なります。一時的なツールの不具合は再利用できる知見ではありませんが、恒常的なアクセス不足は、アクセスを許可することで今後のすべてのセッションに効果があるため、記録する価値があります。こうした不足はそれぞれ改善候補です（「X への読み取り専用アクセスを許可する」や「エージェントが読み取れるファイルに X を出力する」など）。プロンプトの微調整よりも価値が高い場合も少なくありません。

リポジトリで繰り返し発生するミスについては、メモリや新しいチェックを提案する前に、関連するチェックコマンドと設定を確認してください。既存のチェックが実行されていないケース、チェックが壊れているケース、決定論的なチェックが不足しているケース、判断を要するルールを区別します。証拠に裏付けられた最小限の対処を提案してください。既存のチェックを実行または組み込む、チェックを修正する、対象を絞ったチェックを追加する、あるいは判断ルールを残す、のいずれかです。振り返りでの提案は、依頼されていないツールの実装を許可するものではありません。

4. 改善点

具体的な改善点を、影響度と発生頻度の高い順に並べます。実行可能な改善策、カテゴリ／対象、深刻度、確信度、発生回数／根拠をそれぞれ別の列にした、番号付きの表にまとめます。項目は最大10件です。さらに見つかった場合は、まとめたり分割したりせず、優先度の低い項目を除外します。

capture-and-routing.md を参照し、対処カテゴリを1つ選択します。対象は提案として扱い、既存の認可範囲内でのみ適用します。

各メモリ候補に、プロジェクト単位またはプロジェクト横断のラベルを付けます。プロジェクト横断の項目については、設定済みのユーザーレベルのメモリ保存先を提示します。その保存先と対象項目の両方についてユーザーの承認を得るまでは、そこに書き込みません。

永続化がまだ許可されていないメモリ候補については、具体的な項目を提示し、どれを記憶するかユーザーに尋ねます。使用中のハーネスがサポートする承認インターフェースを使うか、チャットで直接尋ねてください。ユーザーがすでに記憶を許可した項目については、再度尋ねません。

許可されたプロジェクト単位のメモリ項目は、使用中のハーネスのファイル編集ツールとメモリ形式を使用して、プロジェクトで設定されたメモリ保存先に保存します。Claude Code では、~/.claude/projects/<project-slug>/memory/ とその MEMORY.md インデックスを調べ、独自に作成したスラッグではなく、設定済みのプロジェクトスラッグを使用します。

各メモリ項目は、個別に修正可能な主張1つにまとめ、設定済みの形式に従います。主張の有効性が日付や出典に依存する場合は、それらを含めます。古い主張を履歴として残す場合は、置き換えられた主張であることを明示し、現在有効なガイダンスから除外します。既存のメモリ規約を使用し、この振り返りだけを目的にアーカイブやインデックスを新設しないでください。

明示的な remember: リクエストも含め、永続化するすべての項目から認証情報の値を除外します。代わりに環境変数名または保管庫の場所を記録し、伏せたシークレット値を、繰り返さずにユーザーへ伝えます。

書き込む前に、メモリディレクトリを対象項目のキーワードで grep します。ほぼ重複する項目が見つかった場合は、2つ目を追加せず、既存ファイルを更新します。既存の記録と明確に矛盾する場合（「タブを使う」という記録があるのに「スペースを使う」とする場合など）は、無条件に追記せず、両方を提示して、統合、置き換え、または両方を残すかをユーザーに選んでもらいます。重複や矛盾が黙って蓄積されることが、整理されたメモリインデックスを劣化させる主な原因です。

5. スキル監査（スキルを使用した場合、または呼び出し漏れによって支障が生じた場合）

スキルに関する文章を提案する前に、スキルの失敗トリアージを適用し、内容、ルーティング、配置、実行の各不備を区別してください。

セッション中に呼び出したスキルごとに、次の手順を実施してください。

A. セルフチェックのゲート：スキルに成功基準と検証ループがない場合：

• 冒頭に## Success Criteriaを追加することを提案してください（測定可能なチェック項目を3～5個）。
• 末尾に## Self-Checkを追加することを提案してください：「出力を提示する前に、すべての成功基準を満たしていることを確認してください。満たしていない場合は、最大5回まで反復してください。」

B. トークン効率：冗長な表現、統合できるセクション、過度に大きな例、「Claudeはすでに知っている」内容、機能していないフロントマターのメタデータを指摘してください。

C. その他：不足しているエッジケース、曖昧な指示（測定可能な基準に書き換えるか削除）、単独の否定表現（代わりに実行することを追加するか削除）を指摘してください。

D. ガイダンスの不一致：スキルが呼び出され、その助言が今回の状況では誤り、古くなっている、または当てはまらないと判明した場合に発生します。A、B、Cはスキル単体を評価しますが、これは実際に問題を引き起こした行に基づいて評価します。以下の4項目をすべて記録してください。

• 誤った動作を引き起こしたSKILL.mdまたはその参照先からの原文の抜粋
• 適用できなかったプロジェクトのコンテキスト（言語、ランナー、フレームワークのバージョン、プロジェクトの規約など）
• その指示に従った結果、何が起きたか
• 代わりに行ったこと

不一致のないスキルについても、「不一致なし」と明記してください。「状況Yでは行Xが誤りで、代わりにこの回避策を使った」という記述は、実行可能な修正案です。「このスキルの指示は曖昧だ」という記述は、調査課題にすぎません。

提案する変更は差分として提示してください。既存の編集権限の範囲内で変更を適用し、それ以外の場合は、現在のハーネスでサポートされている承認インターフェースを使うか、チャットで直接、適用する具体的な変更を確認してください。

6. キャプチャマーカー

キャプチャシグナルとして受け付けるのは、ユーザーが作成したプロンプトと、ツール呼び出しが拒否されたことに対するユーザーのフィードバックのみです。remember:、修正、保留中のキャプチャを処理する前に、capture-and-routing.mdを読んでください。すべてのキャプチャに対し、手順4の認証情報の除外と書き込み前チェックを適用してください。

7. パターンの検出

既存のスキルでは対応できない類似タスクが2件以上ある場合は、新しいスキルを提案してください（説明は1～2文）。確認を得てから作成してください。

**先回りのトリガー：**ユーザーから修正された場合、同じ点について2回明確化された場合、または不満が示された場合は、準備ができたときに振り返りを提案してください（「改善できる点を振り返ります。」）。現在のハーネスで実際にサポートされている呼び出し名を明記してください（Claude Codeでは/ia-reflect、それ以外ではこのスキル名）。スラッシュコマンドに対応していないハーネスでは、スラッシュコマンドを出力しないでください。

セルフチェック

出力を提示する前に、すべての成功基準を満たしていることを確認してください。満たしていない基準がある場合は、最大5回まで修正してください。