reflect

Reflect

現在の会話から長期的に役立つ学びを抽出し、スキルの編集に振り分けます。

呼び出すタイミング

• ユーザーが「reflect」または「/reflect」と言った場合。
• 複雑なタスク（ツール呼び出しが5回以上）が問題なく完了し、その手順を残す価値がある場合。
• エージェントが行き詰まった後に有効な方法を見つけ、その方法が一般化できる場合。
• タスクの途中でユーザーがエージェントの進め方を修正した場合。
• まだどこにも記録されていない、重要なワークフローが生まれた場合。

会話が単純な場合、話題から外れている場合、または既存のスキルに記載済みの内容に親エージェントが正しく従っている場合はスキップします。一度限りの出来事は学びではありません。

手順

1. 現在のトランスクリプトを特定する

親エージェントは並列処理を開始する前に、自身のトランスクリプトファイルを見つけます。システムプロンプトに記載された、アクティブなワークスペースの agent-transcripts/ ディレクトリを使用します。~/.cursor/projects/*/ を対象にグロブ検索してはいけません。これによりワークスペースの境界を越え、無関係なプロジェクトのプライベートな会話を読み込むことになります。

ls -t <agent-transcripts>/*.jsonl <agent-transcripts>/*/*.jsonl <agent-transcripts>/*/subagents/*.jsonl 2>/dev/null | head -10

トランスクリプトのレイアウトは3種類あります。旧形式のフラット型（<id>.jsonl）、現在のネスト型（<id>/<id>.jsonl）、サブエージェント型（<parent>/subagents/<child>.jsonl）です。

候補ごとに最初の JSONL 行を読み、message.content[0].text に会話の最初のユーザープロンプトが含まれているか確認します。一致するパスを使用してください。どのパスも特定できない場合は、セッションの簡潔な要約を作成し、代わりに渡します。

2. 3人のレビュアーを並列で起動する

1つのメッセージで Task を3回呼び出し、それぞれ subagent_type: generalPurpose を指定します。各呼び出しでは model: を明示し、エージェントモード（readonly: false）にします。レビュアーは、トランスクリプトで言及されたチケット、チャットスレッド、オブザーバビリティトレースなどのコンテキストを確認するため、MCP にアクセスする必要があります。読み取り専用モードでは MCP が無効になります。プロンプトではファイルへの書き込みを禁止します。編集は親エージェントが適用します。

観点	model	プロンプトテンプレート
判断	設定済みの reflect-judgment モデル（デフォルトは claude-opus-4-8-thinking-xhigh）	references/judgment-reviewer.md
ツール	設定済みの reflect-tooling モデル（デフォルトは composer-2.5-fast）	references/tooling-reviewer.md
異論	設定済みの reflect-judgment モデル（デフォルトは claude-opus-4-8-thinking-xhigh）	references/divergent-reviewer.md

各テンプレートは、指定箇所のトランスクリプトのパスまたは要約だけを置き換え、ほかはそのまま渡します。レビュアーは Task の応答本文に調査結果を返します。

3. 統合する

Task を1回呼び出し、subagent_type: generalPurpose と、設定済みの reflect-judgment モデル（デフォルトは claude-opus-4-8-thinking-xhigh）を使用します。エージェントモード（readonly: false）にします。統合担当者による品質確認では、引用の抜き取り検証が含まれ、MCP へのアクセスが必要になる場合があります。読み取り専用モードでは MCP が無効になります。references/synthesizer.md をそのまま使用し、各レビュアーの出力全文を指定箇所に挿入します。統合担当者は、構造化された「採用／却下／バックログ」の一覧を返します。

4. 構造による適用の最終確認

統合担当者の「採用」一覧を確認します。lint ルール、スクリプト、メタデータフラグ、またはランタイムチェックのほうが確実に適用できる項目があれば、「採用」から「バックログ」に移します。統合担当者はすでにこの基準を適用していますが、これは編集を反映する前の最終確認です。encode-lessons-in-structure 原則スキルを参照してください。

5. 適用する

承認された編集を適用する前に、統合役の Accepted／Rejected／Backlog の出力全体をユーザーに提示し、明示的な承認を待ちます。適用する項目の範囲はユーザーが選択でき、振り分け先の変更も指示できます。スキルの変更は組織内の今後のすべてのエージェントに影響するため、自動で適用しないでください。

Backlog 項目は、チームが使用する devex／バックログトラッカーに自動的に登録します。これらはトラッカーへの登録であり、スキルの編集ではありません。承認待ちとなるのは Accepted リストだけです。

承認された各 Accepted 項目について、Routing フィールドの指示に正確に従います。

• 既存スキルへの軽微な編集（1 行の箇条書き、文章の簡潔化、古い情報の修正）：親エージェントが直接行います。
• 既存スキルへの実質的な編集（新しいセクション、新しいパターン表、約 10 行を超える編集）：Cursor 組み込みの create-skill スキルに引き継ぎ、ドラフト／テスト／反復のループを実行します。
• tune description: <skill path>（スキルは存在するが、本来起動すべきときに起動しなかった）：create-skill に引き継ぎ、説明最適化のループを実行します。
• new skill via create-skill: <kebab-name>：スキルの作成を create-skill に引き継ぎます。場当たり的に構成を考案しないでください。

環境に SKILL.md バリデーターが含まれている場合は、変更したすべてのスキルに対して実行してから完了を宣言します。含まれていない場合は、この手順を省略してください。

6. ユーザー向けに要約する

前置きは付けず、短いリストにします。

• 適用した編集：<skill path>。変更内容を各 1 行で記載します。
• 作成した新しいスキル：<skill path>。各 1 行で記載します（まれ）。
• devex トラッカーに登録したバックログ：<issue title>（<tags>）。各 1 行で記載します。
• 見送った項目：却下された所見ごとに 1 行で、統合役が示した理由を記載します。