mcpField
R
reflect

reflect

github.com/ericlitmanエージェントワークフロー53846 回インストール1 週間前に更新
リポジトリ

reflect について

Reflectは、会話から長期的に活用できる知見を抽出し、スキルの更新先を決めるスキルです。複数のレビューと統合を行い、採用した編集も承認前には適用しません。

主な機能

  1. 01会話履歴から長期的な知見を抽出
  2. 023つの視点で並列レビュー
  3. 03採用・却下・バックログ項目の統合
  4. 04構造的な強制ルールへの適性確認
  5. 05スキル編集前の承認必須

活用シーン

  1. 01セッションから再利用可能な知見を抽出
  2. 02既存または新規スキルへの指摘の振り分け
  3. 03実施する編集とバックログ項目の区別

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/ericlitman/open-pstack --skill reflect

インストール後、Claude Code で/reflectを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
divergent-reviewer.md
judgment-reviewer.md
synthesizer.md
tooling-reviewer.md

詳細

Reflect

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

ディスパッチの契約。 設定されたすべてのロールをprovider-dispatch.mdで解決します。レビュアーには親のライブ MCP サーフェスが必要なため、デフォルトでサポートされる移植可能な経路はinherit-parent（またはそのエイリアスであるauto）です。トランスクリプトまたは要約と、必要な証拠へのパスを渡します。Codex では、残りの Claude ツール名をcodex-tools.mdで解決します。

ユーザーが「reflect」または「/reflect」と言ったときに呼び出します。会話が些細なもの、話題から外れたもの、または親が既存のスキルに従って適切に対応済みの内容をすでに扱っている場合はスキップします。一度限りのことは学びではありません。

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

並列処理を開始する前に、アクティブなトランスクリプトのマッピングを通じて、この会話のトランスクリプトを解決して確認します。それができない場合は、簡潔なセッション要約を渡します。

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

プロバイダーディスパッチを通じて、1 回の並列処理フェーズですべての読み取り専用レーンを開始します。レビュアーはトランスクリプトで言及されているチケット、チャットスレッド、オブザーバビリティのトレースを調べるために MCP アクセスが必要です。そのため、親と同じネイティブ環境で実行します。プロンプトでファイルへの書き込みを禁止し、編集は親が適用します。poteto-mode スキルの Subagents セクションに従い、作業に応じて各サブエージェントの実行量を選びます。

観点モデル記述子プロンプトテンプレート
判断reflect tooling, judgment, divergent, synthesizer 記述子（デフォルトはinherit-parent）references/judgment-reviewer.md
ツールreflect tooling, judgment, divergent, synthesizer 記述子（デフォルトはinherit-parent）references/tooling-reviewer.md
発散reflect tooling, judgment, divergent, synthesizer 記述子（デフォルトはinherit-parent）references/divergent-reviewer.md

各テンプレートを変更せずに渡し、指定箇所にトランスクリプトのパスまたは要約を挿入します。レビュアーはAgentの応答本文に調査結果を返します。

3. 統合する

reflect tooling, judgment, divergent, synthesizer 記述子（デフォルトはinherit-parent）を使用して、1 つのレーンをディスパッチします。MCP を通じて引用をスポット検証するため、そのアクセスを維持します。references/synthesizer.mdを変更せずに渡し、指定箇所に各レビュアーの出力全文を挿入します。Accepted / Rejected / Backlog のリストが返されます。

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

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

5. 適用する

統合担当の Accepted / Rejected / Backlog の出力全文を提示し、Accepted の編集を適用する前に明示的な承認を待ちます。ユーザーは対象を選び、振り分け先を変更することもできます。スキルの変更は組織内のすべての将来のエージェントに影響します。自動で適用しないでください。

Backlog の各項目は、待たずにチームの DevEx またはバックログ管理システムに登録します。承認を待つのは Accepted リストのみです。

承認された各項目について、Routing に正確に従います。

  • 既存スキルへの軽微な編集（箇条書き 1 行の追加、文の簡潔化、古くなった事実の修正）：親が直接行います。
  • 既存スキルへの実質的な編集（新しいセクション、新しいパターン表、約 10 行を超える変更）：plugin-dev:skill-development スキルに引き継ぎ、下書き／テスト／反復のループを実行します。
  • tune description: <skill path>（スキルは存在するが、必要なときに起動しなかった）：plugin-dev:skill-developmentに引き継ぎ、説明最適化のループを実行します。
  • new skill via plugin-dev:skill-development: <kebab-name>：スキルの作成をplugin-dev:skill-developmentに引き継ぎます。独自に場当たり的な形式を考案しないでください。

環境に SKILL.md バリデーターがある場合は、完了を宣言する前に、編集したすべてのスキルに対して実行します。

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

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

  • 適用した編集：<skill path>。変更内容を1行ずつ記載します。
  • 新規作成したスキル：<skill path>。1行ずつ記載します（まれです）。
  • devex トラッカーに登録したバックログ：<issue title>（<tags>）。1行ずつ記載します。
  • 見送った項目：却下した指摘と、シンセサイザーによる理由を1行ずつ記載します。

コメント

Markdown 対応