plannotator-compound

複合計画分析

ユーザーの Plannotator 計画アーカイブを包括的に調査・分析します。目標は、却下された計画からパターンを抽出し、実践的な知見にまとめ、洗練された HTML ダッシュボードレポートを作成することです。

これは複数フェーズにわたるプロセスです。次のフェーズに進む前に、各フェーズを最後まで完了してください。調査の完全性が最も重要です。すべてのファイルを読み、読み飛ばしはしないでください。

ソースの選択

分析を始める前に、利用可能なデータソースを特定してください。

1. Plannotator モード（優先） — Plannotator のデータディレクトリを特定します。$PLANNOTATOR_DATA_DIR が設定されている場合はそれを使用し、そうでなければ ~/.plannotator を使用します。その中の plans/ サブディレクトリを確認してください。そこに *-denied.md ファイルが存在する場合は、このモードを使用します。以下のワークフロー全体は、Plannotator のデータを対象としています。

2. Claude Code フォールバックモード — Plannotator のアーカイブがない場合、または却下された計画が含まれていない場合は、~/.claude/projects/ を確認します。存在する場合は、続行する前に references/claude-code-fallback.md を読んでください。このリファレンスでは、同梱のパーサー scripts/extract_exit_plan_mode_outcomes.py を使って Claude Code の JSONL トランスクリプトから却下理由を抽出する方法を説明しています。以下の各フェーズには、フォールバックモードで変更される内容についての簡単な説明があります。詳細はリファレンスファイルを確認してください。

3. どちらも利用できない場合 — ユーザーに Plannotator の plans ディレクトリ、または Claude Code の projects ディレクトリを尋ねてください。推測してはいけません。

フェーズ 0：計画の場所を特定し、過去のレポートを確認する

上記の「ソースの選択」で選んだモードを使用してください。

Plannotator モード： plans ディレクトリに *-denied.md ファイルが含まれていることを確認してください。存在しない場合は、処理を中断する前に Claude Code モードに切り替えてください。

Claude Code フォールバックモード： フォールバックのリファレンスに従って同梱のパーサーを実行し、却下理由のデータセットを作成してください。必要であれば /tmp/compound-planning/ を作成します。

どちらのモードでも、以下の「過去のレポートの検出」に進んでください。

過去のレポートの検出

plans ディレクトリを特定した後、既存のレポートを確認してください。

ls ${PLANNOTATOR_DATA_DIR:-~/.plannotator}/plans/compound-planning-report*.html

レポートは、次のバージョン付き命名規則に従います。

• 最初のレポート：compound-planning-report.html
• 2つ目以降のレポート：compound-planning-report-v2.html、compound-planning-report-v3.html など

レポートが1つ以上存在する場合は、最新のもの（バージョン番号が最も大きいもの）を特定してください。stat を使ってファイルシステム上の最終更新日を取得します（macOS：stat -f %Sm -t %Y-%m-%d、Linux：stat -c %y | cut -d' ' -f1）。この日付をカットオフ日とします。

ユーザーに次の選択肢を提示してください。

「以前のレポート（compound-planning-report-v{N}.html）が見つかりました。最終更新日は {CUTOFF_DATE} です。次のどちらかを選べます。

1. 差分分析 — {CUTOFF_DATE} より後の日付のファイルだけを分析し、トークンを節約しながら、以前の知見を踏まえて分析します
2. 全件分析 — アーカイブ全体を最初から再分析します

どちらにしますか？」

続行する前に、ユーザーの回答を待ってください。

差分分析の場合： 以降のすべてのフェーズで、カットオフ日より後の日付のファイルだけを処理します。新しいレポートのヘッダー説明には、対象期間が {CUTOFF_DATE} から現在までであることを記載し、それ以前の知見については過去のレポートを参照します。全体の統計を示すため、インベントリ（フェーズ 1）では引き続きすべてのファイルを数えますが、「前回のレポート以降に追加された件数」は明確に分けて示してください。

全件分析の場合： すべてのファイルを対象に通常どおり進めます。ただし、出力ファイル名には次のバージョン番号を使用してください。

過去のレポートが存在しない場合： 通常どおり進めます。最初のレポートの出力ファイル名は compound-planning-report.html（バージョンサフィックスなし）です。

フェーズ 1：インベントリ

データセットを集計し、報告します。増分実行か全件実行かにかかわらず、全体の統計では必ずすべてのファイルを数えてください。

- *-approved.md files (count)
- *-denied.md files (count)
- Date range (earliest to latest date found in filenames)
- Total days spanned
- Revision rate: denied / (approved + denied) — this is the "X% of plans
  revised before coding" stat used in dashboard section 1

注： *.annotations.md ファイルは完全に無視してください。拒否されたファイルには、計画の全文と、--- 区切りの後に追加されたすべてのレビューフィードバックがすでに含まれています。アノテーションファイルはこの内容の重複する一部であり、両方を読むとフィードバックを二重に数えることになります。

増分モードの場合： 合計数を報告した後、カットオフ日以降の日付のファイル数のみを別途報告してください。

New since {CUTOFF_DATE}:
- *-denied.md files: X (of Y total)
- New date range: {CUTOFF_DATE} to {LATEST_DATE}
- New days spanned: N

カットオフ日以降に新たに拒否されたファイルが 3 件未満の場合は、ユーザーに警告してください。

"前回のレポート以降、新たに拒否された計画は {N} 件のみです。増分分析では内容が不足する可能性があります。このまま続行しますか、それとも全件分析に切り替えますか？"

また、すべての *-approved.md ファイルに対して wc -l を実行し、承認された計画の平均行数を算出してください。これにより、計画が簡潔な状態を保っているか、時間とともに肥大化しているかをユーザーに伝えられます。承認された計画の内容を読む必要はありません。行数だけを確認してください。可能であれば、期間別（例：月別）にも集計し、計画のサイズが変化したかを示してください。

日付はファイル名に YYYY-MM-DD 形式で含まれており、先頭に付く場合（2026-01-07-name-approved.md）と、埋め込まれている場合（name-2026-03-15-approved.md）があります。すべてのファイル名から日付を抽出してください。

調査結果をユーザーに伝え、抽出を開始することを知らせてください。

Claude Code のフォールバックモード： 上記の Plannotator のインベントリ項目は適用されません。代わりに、references/claude-code-fallback.md のインベントリ手順に従い、パーサーが作成した拒否理由のデータセットを報告してください。

フェーズ 2：マッピング — 並列抽出

ここが最も時間のかかるフェーズです。対象範囲内の *-denied.md ファイルをすべて読む必要があります。ファイルを読み飛ばしてはいけません。早まって要約してはいけません。

対象範囲内とは、全件分析の場合はすべての拒否ファイル、増分分析の場合はカットオフ日以降の日付の拒否ファイルのみを指します。増分モードでは、埋め込まれた YYYY-MM-DD の日付がカットオフ日より後のファイルのみを処理してください。

Claude Code のフォールバックモード： パーサーの出力がクリーンなソースデータセットです。JSON の分割ファイルに特化した抽出プロンプトとバッチ処理方法について、フォールバックのリファレンスを確認してください。パーサーに問題がある場合、またはユーザーが監査レベルの検証を求めた場合を除き、未加工の .jsonl ログには戻らないでください。

重要： *-denied.md ファイルのみを読んでください。承認済みの計画、アノテーションファイル、差分ファイルは読まないでください。各拒否ファイルには、計画の全文に続いて --- 区切りとレビュアーのフィードバックが含まれており、分析に必要な内容はすべて 1 つのファイルにまとまっています。

バッチ処理方法

抽出エージェントはすべて model: "haiku" を使用してください。単純なファイル読み込みと構造化抽出を行うためのものであり、推論を行うものではありません。この作業では Haiku のほうが高速で低コストです。

方法はデータセットのサイズによって異なります。

ごく小規模なデータセット（合計 10 ファイル以下）： メインエージェントですべてのファイルを直接読みます。サブエージェントは不要です。順番に読み、フェーズ 3 に進んでください。

小規模なデータセット（11～30 ファイル）： Haiku エージェントを 2～3 個並列で起動し、ファイルをほぼ均等に分割してください。

中規模なデータセット（31～80 ファイル）： Haiku エージェントを 4～6 個並列で起動し、それぞれに約 10～15 ファイルを割り当ててください。ファイルの種類や期間ごとに分割します。

大規模なデータセット（80 ファイル以上）： 各バッチが約 10～15 ファイルになるよう、必要な数の Haiku エージェントを並列で起動してください。データ内の自然な時間区分（月、四半期、またはバランスの取れたバッチになる任意のグループ分け）で分割します。特定の期間に偏りがある場合（例：直近の月に他の期間の 3 倍のファイルがある場合）は、その期間を複数のバッチに分けてください。

Agent ツールを使って run_in_background: true および model: "haiku" を指定し、すべての抽出エージェントを並列で起動してください。

出力ファイル

各抽出エージェントは、エージェントのタスク出力（解析が難しい、インターリーブされた JSONL フレームワークログを含みます）に頼るのではなく、結果をクリーンな出力ファイルに書き込む必要があります。各エージェントには、次の場所に書き込むよう指示してください。

/tmp/compound-planning/extraction-{batch-name}.md

エージェントを起動する前に、/tmp/compound-planning/ ディレクトリを作成してください。Phase 3 の reduce エージェントは、これらのクリーンなファイルを直接読み込みます。

抽出プロンプト

各エージェントには、次の指示を渡します（対象期間、ファイルリスト、出力パスを適宜変更してください）。

You are extracting structured data from denied plan files for a pattern analysis.

Directory: [PLANS DIRECTORY]
Files to read: [LIST OF SPECIFIC *-denied.md FILES]
Output: Write your complete results to [OUTPUT FILE PATH]

Each denied file contains two parts separated by a --- line:
1. The plan text (above the ---)
2. The reviewer's feedback and annotations (below the ---)

Read EVERY file in your list. For EACH file, extract:
- The plan name/topic (from the plan text above the ---)
- The denial reason or feedback given (from below the --- — capture the actual
  words used)
- What was specifically asked to change
- The type of feedback (let the content determine the category — don't force-fit
  into predefined types. Common types include things like: scope concerns,
  approach disagreements, missing information, process requirements, quality
  concerns, UX/design issues, naming disputes, clarification requests,
  testing/procedural denials — but the user's actual patterns may differ)
- Any specific phrases or recurring language from the reviewer
- Individual annotations if present (numbered feedback items with quoted text
  and reviewer comments)
- The date (extracted from the filename)

Do NOT skip any files. One entry per file.

Format each entry as:
**[filename]**
- Date: ...
- Topic: ...
- Denial reason: ...
- Feedback type: ...
- Specific asks: ...
- Notable phrases: ...
- Annotations: [count, with brief summary of each]
---

After processing all files, write the complete results to [OUTPUT FILE PATH].
State the total file count at the end of the file.

エージェントの実行中

完了状況を追跡してください。各エージェントの処理が終わったら、処理したファイル数を記録します。合計数が Phase 1 の一覧と一致することを確認してください。エージェントの処理数が不足している場合は、その旨を記録し、未処理ファイルを対象に再起動することを検討してください。

エージェントがタイムアウトした場合（大量のバッチでは起こり得ます。128 ファイルのバッチでは 8 分以上かかることがあります）、未処理ファイルだけを対象に再起動してください。タイムアウトするまでにどこまで処理できたか、出力ファイルを確認してください。

Phase 3: Reduction — パターン分析

すべての抽出エージェントの処理が完了した後（または小規模なデータセットですべてのファイルを読み込み終えた後）、リダクションに進みます。リダクションエージェントでは model: "sonnet" を使用してください。このフェーズでは、単なるファイルの読み込みではなく、実際の分析的推論が必要です。

リダクション戦略

抽出ファイルの数に応じて、アプローチを変えます。

標準（抽出ファイルが 20 以下）： 1 つの Sonnet エージェントを起動して、すべての抽出ファイルを読み込み、分析全体を作成します。ほとんどのデータセットはこれで対応できます。

大規模（抽出ファイルが 21 以上）： 2 段階のリダクションを行います。

1. Stage 1 — 部分リダクション： 抽出ファイルを 4〜6 個ずつのグループに分けます。Sonnet エージェントを並列で起動し、各エージェントが 1 グループを読み込み、以下に示す同じセクション構成で部分分析を作成します。それぞれの出力先は次のとおりです。 /tmp/compound-planning/partial-reduce-{N}.md

2. Stage 2 — 最終リダクション： 1 つの Sonnet エージェントがすべての部分リダクションファイルを読み込み、統合して包括的な最終分析を作成します。このエージェントは、分類体系を統合し、数をまとめ、パターンの重複を除き、部分分析間で分類が食い違う場合は調整します。

Claude Code のフォールバックモード： リダクションフェーズは同じです。上流工程で異なるのは、抽出ファイルが Plannotator の Markdown ファイルではなく、正規化された denial-reason JSON から生成されている点だけです。

リダクションプロンプト

各リダクションエージェントには、次のプロンプトを渡してください（単一段階か複数段階かに応じてファイルパスを変更してください）。

You are a data scientist conducting the reduction phase of a map-reduce analysis
across a user's denied plan archive.

Read ALL extraction files at [FILE PATHS]

These files contain structured extractions from every denied plan file. Each
extraction includes the plan topic, denial feedback, annotations, and reviewer
language. Your job: aggregate everything, find patterns, cluster into a taxonomy,
and produce a comprehensive analysis.

Be exhaustive. Use real counts. Quote real phrases from the data. This is
research — no hand-waving, no fabrication.

Write your complete results to [OUTPUT FILE PATH].

Produce the following sections:
[... sections listed below ...]

リダクションエージェントの役割は、データそのものに語らせることです。あらかじめ決められた枠組みを押しつけず、実際に存在する傾向を見つけてください。分析では、次の項目を作成します。

1. 拒否理由の分類体系

データから導き出される有限の種類に、すべての拒否を分類します。発生数を数え、割合を示してください。各種類には実際の引用例を含めてください。8〜15 種類を目安にします。具体性を保ちつつ、一覧しやすい数にしてください。分類は、ユーザーの実際のフィードバックに基づいて決めます。

2. 主なフィードバックパターン（頻度順）

最も頻繁に繰り返される 5〜10 個のパターンを示します。それぞれについて、レビュアーが一貫して求めていること、異なるファイルからの引用例を 3 件以上、そしてパターンが時間とともに変化したかどうかを記載してください。

3. 繰り返し使われるフレーズ

レビュアーが繰り返し使う正確なフレーズと、その使用回数、および各フレーズが示す内容を記載してください。これらはレビュアー固有の語彙であり、重視する点を示す略式表現です。

4. レビュアーが重視すること（暗黙の好み）

パターンから導き出される、特定のレビュアーが最も重視する点を示します。品質、速度、説明、アーキテクチャ、プロセス、シンプルさのどれでしょうか。証拠の強さに基づいて順位を付けてください。このセクションは、レビュアーが求める基準の人物像を描くような内容にしてください。

5. エージェントが一貫して間違えること

その裏返しとして、どのような繰り返しのミスが拒否につながるのでしょうか。このレビュアーに対して、エージェントは何をやめるべきでしょうか。

6. 構造に関する要望

レビュアーが一貫して求める計画の構成を示します。必須のセクション、順序、形式の好み、期待される詳細度を記載してください。

7. 時間の経過に伴う変化

フィードバックのパターンが期間全体でどのように変化したか。データに存在する自然な時間の区切り（短い期間なら週、長い期間なら月）でグループ化します。期待値は成熟したか。新しいパターンは現れたか。何が変化したか。データセットが 1 か月未満の場合は、変化の分析は限定的であると注記しつつも、初期のファイルから後期のファイルへの進展がないか探してください。

8. 実行可能なプロンプト指示

最も重要な出力です。すべてのパターンに基づき、最も一般的な却下理由を防ぐためにプランニングプロンプトに埋め込むことができる、具体的な番号付きの指示を作成します。これらはエージェントが従える実際の指令として書いてください。このユーザーのパターンに固有のものにしてください —「良いプランを書く」のような一般的なアドバイスは無価値です。各指示は、実際に頻繁に発生する却下パターンに遡って関連付けられるべきです。

指示を書いた後、それらが却下の何パーセントに対処できるかを計算してください（指示がカバーするカテゴリに該当する却下の数を、却下の総数と比較して数えます）。このパーセンテージを報告してください — ユーザーごとに異なります。

フェーズ 4: HTML ダッシュボードの生成

最終成果物として、単一の自己完結型 HTML ファイルを構築します。ユーザーの plans ディレクトリに、バージョン付きのファイル名で保存します:

• 初回のレポート: compound-planning-report.html
• 2 回目のレポート: compound-planning-report-v2.html
• 3 回目のレポート: compound-planning-report-v3.html
• 以降も同様。

バージョン番号は、フェーズ 0 で見つかった既存のレポートに基づいて決定されました。

これが増分レポートの場合、ヘッダーには分析期間（例: 「2026 年 3 月 15 日 – 3 月 31 日」）を示し、「増分分析 — 以前の調査結果は v{N-1} を参照してください。」と注記するサブタイトルを含める必要があります。セクション 1 の記述では、調査結果を完全な全体像としてではなく、前回のレポート以降の新規または変更点として位置づける必要があります。ヘッダーの全体統計（ファイル数、改訂率）は、文脈のためにアーカイブ全体を反映したままにする必要があります。

assets/report-template.html のテンプレートをデザイン言語のみのために読んでください。テンプレートには前回の分析のサンプルデータが含まれています — テンプレート内のすべてのデータ値、引用、パーセンテージは無視してください。その視覚的デザインのみを使用してください: 色、タイポグラフィ、余白、コンポーネントスタイル、レイアウトパターン。

デザイン言語（テンプレートより）

• パレット: ライトモード、温かみのあるオフホワイト（#FDFCFB）、テキストはスレートスケール、ハイライト/アクセントにアンバー、ポジティブにエメラルド、ネガティブにローズ、アクション要素にインディゴ
• タイポグラフィ: Playfair Display（セリフ、ナラティブ見出し用）、Inter（サンズ、本文/データ用）、JetBrains Mono（モノ、コード/フレーズ用） — Google Fonts CDN
• レイアウト: 単一カラム、最大幅 1024px、ゆとりのある縦方向の余白（主要セクション間に 128px）、エディトリアル/ナラティブ優先の美学
• トーン: 穏やかで、内省的、権威的。監視ダッシュボードではなく、個人の振り返りジャーナルのように。

ページフレーム（ヘッダー + フッター）

7 つのセクションの前に、ページには以下があります:

• ヘッダー: 左側にレポートタイトル（Playfair Display、約 36px）、その下にプロジェクト名 + 日付範囲を軽いメタテキストで。右側にファイル数をモノで（例: 「223 件の却下 · 71 日間」）。コンテンツとは下部のボーダーで区切られます。セクション 1 の前にゆとりのある下部パディング。

• フッター: セクション 7 の後。上部ボーダー、中央揃えのイタリック Playfair Display のタグラインでコーパスを要約（例: 「Plannotator アーカイブからの X 件の却下されたプランの分析。」）。

ダッシュボードのセクション順（7 セクション）

レポートは、以下の正確な順序で構成されます。各セクションは前のセクションを踏まえた内容になっており、「何が起きたのか」から「なぜ」へ、そして「どう対応すべきか」へと展開します。

1. データが語るストーリー — 調査結果の要点を文章で伝える、編集記事風の段落（Playfair Display のセリフ体、約 26px）。箇条書きではなく、記事の書き出しのような実際の段落にします。横には主要な指標を 3 つ表示する KPI サイドバーを配置します（最も高い却下率、全体の修正率、見つかった却下カテゴリの種類数）。ストーリーの中で最も印象的な数値を、アンバーのインライン強調で目立たせます。

2. プランが却下される理由 — 分類体系を順位付きリストで表示します。各行には、順位（等幅フォント）、カテゴリ名、細い 4px の進捗バー（1 位は amber-500、それ以外は slate-300）、割合（等幅フォント）を表示し、上位項目にはラベルの下にデータから引用した実際のイタリック体の引用を表示します。上位 10 カテゴリ、またはデータで裏付けられる数のカテゴリを表示します（最低 5 つ）。

3. 期待の変化 — 自然な期間ごとにカードを 1 枚表示します。各カードには、期間名（セリフ体）、テーマを表すフレーズ（色付きの大文字表記。変化を示すため期間ごとに色を変える）、説明の段落、下部の統計情報（例：「X 件の却下 · Y 件のナラティブに関するリクエスト」）を含めます。データが 3 つ未満の期間にまたがる場合は、2 枚のカード、または内部の変化を示す 1 枚のカードを使用します。

4. うまくいくこと／いかないこと — 2 枚のカードを横並びで表示します。左側は緑を基調とし（背景は emerald-50/50、枠線は emerald-100）、このレビュアーに対して成功するプランの特性を記載します。右側は赤を基調とし（背景は rose-50/50、枠線は rose-100）、エージェントが繰り返し間違えている点を記載します。どちらも削減分析に基づく内容とします。小さな色付きのドットを使った箇条書きにし、各カードに 5～8 項目を含めます。

5. 実践につながる成果 — 分析結果を具体的な改善につなげます。冒頭では、導き出されたプロンプトの指示数と、それらが対応すると推定される却下の割合を、Playfair Display の文章で示します（一般的な数値ではなく、Phase 3 で実際に算出した割合を使用します）。続いて、最も効果の高い上位 3 つの改善点を番号付きで示します。各項目には、アンバー色の番号、太字のタイトル、1 行の説明を付けます。このセクションは、分析と、その後に続く完全なプロンプトをつなぎます。

6. よく使われるフレーズ — チップのグリッド（モバイルでは 2 列、デスクトップでは 3 列）を表示します。各チップには、左側に等幅フォントの引用符付きフレーズ、右側に出現頻度を配置します。背景は白、枠線は slate-200、角丸は 12px にします。見つかったフレーズのうち、繰り返し使われるものを 9～12 個表示します。これらはレビュアー本人が実際に使った言葉、つまりその人らしさが表れる表現にしてください。

7. 改善のためのプロンプト — ダークなパネル（背景は slate-900、文字は白、角丸は 3xl、影は xl）を表示します。冒頭に、指示内容について説明する Playfair の導入文を置きます。続いて、Phase 3 で作成した番号付きの指示をすべて含む、ダークなコードブロック（背景は slate-800/80、等幅フォントの文字は amber-200）を配置します。正常に動作するクリップボードへのコピーボタンを付けます（JS も含めます）。コードブロックの下には、グラデーションの光彩カード（白いカードの背後に、ぼかしたインディゴからパープルへの光彩を配置）を置きます。締めくくりのメッセージでは、これらの指示がユーザー自身のフィードバック、言葉遣い、基準から導き出された、その人だけのものであることを伝えます。

適応ルール

• ユーザーのデータが 3 か月未満の場合は、進化セクションのカード数を減らします
• 拒否されたファイルの大半で、--- より下にフィードバックがない場合（注釈のない単純な拒否）は、分析の内容が薄くなることを説明に記載します
• Claude Code フォールバックモード： レポートのデータソースを、Claude Code の ExitPlanMode の拒否理由として明示します。注釈数や承認済みプランの行数など、Plannotator にしかない項目を捏造しないでください。KPI の代替指標とフッター／出典表示のガイダンスについては、フォールバックのリファレンスを参照してください。
• 拒否カテゴリが 5 つ未満の場合は、分類とパターンのセクションを 1 つにまとめます
• データセットが非常に小さい場合（ファイルが 20 件未満）、説明でサンプル数の限界に触れ、調査結果を暫定的なものとして提示します
• プロンプトの指示数はユーザーによって異なり、8 件の場合も 20 件の場合もあります。正確に 17 件に固定しないでください。データに応じて件数を決めます。
• セクション 5 の実行可能な上位 3 項目には、最も印象的に聞こえる 3 項目ではなく、拒否の最大の割合を占める 3 項目を選びます

主なルール

1. すべての数値は、実際の分析結果に基づくものとし、捏造しないでください
2. すべての引用は、実在するファイルからの実際の引用にしてください
3. 分類の割合は、実際の件数から計算してください
4. プロンプトの指示は、実際の拒否パターンに基づくものにしてください
5. プロンプトブロックのコピー用ボタンが機能するようにしてください（JS を含めます）

生成後、ユーザーのブラウザーでファイルを開きます。

フェーズ 5：要約

ユーザーに次の内容を伝えます：

• 分析した拒否ファイルの件数
• 増分レポートの場合：前回のレポート以降に追加された件数
• 上位 3 つの拒否パターン
• プロンプトの指示で対処できると推定される拒否の割合
• 最も効果の高いプロンプト改善策 1 つ
• レポートの保存先（バージョン番号を含む）
• 増分レポートの場合：以前の調査結果は前回のレポートに記載されていることをユーザーに伝えます

Claude Code フォールバックモード： フォールバックのリファレンスに従って要約を調整し、Plannotator のファイル件数の代わりに、人間による拒否理由の分析件数と、スキャンした ExitPlanMode の試行総数を報告します。

フェーズ 6：改善フック

概要を提示した後、改善フックを有効にするかユーザーに尋ねます。これは、レポートのセクション 7 にある修正用プロンプトの指示を取得し、Plannotator の EnterPlanMode フックが今後のすべてのプランニングセッションに自動で挿入できるよう、ファイルに書き込むものです。

「改善フックを有効にしますか？修正用プロンプトの指示をファイルに保存し、今後のすべてのプランニングセッションに自動で挿入します。これにより、Claude はプランを作成する前に、あなたのフィードバックの傾向を確認できます。」

はいの場合：

フックファイルの保存先は次のとおりです。

${PLANNOTATOR_DATA_DIR:-~/.plannotator}/hooks/compound/enterplanmode-improve-hook.txt

データディレクトリ内に hooks/compound/ ディレクトリが存在しない場合は作成します。

ファイルの内容には、フェーズ 3 の修正用プロンプトの指示を記載します。これは、HTML レポートのセクション 7 に表示されるものと同じ番号付きリストです。プレーンテキストで、各指示を 1 行ずつ、番号を先頭に付けて記述します。HTML、Markdown のフェンス、前置きは含めず、指示のみを記載します。フックシステムは、このファイルの内容をそのままプランニングコンテキストに挿入します。

ファイルがすでに存在する場合：

既存のファイルを読み込み、次の選択肢をユーザーに提示します。

「以前の分析で作成された改善フックがすでにあります。次のいずれかを選べます。

1. 置き換える — 新しい指示で上書きします（古い指示は失われます）
2. 統合する — 重複する指示を取り除き、それぞれの最適な表現を残して両方を統合します
3. 既存のままにする — 現在のフックを変更せず、この手順をスキップします

どれにしますか？」

• 置き換える： 新しい指示でファイルを上書きします。
• 統合する： 既存の指示を読み込み、新しい指示と比較して統合します。同じ意図の指示は、表現が異なっていても重複として削除します。2 つの指示が同じパターンを扱う場合は、より具体的で実行しやすいものを残します。最終リストの番号を順番に振り直し、統合した結果をファイルに書き込みます。何が変わったか（新たに追加した項目数、削除した重複項目数、残した既存項目数）をユーザーに示します。
• 既存のままにする： 何もせず、次に進みます。

いいえの場合： このフェーズ全体をスキップします。

重要な注意事項

• データソースの優先順位： 第一の手段は Plannotator です。Plannotator のアーカイブがないユーザー向けに、Claude Code のログ分析を第二の手段として使用します。
• 調査の完全性： すべてのファイルを読む必要があります。この分析の価値は網羅性にあります。サンプリングしたり読み飛ばしたりすると、調査結果の信頼性が損なわれます。
• 実データのみ： 引用、割合、傾向を決して捏造しないでください。データから明確な傾向が読み取れない場合は、作り上げるのではなく、正直にそう伝えてください。
• データを起点にする： 分類体系、傾向、指示は、ファイルに実際に含まれている内容から導き出してください。却下の傾向はユーザーごとにまったく異なります。モバイルアプリを開発するユーザーのフィードバックは、API を開発するユーザーのものとは異なります。どのような傾向があるかを決めつけないでください。
• エージェントの並列化： データセットが大きい場合は、並列エージェントを最大限に活用し、全体の処理時間を短縮します。ボトルネックとなるのは最大のバッチです。分割してください。
• 構造化された抽出形式： 抽出を行うエージェントには、区切りが一貫した構造化テキストで返すよう依頼し、集約エージェントが確実に解析できるようにしてください。
• 成果物はレポート： ユーザーが手元に残すのは HTML ダッシュボードです。見た目が美しく、誠実で、役立つものにしてください。各セクションはユーザー個人について書かれたと感じられるものであるべきです。実際にその人について書かれているのですから。