opportunity-scan

Opportunity Scan — 実際に起きたことから、何を変えるべきかを見つける

エージェント自身の機能と、選択したターゲット１つを読み込み、各調査結果をどのプリミティブにすべきかを提案します。エージェントに依存しません（Claude Code、Codex、PI、…）。見つかった内容をプリミティブの全選択肢（ルール · スキル · フック · サブエージェント · MCP · 自動化／ワークフロー）に照らし合わせ、まずエージェントの機能を把握するため、どのエージェントでも動作します。

２つのターゲット、１つのスキル — 設計はこれだけです：

• １回の実行 → REACTIVE ループ。 実行したループで、何かがうまくいきませんでした。その実行の成果物をスキャンに指定し、「これを防ぐには、AI レイヤーの何が必要だったのか？」と尋ねます。コードではなく、システムを修正します。
• 一定期間のログ → PROACTIVE スキャン。 何も壊れていません。数週間分のセッションを指定し、「手作業で繰り返しているうち、何を仕組み化すべきなのか？」と尋ねます。

同じスキル、同じ形式の出力で、読み取る対象を変えるだけです。

これは、何を変えるべきかを見つける発見ツールであり、作ったものの品質を評価する評価ツールではありません。２つは分けておきましょう。

入力 — まず必須項目、その後に任意項目

$ARGUMENTS は位置指定の項目ではなく、文章として読み取ります。必須なのは入力１だけです。入力２は自由形式で、空白を含むため、引数を空白で分割したり、位置で割り当てたりしないでください。引用符なしで入力された補足も、１つの補足として扱います。不足している項目があれば、１つずつ質問するのではなく、１つのメッセージでまとめて一度だけ尋ねます。

1. スキャン対象 (必須) — 次のいずれか１つだけ：

   • １回の実行（reactive） — １回のループで残された成果物：計画、実装レポート、RCA、PR 本文、レビュー結果、コミット／差分。参照できる場合は、その実行のセッションログも追加してください。これらはすでに実行単位で絞り込まれているため、セッションを探し回る必要はありません。
   • ログの一定期間分（proactive） — エージェントのセッションログの保存先と、遡る期間。例：Claude Code → ~/.claude/projects/ + ~/.claude/history.jsonl、Codex → ~/.codex/sessions/、PI → 拡張機能のログディレクトリ。デフォルトの期間：直近２週間。

   この選択によって、スキャンが reactive になるか proactive になるかが決まります。それ以外は何も変わりません。

2. 補足 (任意 — 一度だけ尋ね、「特になし」も受け付ける) — 入力は１つで、その意味はターゲットに応じて変わります：

   • １回の実行をスキャンする場合： 気づいた症状を自分の言葉で伝えます。エージェントが間違えたこと、修正しなければならなかったこと、いら立ったことです。あなたはその場にいたのですから、成果物からスキャンに再推論させられる内容を、そのまま伝えてください。(これは１文で表す外側のループにおける「今、X をした」の部分です。ツール版でも同じ X を受け付けます。) 観察した事実にとどめてください。なぜ起きたのかを明らかにするのは、あなたではなくスキャンの役目です。
   • ログをスキャンする場合： 重視するテーマです。手作業でやめたい作業の種類、繰り返し徹底している品質基準、コストがかかり続けているループの一部などです。補足がない場合、スキャンは頻度順に並べますが、それはあなたが重視するものの順位とは異なります。

   どちらの場合も、補足を伝えるのはあなた、根拠を示すのはターゲットです。

3. エージェント自身の機能に関するドキュメント (任意 — 通常は自分で調べる) — これにより、エージェントが何になれるか（実際の拡張ポイント）をスキャンが把握できます。まず自分で調べてください。先に尋ねないでください。 実行中のエージェントを特定し、そのエージェント自身の拡張性に関するドキュメントを探します（Claude Code の場合は code.claude.com/docs）。本当に特定できない場合、またはユーザーが特定の場所を指定してほしい場合に限り、尋ねてください。拡張ポイントを固定の一覧だと思い込んではいけません。実際に見つかったドキュメントから読み取ってください。

手順 — 文字どおりに守ってください。ここが壊れやすい部分です（メタプロンプト）

1. 自分の能力を把握します。 どのエージェントとして実行されているかを特定し、その能力に関するドキュメントを読みます（入力 3。通常は自分で解決します）。このエージェントの拡張ポイント（ルール、スキル、フック、サブエージェント、MCP／ツール、自動化／ワークフローなど、ドキュメントに記載されているもの）を簡潔に内部リストへまとめます。決めつけず、ドキュメントの記述に従ってください。

2. 対象を読みます — 入力 1 の内容に応じて分岐します。

   • RUN の場合： 成果物をすべて読みます。規模は小さく、細部に意味があります。入力 2 で症状が示されている場合は、そこから始めます。成果物の中で該当箇所を見つけ、ユーザーがすでに伝えた内容を最初から再導出するのではなく、実際に起きたことと照らして確認します。そのうえで、実行全体を再構成します。何を求められ、エージェントが何をし、どこで誤り、どこを修正する必要があり、何を仮定し、何を省いたかを確認します。指定された症状は入り口であり、視野を狭めるものではありません。差分は最後に読み、主題ではなく証拠として扱います。
   • ログの一定期間の場合： 実際に行ったことを抽出します。繰り返されたコマンド、反復する複数手順の流れ、繰り返された指示や修正、使用したツール、摩擦や再試行などです。ログをそのまま取り込まず、集計します。 ログは膨大な場合があるため、生のトランスクリプトよりプロンプト／コマンド履歴ファイルを優先し、シェルツール（jq／grep／sort | uniq -c）で絞り込みます。コンテキストに取り込むのは頻度と代表的なサンプルだけにし、ログファイル全体は取り込みません。

   どちらの場合も、対象を見つけられない、または解析できない場合は、作り上げずにユーザーに尋ねてください。

3. 変更すべき点を見つけます — 対象によって問いが異なります。

   • RUN（リアクティブ）： 誤りが起きた、または修正が必要だった事柄ごとに、「AI レイヤーの何があれば、これを防げたか？」と考えます。見逃しを防げた最小限で持続性のある変更を挙げます。今日すぐ適用できるほど具体的に、ルールへの一行追加、スキルへの手順追加、フック、ツールのスコープ調整などを示してください。コードではなくシステムを修正します。 コードの修正案ではなく、そのコード修正を不要または自動にできた仕組みを提案してください。⚠️ 失敗のすべてがシステムの欠陥とは限りません。 持続性のある変更では防げなかった問題があれば、一度限りの事例にルールをでっち上げず、そう明言してください。憶測に基づくルールを五つ作るより、正直に「変更することはありません」と一つ伝えるほうが価値があります。
   • ログ（プロアクティブ）： 繰り返し現れるパターンごとに、**「これは何にすべきか？」**と考えます。おおよその優先順位は、発生頻度 × 設定によって削減できる手間です。

   どちらの対象でも： 手順 1 のリストから最適なプリミティブを選び、その理由を述べます。入力 2 がある場合は、その内容を重視します。RUN では、指定された症状を防ぐ案を報告の先頭に置きます（証拠から実際の症状が別のものだと分かった場合は、その点を明言します）。ログでは、最頻出のパターンではなくても、ユーザーが重視すると述べた内容を取り上げます。また、頻度の高いパターンでも、設定する価値がない場合はその旨を明言します。さらに、提案する変更は、既存の成果物のプロジェクト内の書式に合わせます。 まずプロジェクトの既存のルール、スキル、エージェントをいくつか確認し、提案がそれらに似た形になるようにしてください。そうすれば、ユーザーが実際に導入したくなる提案になります。対応例：

   • 何度も繰り返すルール → ルール（CLAUDE.md / AGENTS.md）
   • 繰り返す複数手順のワークフロー → スキル
   • 手作業で何度も徹底する、必ず守る／絶対にしてはならない事項 → フック
   • 特化した作業の定期的な委任 → サブエージェント
   • 頻繁に行う、一貫したエンドツーエンドの引き継ぎ → 自動化（後に Archon ワークフロー）

4. レポートを作成します。 下記の仕様に従って、自己完結型の HTML ファイルを 1 つ作成し、その保存場所をユーザーに伝えます。

レポートの方針 — 指示するのはレポートの表現方法であり、内容ではありません

分析結果をレポートに反映してください。 どのセクションを設けるか、各セクションに何を盛り込むか、どこまで掘り下げるか、機会をいくつ示すか、どの引用や数値を取り上げる価値があるか——そのすべては、このスキルではなく、実際に見つかった内容から決まります。レポートのセクションを固定したり、発見事項を先回りして用意したり、結論を指定したりしないでください。データが豊富ならレポートも充実させ、ひとつの発見事項に独立した深掘りセクションが必要なら設け、意外な結果があれば取り上げてください。

指定するのは表現方法だけです。

• インライン CSS を含む、自己完結した .html ファイルを 1 つ作成してください。どのブラウザーでも開けます。
• 見た目がすっきりしていて、流し読みしやすく、ゆとりのあるレイアウトにしてください。実際に見つかった内容に最適なレイアウト、セクション、実際の引用、統計、ビジュアルを使い、発見事項を十分に伝えてください。

ルール：このスキルが定めるのは、ページ上での表現方法であり、ページに載せる内容ではありません。

シンプルに保つ

明確に、次の 4 つの手順だけを実行してください。不要な評価フレームワーク、設定、追加の工程を加えないでください。手順を完了できない場合（ドキュメントまたは対象が見つからない場合）は、中断して確認を求めてください。分析内容を決して捏造しないでください。 1 回の実行につき、対象は 1 つだけスキャンしてください。 リアクティブな視点とプロアクティブな視点の両方が必要なら、2 回実行して 2 つのレポートを作成してください。「このループで何が壊れたか」と「1 か月を通じて何を繰り返しているか」を混ぜると、どちらの問いにも十分に答えられないレポートになります。