reflect

Reflect

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

ユーザーが「reflect」または「/reflect」と言った場合に呼び出します。会話が些細な内容、無関係な内容、または親が既存のスキルを正しく適用している内容ならスキップします。一度限りの出来事は学びではありません。

1. アクティブなトランスクリプトを特定する

親は並列処理を開始する前に、自身のトランスクリプトファイルを特定します。これは、このワークスペースのトランスクリプト保存先にある最新のセッションです。場所の特定には pstack-harness スキルを使います。他のワークスペースのトランスクリプト保存先を読んではいけません。それはワークスペースの境界を越え、無関係なプロジェクトのプライベートなチャットを読むことになります。

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

これで、従来のフラットな（<id>.jsonl）、現在のネストされた（<id>/<id>.jsonl）、サブエージェントの（<parent>/subagents/<child>.jsonl）レイアウトに対応できます。各候補の先頭の JSONL 行を読みます。message.content[0].text に会話の最初のユーザープロンプトが含まれているファイルを選びます。一致するものがない場合は、代わりにセッションの簡潔な要約を渡します。

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

1 つのメッセージで、subagent_type: general-purpose、以下の表に示す model、エージェントモード（readonly: false）を指定して、3 件の Task 呼び出しを行います。レビュアーは、トランスクリプトで参照されているチケット、チャットスレッド、オブザーバビリティのトレースを確認するために MCP アクセスが必要です。readonly では MCP が使えなくなります。起動には pstack-harness スキルを使います。その Spawn a role セクションでロールを解決し、この CLI 用の起動呼び出しを組み立てます。

各レビュアーと統合担当者は、pstack モデル設定のロール行とデフォルト値を指定します。モデル、エフォート、エージェントタイプの解決には pstack-harness スキルを使います。その Spawn a role セクションでは、設定がない場合、inherit-parent、無効な値への対応についても説明しています。

観点	ロール行	デフォルトの model	プロンプトテンプレート
判断	reflect judgment, divergent, synthesizer	opus	references/judgment-reviewer.md
ツール	reflect tooling	opus	references/tooling-reviewer.md
発散	reflect judgment, divergent, synthesizer	opus	references/divergent-reviewer.md

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

3. 統合する

subagent_type: general-purpose、reflect judgment, divergent, synthesizer 行から取得した model（デフォルトは opus）、エージェントモード（readonly: false）を指定して、1 件の Task 呼び出しを行います。MCP を通じて引用を抜き取り検証します。readonly では MCP が使えなくなります。references/synthesizer.md をそのまま渡し、各レビュアーの出力全文を指定箇所に埋め込みます。Accepted / Rejected / Backlog のリストが返されます。

4. 構造による適用を確認する

Accepted の項目のうち、リントルール、スクリプト、メタデータフラグ、またはランタイムチェックによって、より確実に適用できるものは Backlog に移します。encode-lessons-in-structure 原則スキルを参照してください。

5. 適用

統合担当の Accepted／Rejected／Backlog の全出力を提示し、Accepted の編集を適用する前に、明示的な承認を待ちます。ユーザーが適用する項目を選び、ルーティングを変更する場合もあります。スキルの変更は、組織内の今後のすべてのエージェントに影響します。自動で適用しないでください。

通常の Backlog 項目は、待たずにチームの devex または backlog のトラッカーに登録します。セキュリティ、プライバシー、認証、データ、権限境界に関する指摘は例外です。こうした指摘は非公開にし、オペレーターに直接報告します。公開トラッカー、issue、PR、コメントには投稿もリンクもしないでください。承認を待つのは Accepted の一覧だけです。

承認された各行のルーティングに正確に従います。

• 既存スキルの軽微な編集（1行の箇条書き、文の簡潔化、古くなった事実の修正）：親が直接対応します。
• 既存スキルの大幅な編集（新しいセクション、新しいパターン表、約10行を超える変更）：../poteto-mode/playbooks/authoring-a-skill.md の作成ガイドに従い、ドラフト／テスト／反復のループを実施します。
• tune description: <skill path>（スキルは存在するものの、必要な場面で起動しなかった場合）：../poteto-mode/playbooks/authoring-a-skill.md に従って説明を書き直し、起動すべき場合と起動すべきでない場合の文言をテストする説明最適化ループを実施します。
• new skill: <kebab-name>：../poteto-mode/playbooks/authoring-a-skill.md に従って作成します。独自の形式をその場で考案しないでください。

環境に SKILL.md バリデーターが用意されている場合は、完了を宣言する前に、変更したすべてのスキルで実行します。

6. ユーザーへの要約

前置きなしで、簡潔に列挙します。

• 適用した編集：<skill path>。変更内容を1行ずつ記載します。
• 新規作成したスキル：<skill path>。それぞれ1行で記載します（まれです）。
• devex トラッカーに登録した Backlog：<issue title>（<tags>）。それぞれ1行で記載します。
• 見送り：却下された指摘ごとに1行で、統合担当による理由を記載します。