Back to Details

plannotator-compound

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Compound Planning Analysis

复合规划分析

You are conducting a comprehensive research analysis of a user's Plannotator plan archive. The goal: extract patterns from their denied plans, reduce them into actionable insights, and produce an elegant HTML dashboard report.
This is a multi-phase process. Each phase must complete fully before the next begins. Research integrity is paramount — every file must be read, no skipping.
你将对用户的Plannotator计划归档文件进行全面的研究分析。目标是：从被拒绝的计划中提取模式，将其转化为可操作的洞察，并生成一份美观的HTML仪表盘报告。
这是一个多阶段流程，每个阶段必须完全完成后才能进入下一阶段。研究的完整性至关重要——必须读取每一个文件，不得跳过。

Source Selection

数据源选择

Before starting the analysis, determine which data source is available.
  1. Plannotator mode (first-class) — Determine the Plannotator data directory: use 
    $PLANNOTATOR_DATA_DIR
    if set, otherwise 
    ~/.plannotator
    . Check the 
    plans/
    subdirectory there. If it exists and contains 
    *-denied.md
    files, use this mode. The entire workflow below is written for Plannotator data.
  2. Claude Code fallback mode — If the Plannotator archive is absent or contains no denied plans, check 
    ~/.claude/projects/
    . If present, read references/claude-code-fallback.md before continuing. That reference explains how to use the bundled parser at scripts/extract_exit_plan_mode_outcomes.py to extract denial reasons from Claude Code JSONL transcripts. Every phase below has a short note explaining what changes in fallback mode — the reference file has the details.
  3. Neither available — Ask the user for their Plannotator plans directory or Claude Code projects directory. Do not guess.
开始分析前，先确定可用的数据源。
  1. Plannotator模式（优先选择） —— 确定Plannotator数据目录：如果设置了
    $PLANNOTATOR_DATA_DIR
    则使用该目录，否则使用
    ~/.plannotator
    。检查该目录下的
    plans/
    子目录。如果该目录存在且包含
    *-denied.md
    文件，则使用此模式。以下整个工作流均针对Plannotator数据编写。
  2. Claude Code fallback模式 —— 如果Plannotator归档不存在或不包含被拒绝的计划，检查
    ~/.claude/projects/
    。如果存在，在继续之前先阅读references/claude-code-fallback.md。该参考文档说明了如何使用scripts/extract_exit_plan_mode_outcomes.py中的捆绑解析器从Claude Code JSONL转录文件中提取拒绝原因。以下每个阶段都有简短说明，解释在fallback模式下的变化——详细信息请参考该参考文件。
  3. 两者均不可用 —— 向用户索要他们的Plannotator计划目录或Claude Code项目目录，不得猜测。

Phase 0: Locate Plans & Check for Previous Reports

阶段0：定位计划文件并检查历史报告

Use the mode chosen in Source Selection above.
Plannotator mode: Verify the plans directory contains 
*-denied.md
files. If none exist, fall back to Claude Code mode before stopping.
Claude Code fallback mode: Run the bundled parser per the fallback reference to build the denial-reason dataset. Create 
/tmp/compound-planning/
if needed.
In either mode, proceed to Previous Report Detection below.
使用上述数据源选择阶段确定的模式。
Plannotator模式： 验证计划目录是否包含
*-denied.md
文件。如果不存在，在停止前切换到Claude Code模式。
Claude Code fallback模式： 根据fallback参考文档运行捆绑解析器，构建拒绝原因数据集。必要时创建
/tmp/compound-planning/
目录。
无论使用哪种模式，继续执行以下的历史报告检测步骤。

Previous Report Detection

历史报告检测

After locating the plans directory, check for existing reports:
ls ${PLANNOTATOR_DATA_DIR:-~/.plannotator}/plans/compound-planning-report*.html
Reports follow a versioned naming scheme:
  • First report: 
    compound-planning-report.html
  • Subsequent reports: 
    compound-planning-report-v2.html
    , 
    compound-planning-report-v3.html
    , etc.
If one or more reports exist, determine the latest one (highest version number). Get its filesystem modification date using 
stat
(macOS: 
stat -f %Sm -t %Y-%m-%d
, Linux: 
stat -c %y | cut -d' ' -f1
). This is the cutoff date.
Present the user with a choice:
"I found a previous report (
compound-planning-report-v{N}.html
) last updated on {CUTOFF_DATE}. I can either:
  1. Incremental — Only analyze files dated after {CUTOFF_DATE}, saving tokens and building on previous findings
  2. Full — Re-analyze the entire archive from scratch
Which would you prefer?"
Wait for the user's response before proceeding.
If incremental: Filter all subsequent phases to only process files with dates after the cutoff date. The new report version will note in its header narrative that it covers the period from {CUTOFF_DATE} to present, and reference the previous report for earlier findings. The inventory (Phase 1) should still count ALL files for overall stats, but clearly separate "new since last report" counts.
If full: Proceed normally with all files, but still use the next version number for the output filename.
If no previous report exists: Proceed normally. The output filename will be 
compound-planning-report.html
(no version suffix for the first report).
定位计划目录后，检查是否存在现有报告：
ls ${PLANNOTATOR_DATA_DIR:-~/.plannotator}/plans/compound-planning-report*.html
报告遵循版本化命名规则：
  • 第一份报告：
    compound-planning-report.html
  • 后续报告：
    compound-planning-report-v2.html
    、
    compound-planning-report-v3.html
    等
如果存在一份或多份报告，确定最新的报告（版本号最高）。使用
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}之后的文件，节省token并基于之前的发现进行扩展
  2. 全量分析 —— 从头开始重新分析整个归档文件
你更倾向于哪种方式？"
等待用户回复后再继续。
如果选择增量分析： 过滤后续所有阶段，仅处理日期晚于截止日期的文件。新报告版本将在标题说明中注明其覆盖的时间段为{CUTOFF_DATE}至当前，并引用历史报告查看早期发现。阶段1的统计仍需统计所有文件的整体数据，但要明确区分“自上次报告以来新增”的统计数据。
如果选择全量分析： 正常处理所有文件，但输出文件名仍使用下一个版本号。
如果没有历史报告： 正常处理。输出文件名为
compound-planning-report.html
（第一份报告无版本后缀）。

Phase 1: Inventory

阶段1：统计盘点

Count and report the dataset. Always count ALL files for overall stats, regardless of whether this is an incremental or full run:
- *-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
Note: Ignore 
*.annotations.md
files entirely. Denied files already contain the full plan text plus all reviewer feedback appended after a 
---
separator. Annotation files are redundant subsets of this content — reading both would double-count feedback.
If incremental mode: After the total counts, separately report the counts for files dated after the cutoff date only:
New since {CUTOFF_DATE}:
- *-denied.md files: X (of Y total)
- New date range: {CUTOFF_DATE} to {LATEST_DATE}
- New days spanned: N
If fewer than 3 new denied files exist since the cutoff, warn the user:
"Only {N} new denied plans since the last report. The incremental analysis may be thin. Would you like to proceed or switch to a full analysis?"
Also run 
wc -l
across all 
*-approved.md
files to get average lines per approved plan. This tells the user whether their plans are staying lightweight or bloating over time. You do not need to read approved plan contents — just their line counts. If possible, break this down by time period (e.g., monthly) to show whether plan size changed.
Dates appear in filenames in YYYY-MM-DD format, sometimes as a prefix (2026-01-07-name-approved.md) and sometimes embedded (name-2026-03-15-approved.md). Extract dates from all filenames.
Tell the user what you found and that you're beginning the extraction.
Claude Code fallback mode: The Plannotator inventory fields above do not apply. Follow the inventory instructions in references/claude-code-fallback.md instead — report the denial-reason dataset assembled by the parser.
统计并报告数据集。无论增量还是全量运行，始终统计所有文件的整体数据：
- *-approved.md文件数量
- *-denied.md文件数量
- 日期范围（文件名中最早到最晚的日期）
- 覆盖的总天数
- 修订率：被拒绝数/(通过数+被拒绝数) —— 这是仪表盘第1部分中使用的“编码前X%的计划需要修订”统计数据
注意： 完全忽略
*.annotations.md
文件。被拒绝的文件已包含完整的计划文本以及
---
分隔符后附加的所有审核反馈。注释文件是这些内容的冗余子集——同时读取两者会导致反馈重复统计。
如果是增量分析： 在总统计之后，单独报告截止日期之后的文件统计：
自{CUTOFF_DATE}以来新增：
- *-denied.md文件：X（总计Y）
- 新增日期范围：{CUTOFF_DATE}至{LATEST_DATE}
- 新增覆盖天数：N
如果自截止日期以来新增的被拒绝文件少于3个，向用户发出警告：
"自上次报告以来仅新增{N}份被拒绝的计划。增量分析的结果可能不够充分。你是否要继续或切换为全量分析？"
同时对所有
*-approved.md
文件运行
wc -l
命令，获取每份通过计划的平均行数。这能让用户了解他们的计划是保持简洁还是变得冗长。无需读取通过计划的内容——只需统计行数。如果可能，按时间段（如每月）细分，显示计划大小是否发生变化。
文件名中的日期格式为YYYY-MM-DD，有时作为前缀（2026-01-07-name-approved.md），有时嵌入其中（name-2026-03-15-approved.md）。从所有文件名中提取日期。
告知用户你的发现，并说明即将开始提取工作。
Claude Code fallback模式： 上述Plannotator统计字段不适用。请遵循references/claude-code-fallback.md中的统计说明——报告由解析器整理的拒绝原因数据集。

Phase 2: Map — Parallel Extraction

阶段2：映射——并行提取

This is the most time-intensive phase. You must read EVERY 
*-denied.md
file in scope. Do not skip files. Do not summarize early.
In scope means: all denied files if running a full analysis, or only denied files dated after the cutoff date if running incrementally. In incremental mode, only process files whose embedded YYYY-MM-DD date is strictly after the cutoff.
Claude Code fallback mode: The parser output is the clean source dataset. Read the fallback reference for the extraction prompt and batching strategy specific to JSON part files. Do not go back to raw 
.jsonl
logs unless the parser fails or the user asks for audit-level verification.
Important: Only read 
*-denied.md
files. Do NOT read approved plans, annotation files, or diff files. Each denied file contains the full plan text followed by a 
---
separator and the reviewer's feedback — everything needed for analysis is in one file.
这是最耗时的阶段。你必须读取范围内的每一个
*-denied.md
文件，不得跳过任何文件，不得提前汇总。
范围内指：如果是全量分析，则所有被拒绝文件；如果是增量分析，则仅日期晚于截止日期的被拒绝文件。在增量模式下，仅处理嵌入的YYYY-MM-DD日期严格晚于截止日期的文件。
Claude Code fallback模式： 解析器输出为干净的源数据集。请阅读fallback参考文档，了解针对JSON分片文件的提取提示词和批处理策略。除非解析器失败或用户要求审计级验证，否则不要返回原始
.jsonl
日志。
重要提示： 仅读取
*-denied.md
文件。不得读取通过的计划、注释文件或差异文件。每个被拒绝的文件包含完整的计划文本，以及
---
分隔符后的审核反馈——分析所需的所有内容都在一个文件中。

Batching Strategy

批处理策略

All extraction agents should use 
model: "haiku"
— they're doing straightforward file reading and structured extraction, not reasoning. Haiku is faster and cheaper for this work.
The approach depends on dataset size:
Tiny datasets (≤ 10 total files): Read all files directly in the main agent — no need for sub-agents. Just read them sequentially and proceed to Phase 3.
Small datasets (11-30 files): Launch 2-3 parallel Haiku agents, splitting files roughly evenly.
Medium datasets (31-80 files): Launch 4-6 parallel Haiku agents (~10-15 files each). Split by file type and/or time period.
Large datasets (80+ files): Launch as many parallel Haiku agents as needed to keep each batch around 10-15 files. Split by the natural time boundaries in the data (months, quarters, or whatever groupings produce balanced batches). If one time period dominates (e.g., the most recent month has 3x the files), split that period into multiple batches.
Launch all extraction agents in parallel using the Agent tool with 
run_in_background: true
and 
model: "haiku"
.
所有提取Agent应使用
model: "haiku"
——它们执行的是简单的文件读取和结构化提取，而非推理任务。Haiku在此类工作中速度更快、成本更低。
方法取决于数据集大小：
小型数据集（≤10个文件）： 在主Agent中直接读取所有文件——无需子Agent。只需按顺序读取它们，然后进入阶段3。
较小数据集（11-30个文件）： 启动2-3个并行的Haiku Agent，大致平均拆分文件。
中等数据集（31-80个文件）： 启动4-6个并行的Haiku Agent（每个处理约10-15个文件）。按文件类型和/或时间段拆分。
大型数据集（80+个文件）： 启动足够多的并行Haiku Agent，使每个批次保持在10-15个文件左右。按数据中的自然时间边界（月份、季度或任何能产生均衡批次的分组）拆分。如果某个时间段占比过大（例如最近一个月的文件数量是其他月份的3倍），则将该时间段拆分为多个批次。
使用Agent工具，设置
run_in_background: true
和
model: "haiku"
，并行启动所有提取Agent。

Output Files

输出文件

Each extraction agent must write its results to a clean output file rather than relying on the agent task output (which contains interleaved JSONL framework logs that are difficult to parse). Instruct each agent to write to:
/tmp/compound-planning/extraction-{batch-name}.md
Create the 
/tmp/compound-planning/
directory before launching agents. The reduce agent in Phase 3 will read these clean files directly.
每个提取Agent必须将结果写入干净的输出文件，而非依赖Agent任务输出（其中包含交错的JSONL框架日志，难以解析）。指示每个Agent写入：
/tmp/compound-planning/extraction-{batch-name}.md
启动Agent前创建
/tmp/compound-planning/
目录。阶段3中的归约Agent将直接读取这些干净的文件。

Extraction Prompt

提取提示词

Each agent receives this instruction (adapt the time period, file list, and output path):
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.
每个Agent将收到以下指令（调整时间段、文件列表和输出路径）：
你正在从被拒绝的计划文件中提取结构化数据，用于模式分析。

目录：[计划目录]
要读取的文件：[特定*-denied.md文件列表]
输出：将完整结果写入[输出文件路径]

每个被拒绝的文件包含两部分，由---行分隔：
1. 计划文本（---上方）
2. 审核反馈和注释（---下方）

读取列表中的每一个文件。针对每个文件，提取：
- 计划名称/主题（来自---上方的计划文本）
- 拒绝原因或给出的反馈（来自---下方——记录实际使用的措辞）
- 具体要求修改的内容
- 反馈类型（由内容决定分类——不要强行适配预定义类型。常见类型包括：范围问题、方法分歧、信息缺失、流程要求、质量问题、UX/设计问题、命名争议、澄清请求、测试/流程拒绝——但用户的实际模式可能不同）
- 审核者使用的任何特定短语或重复语言
- 如果存在单独的注释（带引用文本和审核者评论的编号反馈项）
- 日期（从文件名中提取）

不得跳过任何文件。每个文件对应一条记录。

每条记录格式如下：
**[文件名]**
- 日期：...
- 主题：...
- 拒绝原因：...
- 反馈类型：...
- 具体要求：...
- 显著短语：...
- 注释：[数量，每条简要总结]
---

处理完所有文件后，将完整结果写入[输出文件路径]。在文件末尾注明处理的文件总数。

While Agents Run

Agent运行期间

Track completion. As each agent finishes, note the count of files it processed. Verify the total matches the inventory from Phase 1. If any agent's count is short, flag it and consider re-launching for the missing files.
If an agent times out (possible with large batches — a batch of 128 files can take 8+ minutes), re-launch it for just the unprocessed files. Check the output file to see how far it got before timing out.
跟踪完成情况。每个Agent完成后，记录其处理的文件数量。验证总数是否与阶段1的统计一致。如果任何Agent的数量不足，标记出来并考虑重新启动以处理缺失的文件。
如果Agent超时（大批次可能出现——128个文件的批次可能需要8分钟以上），仅针对未处理的文件重新启动它。检查输出文件，查看它在超时前处理到了哪里。

Phase 3: Reduce — Pattern Analysis

阶段3：归约——模式分析

Once ALL extraction agents have completed (or all files have been read for tiny datasets), proceed with the reduction. Reduction agents should use 
model: "sonnet"
— this phase requires real analytical reasoning, not just file reading.
所有提取Agent完成后（或小型数据集的所有文件读取完成后），进入归约阶段。归约Agent应使用
model: "sonnet"
——此阶段需要真正的分析推理，而非仅文件读取。

Reduction Strategy

归约策略

The approach depends on how many extraction files were produced:
Standard (≤ 20 extraction files): Launch a single Sonnet agent to read all extraction files and produce the full analysis. This covers most datasets.
Large (21+ extraction files): Use a two-stage reduce:
  1. Stage 1 — Partial reduces: Split the extraction files into groups of 4-6. Launch parallel Sonnet agents, each reading one group and producing a partial analysis with the same sections listed below. Each writes to 
    /tmp/compound-planning/partial-reduce-{N}.md
    .
  2. Stage 2 — Final reduce: A single Sonnet agent reads all partial reduce files and synthesizes them into the final comprehensive analysis. This agent merges taxonomies, combines counts, deduplicates patterns, and reconciles any conflicting categorizations across partials.
Claude Code fallback mode: The reduction phase is the same. The only upstream difference is that extraction files were derived from normalized denial-reason JSON instead of Plannotator markdown files.
方法取决于生成的提取文件数量：
标准情况（≤20个提取文件）： 启动一个Sonnet Agent，读取所有提取文件并生成完整分析。这适用于大多数数据集。
大型情况（21+个提取文件）： 使用两阶段归约：
  1. 阶段1——部分归约： 将提取文件分成4-6个组。启动并行的Sonnet Agent，每个读取一组并生成包含以下相同部分的部分分析。每个Agent将结果写入
    /tmp/compound-planning/partial-reduce-{N}.md
    。
  2. 阶段2——最终归约： 一个单独的Sonnet Agent读取所有部分归约文件，并将它们合成为最终的综合分析。此Agent将合并分类法、汇总统计、去重模式，并协调各部分之间的任何冲突分类。
Claude Code fallback模式： 归约阶段相同。唯一的上游差异是提取文件来自标准化的拒绝原因JSON，而非Plannotator的markdown文件。

Reduction Prompt

归约提示词

Give each reduction agent this prompt (adapt file paths for single vs multi-stage):
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 ...]
The reduction agent's job is to let the data speak. Do not impose a predetermined framework — discover what's actually there. The analysis must produce:
向每个归约Agent提供以下提示词（针对单阶段与多阶段调整文件路径）：
你是一名数据科学家，正在对用户被拒绝的计划归档文件进行Map-Reduce分析的归约阶段。

读取[文件路径]下的所有提取文件

这些文件包含每个被拒绝计划文件的结构化提取内容。每个提取内容包括计划主题、拒绝反馈、注释和审核者语言。你的任务：汇总所有内容，发现模式，聚类为分类法，并生成综合分析。

要详尽全面。使用真实统计数据。引用数据中的真实短语。这是研究——不得含糊其辞，不得编造内容。

将完整结果写入[输出文件路径]。

生成以下部分：
[...以下列出的部分...]
归约Agent的任务是让数据自己说话。不要强加预先设定的框架——发现实际存在的内容。分析必须生成：

1. Denial Reason Taxonomy

1. 拒绝原因分类法

Categorize every denial into a finite set of types that emerge from the data. Count occurrences. Show percentages. Include real example quotes for each type. Aim for 8-15 categories — enough to be specific, few enough to be scannable. Let the user's actual feedback determine what the categories are.
将每个拒绝归为从数据中得出的有限类型集合。统计出现次数，显示百分比。为每种类型包含真实的示例引用。目标是8-15个类别——足够具体，同时易于浏览。让用户的实际反馈决定类别是什么。

2. Top Feedback Patterns (ranked by frequency)

2. 顶级反馈模式（按频率排序）

The 5-10 most recurring patterns. For each: what the reviewer consistently asks for, 3+ example quotes from different files, and whether the pattern changed over time.
5-10个最常见的重复模式。针对每个模式：审核者持续要求的内容、来自不同文件的3个以上示例引用，以及该模式是否随时间变化。

3. Recurring Phrases

3. 重复短语

Exact phrases the reviewer uses repeatedly, with counts and what they signal. These are the reviewer's vocabulary — their shorthand for what they care about.
审核者重复使用的确切短语，附带出现次数及其含义。这些是审核者的常用词汇——他们表达关注点的简写方式。

4. What the Reviewer Values (implicit preferences)

4. 审核者重视的内容（隐含偏好）

Derived from patterns — what does this specific person care about most? Quality? Speed? Narrative? Architecture? Process? Simplicity? Rank by evidence strength. This section should feel like a personality profile of the reviewer's standards.
从模式中推导——这位特定的审核者最关心什么？质量？速度？叙事性？架构？流程？简洁性？按证据强度排序。此部分应感觉像是审核者标准的个性剖析。

5. What Agents Consistently Get Wrong

5. Agent持续犯的错误

The flip side — what recurring mistakes trigger denials? What should agents stop doing for this reviewer?
相反的一面——哪些重复错误会导致拒绝？Agent应该停止做哪些事情来满足这位审核者的要求？

6. Structural Requests

6. 结构化要求

What plan structure does the reviewer consistently demand? Required sections, ordering, format preferences, level of detail expected.
审核者持续要求的计划结构是什么？必填部分、顺序、格式偏好、预期的详细程度。

7. Evolution Over Time

7. 随时间的演变

How feedback patterns changed across the time span. Group by whatever natural time boundaries exist in the data (weeks for short spans, months for longer ones). Did expectations mature? Did new patterns emerge? What shifted? If the dataset spans less than a month, note that evolution analysis is limited but still look for any progression from early to late files.
反馈模式在整个时间段内如何变化。按数据中的自然时间边界分组（短时间段按周，长时间段按月）。期望是否变得更高？是否出现新的模式？发生了哪些变化？如果数据集跨度不足一个月，注明演变分析有限，但仍需寻找从早期到晚期文件的任何进展。

8. Actionable Prompt Instructions

8. 可操作的提示词指令

The most important output. Based on all patterns: specific numbered instructions that could be embedded in a planning prompt to prevent the most common denial reasons. Write these as actual directives an agent could follow. Be specific to this user's patterns — generic advice like "write good plans" is worthless. Each instruction should trace back to a real, frequent denial pattern.
After writing the instructions, calculate what percentage of denials they would address (count how many denials fall into categories covered by the instructions vs total denials). Report this percentage — it will be different for every user.
最重要的输出。基于所有模式：可嵌入到规划提示词中的具体编号指令，以防止最常见的拒绝原因。将这些写为Agent可以遵循的实际指令。要针对用户的具体模式——像“写好计划”这样的通用建议毫无价值。每条指令都应追溯到真实、频繁出现的拒绝模式。
写完指令后，计算它们能解决的拒绝百分比（统计属于指令覆盖类别的拒绝数与总拒绝数的比例）。报告此百分比——每个用户的结果都会不同。

Phase 4: Generate the HTML Dashboard

阶段4：生成HTML仪表盘

Build a single, self-contained HTML file as the final deliverable. Save it to the user's plans directory with a versioned filename:
  • First ever report: 
    compound-planning-report.html
  • Second report: 
    compound-planning-report-v2.html
  • Third report: 
    compound-planning-report-v3.html
  • And so on.
The version number was determined in Phase 0 based on existing reports found.
If this is an incremental report, the header should indicate the analysis period (e.g., "March 15 – March 31, 2026") and include a subtitle noting "Incremental analysis — see v{N-1} for earlier findings." The narrative in section 1 should frame findings as what's new or changed since the last report, not as a complete picture. Overall stats in the header (file counts, revision rate) should still reflect the full archive for context.
Read the template at 
assets/report-template.html
for the design language only. The template contains example data from a previous analysis — ignore all data values, quotes, and percentages in the template. Use only its visual design: colors, typography, spacing, component styles, and layout patterns.
构建单个自包含的HTML文件作为最终交付成果。将其保存到用户的计划目录，使用版本化文件名：
  • 第一份报告：
    compound-planning-report.html
  • 第二份报告：
    compound-planning-report-v2.html
  • 第三份报告：
    compound-planning-report-v3.html
  • 以此类推
版本号在阶段0中根据发现的现有报告确定。
如果是增量报告，标题应注明分析时间段（例如“2026年3月15日 – 3月31日”），并包含副标题注明“增量分析——查看v{N-1}版本了解早期发现”。第1部分的叙述应将发现描述为自上次报告以来的新增或变化，而非完整情况。标题中的整体统计数据（文件数量、修订率）仍需反映整个归档文件以提供上下文。
仅参考
assets/report-template.html
模板的设计语言。模板包含来自之前分析的示例数据——忽略模板中的所有数据值、引用和百分比。仅使用其视觉设计：颜色、排版、间距、组件样式和布局模式。

Design Language (from template)

设计语言（来自模板）

  • Palette: Light mode, warm off-white (#FDFCFB), text in slate scale, amber for highlights/accents, emerald for positive, rose for negative, indigo for action elements
  • Typography: Playfair Display (serif, for narrative headings), Inter (sans, for body/data), JetBrains Mono (mono, for code/phrases) — Google Fonts CDN
  • Layout: Single-column, max-width 1024px, generous vertical whitespace (128px between major sections), editorial/narrative-first aesthetic
  • Tone: Calm, reflective, authoritative. Like a personal retrospective journal, not a monitoring dashboard.
  • 调色板： 浅色模式，暖灰白色（#FDFCFB），文本为石板灰系列，琥珀色用于高亮/强调，翡翠绿表示正面，玫瑰红表示负面，靛蓝色用于操作元素
  • 排版： Playfair Display（衬线字体，用于叙述标题），Inter（无衬线字体，用于正文/数据），JetBrains Mono等宽字体（用于代码/短语）——使用Google Fonts CDN
  • 布局： 单列，最大宽度1024px，充足的垂直留白（主要部分之间128px），编辑/叙事优先的美学风格
  • 语气： 冷静、反思、权威。像个人回顾日志，而非监控仪表盘。

Page Frame (header + footer)

页面框架（页眉+页脚）

Before the 7 sections, the page has:
  • Header: Report title on the left (Playfair Display, ~36px), project name + date range below it in light meta text. On the right: file counts in mono (e.g., "223 denials · 71 days"). Separated from content by a bottom border. Generous bottom padding before section 1.
  • Footer: After section 7. Top border, centered italic Playfair Display tagline summarizing the corpus (e.g., "Analysis of X denied plans from the Plannotator archive.").
在7个部分之前，页面包含：
  • 页眉： 左侧为报告标题（Playfair Display，约36px），下方为项目名称+日期范围的浅色元文本。右侧为等宽字体显示的文件统计（例如“223次拒绝 · 71天”）。与内容之间用底部边框分隔。第1部分之前有充足的底部内边距。
  • 页脚： 在第7部分之后。顶部边框，居中的斜体Playfair Display标语，总结语料库（例如“对Plannotator归档中X份被拒绝计划的分析”）。

Dashboard Section Order (7 sections)

仪表盘部分顺序（7个部分）

The report follows this exact section order. Each section builds on the previous one — the flow moves from "what happened" through "why" to "what to do about it":
  1. The story in the data — An editorial narrative paragraph (Playfair Display serif, ~26px) that tells the headline finding in prose. Not bullet points — a real paragraph that reads like the opening of an article. Alongside it, a KPI sidebar with 3 key metrics (the top denial percentage, the overall revision rate, and the number of distinct denial categories found). Use an amber inline highlight on the most striking number in the narrative.
  2. Why plans get denied — The taxonomy as a ranked list. Each row: rank number (mono), category label, a thin 4px progress bar (top item in amber-500, rest in slate-300), percentage (mono), and for the top entries, a real italic quote from the data below the label. Show the top 10 categories or however many the data supports (minimum 5).
  3. How expectations evolved — One card per natural time period. Each card has: the period name in serif, a theme phrase in colored uppercase (different color per period to show progression), a description paragraph, and a stat line at the bottom (e.g., "X denials · Y narrative requests"). If the data spans less than 3 distinct periods, use 2 cards or even a single card with internal progression noted.
  4. What works vs what doesn't — Two side-by-side cards. Left: green-tinted (emerald-50/50 bg, emerald-100 border) with traits of plans that succeed for this reviewer. Right: red-tinted (rose-50/50 bg, rose-100 border) with what agents keep getting wrong. Both derived from the reduction analysis. Bulleted with small colored dots. 5-8 items per card.
  5. The actionable output — The diagnostic payoff. Opens with a Playfair Display narrative sentence stating how many prompt instructions were derived and what estimated percentage of denials they address (use the real calculated percentage from Phase 3, not a generic number). Then the top 3 most impactful improvements as numbered items, each with an amber number, bold title, and one-line description. This section bridges the analysis and the full prompt that follows.
  6. Your most-used phrases — Grid of chips (2-col mobile, 3-col desktop). Each chip: monospace quoted phrase on the left, frequency count on the right. White bg, slate-200 border, rounded-12px. Show 9-12 of the most recurring phrases found. These should be the reviewer's actual words — their verbal fingerprint.
  7. The corrective prompt — Dark panel (slate-900 bg, white text, rounded-3xl, shadow-xl). Opens with a Playfair intro sentence about the instructions. Then a dark code block (slate-800/80 bg, amber-200 monospace text) containing the full numbered prompt instructions from Phase 3. Include a copy-to-clipboard button that works (JS included). Below the code block: a gradient glow card (indigo-to-purple blurred halo behind a white card) with a closing message that these instructions are personal — derived from the user's own feedback, their own language, their own standards.
报告严格遵循此部分顺序。每个部分基于前一部分构建——流程从“发生了什么”到“为什么”再到“该怎么做”：
  1. 数据中的故事 —— 一段编辑性叙述段落（Playfair Display衬线字体，约26px），用散文形式讲述核心发现。不要使用项目符号——要像文章开头一样的真实段落。旁边是KPI侧边栏，包含3个关键指标（最高拒绝百分比、整体修订率、发现的不同拒绝类别数量）。在叙述中用琥珀色内联高亮最引人注目的数字。
  2. 计划被拒绝的原因 —— 分类法按排名列表展示。每一行：排名数字（等宽字体）、类别标签、细4px进度条（排名第一的为琥珀色-500，其余为石板灰-300）、百分比（等宽字体），排名靠前的条目在标签下方显示真实的斜体引用。显示排名前10的类别或数据支持的数量（最少5个）。
  3. 期望如何演变 —— 每个自然时间段对应一个卡片。每个卡片包含：时间段名称（衬线字体）、彩色大写的主题短语（每个时间段使用不同颜色以显示进展）、描述段落，以及底部的统计行（例如“X次拒绝 · Y次叙事请求”）。如果数据跨度少于3个不同时间段，使用2个卡片甚至单个卡片，注明内部进展。
  4. 有效做法vs无效做法 —— 两个并排的卡片。左侧：绿色色调（翡翠绿-50/50背景，翡翠绿-100边框），包含符合该审核者要求的计划特征。右侧：红色色调（玫瑰红-50/50背景，玫瑰红-100边框），包含Agent持续犯的错误。两者均来自归约分析。使用带彩色小点的项目符号，每个卡片5-8项。
  5. 可操作的输出 —— 诊断成果。开头用Playfair Display叙述句，说明推导了多少条提示词指令以及它们能解决的拒绝百分比（使用阶段3中计算的真实百分比，而非通用数字）。然后是3个最具影响力的改进措施，编号显示，每个包含琥珀色数字、加粗标题和一行描述。此部分连接分析与后续的完整提示词。
  6. 最常用的短语 —— 芯片网格（移动端2列，桌面端3列）。每个芯片：左侧为等宽字体的引用短语，右侧为出现次数。白色背景，石板灰-200边框，圆角12px。显示9-12个最常见的重复短语。这些应该是审核者的真实措辞——他们的语言特征。
  7. 纠正性提示词 —— 深色面板（石板灰-900背景，白色文本，圆角3xl，阴影xl）。开头用Playfair介绍句说明指令。然后是深色代码块（石板灰-800/80背景，琥珀色-200等宽字体文本），包含阶段3中的完整编号提示词指令。包含一个可用的复制到剪贴板按钮（已包含JS）。代码块下方：渐变发光卡片（白色卡片背后有靛蓝到紫色的模糊光晕），包含结束语，说明这些指令是个性化的——源自用户自己的反馈、语言和标准。

Adaptation Rules

适配规则

  • If the user has < 3 months of data, reduce the evolution section to fewer cards
  • If most denied files lack feedback below the 
    ---
    (bare denials with no annotations), note this in the narrative — the analysis will be thinner
  • Claude Code fallback mode: Explicitly label the report source as Claude Code 
    ExitPlanMode
    denial reasons. Do not fabricate Plannotator-only fields such as annotation counts or approved-plan line counts. See the fallback reference for KPI substitutes and footer/provenance guidance.
  • If fewer than 5 denial categories emerge, combine the taxonomy and patterns sections into one
  • If the dataset is very small (< 20 files), the narrative should acknowledge the limited sample size and frame findings as preliminary
  • The number of prompt instructions will vary per user — could be 8 or 20. Don't force exactly 17. Let the data determine the count.
  • The top 3 actionable items in section 5 must be the 3 that cover the largest share of denials, not the 3 that sound most impressive
  • 如果用户的数据不足3个月，将演变部分减少为更少的卡片
  • 如果大多数被拒绝文件在
    ---
    下方缺少反馈（仅拒绝无注释），在叙述中注明——分析结果会不够全面
  • Claude Code fallback模式： 明确标记报告来源为Claude Code 
    ExitPlanMode
    拒绝原因。不得编造仅Plannotator有的字段，如注释数量或通过计划的行数。参考fallback文档获取KPI替代方案和页脚/来源说明指导。
  • 如果出现的拒绝类别少于5个，将分类法和模式部分合并为一个
  • 如果数据集非常小（<20个文件），叙述应承认样本量有限，并将发现描述为初步结果
  • 提示词指令的数量因用户而异——可能是8条或20条。不要强行设定为17条。让数据决定数量。
  • 第5部分中的前3个可操作项必须是覆盖拒绝比例最大的3个，而非听起来最吸引人的3个

Key Rules

关键规则

  1. Every number must come from the real analysis — no fabricated data
  2. Every quote must be a real quote from a real file
  3. The taxonomy percentages must be calculated from real counts
  4. The prompt instructions must trace back to actual denial patterns
  5. The copy button on the prompt block must work (include the JS)
After generating, open the file in the user's browser.
  1. 每个数字必须来自真实分析——不得编造数据
  2. 每个引用必须来自真实文件的真实引用
  3. 分类法百分比必须根据真实统计计算
  4. 提示词指令必须追溯到实际拒绝模式
  5. 提示词块上的复制按钮必须可用（包含JS）
生成后，在用户浏览器中打开该文件。

Phase 5: Summary

阶段5：总结

Tell the user:
  • How many denied files were analyzed
  • If incremental: how many were new since the last report
  • The top 3 denial patterns found
  • The estimated percentage of denials the prompt instructions would address
  • The single most impactful prompt improvement
  • Where the report was saved (including version number)
  • If incremental: remind the user that earlier findings are in the previous report
Claude Code fallback mode: Adapt the summary per the fallback reference — report human denial reasons analyzed and total 
ExitPlanMode
attempts scanned instead of Plannotator file counts.
告知用户：
  • 分析了多少份被拒绝的文件
  • 如果是增量分析：自上次报告以来新增了多少份
  • 发现的前3个拒绝模式
  • 提示词指令预计能解决的拒绝百分比
  • 最具影响力的单个提示词改进措施
  • 报告保存的位置（包括版本号）
  • 如果是增量分析：提醒用户早期发现在历史报告中
Claude Code fallback模式： 根据fallback参考文档调整总结——报告分析的人工拒绝原因数量和扫描的
ExitPlanMode
尝试总数，而非Plannotator文件数量。

Phase 6: Improvement Hook

阶段6：改进钩子

After presenting the summary, ask the user if they want to enable an improvement hook — this takes the corrective prompt instructions from section 7 of the report and writes them to a file that Plannotator's 
EnterPlanMode
hook can inject into every future planning session automatically.
"Would you like to enable the improvement hook? This will save the corrective prompt instructions to a file that gets automatically injected into all future planning sessions — so Claude sees your feedback patterns before writing any plan."
If yes:
The hook file lives at:
${PLANNOTATOR_DATA_DIR:-~/.plannotator}/hooks/compound/enterplanmode-improve-hook.txt
Create the 
hooks/compound/
directory inside the data directory if it doesn't exist.
The file contents should be the corrective prompt instructions from Phase 3 — the same numbered list that appears in section 7 of the HTML report. Write them as plain text, one instruction per line, prefixed with their number. No HTML, no markdown fences, no preamble — just the instructions themselves. The hook system will inject this file's contents as-is into the planning context.
If the file already exists:
Read the existing file and present the user with a choice:
"An improvement hook already exists from a previous analysis. I can:
  1. Replace — Overwrite with the new instructions (the old ones are gone)
  2. Merge — Combine both, deduplicating overlapping instructions and keeping the best version of each
  3. Keep existing — Leave the current hook as-is, skip this step
Which would you prefer?"
  • Replace: Overwrite the file with the new instructions.
  • Merge: Read the existing instructions, compare with the new ones, and produce a merged set. Remove duplicates (same intent even if worded differently). When two instructions cover the same pattern, keep the more specific or actionable version. Re-number the final list sequentially. Write the merged result to the file. Show the user what changed (added N new, removed N redundant, kept N existing).
  • Keep existing: Do nothing, move on.
If no: Skip this phase entirely.
展示总结后，询问用户是否要启用改进钩子——这会将报告第7部分中的纠正性提示词指令写入一个文件，Plannotator的
EnterPlanMode
钩子会在未来所有规划会话中自动注入该文件内容。
"你是否要启用改进钩子？这会将纠正性提示词指令保存到一个文件，该文件会自动注入到所有未来的规划会话中——这样Claude在编写任何计划之前就能了解你的反馈模式。"
如果用户同意：
钩子文件位于：
${PLANNOTATOR_DATA_DIR:-~/.plannotator}/hooks/compound/enterplanmode-improve-hook.txt
如果数据目录中不存在
hooks/compound/
目录，创建该目录。
文件内容应为阶段3中的纠正性提示词指令——与HTML报告第7部分中相同的编号列表。将它们写为纯文本，每条指令一行，前面加上编号。不要HTML、markdown围栏或前言——仅包含指令本身。钩子系统会将此文件内容原样注入到规划上下文中。
如果文件已存在：
读取现有文件并向用户提供选择：
"已存在来自之前分析的改进钩子。我可以：
  1. 替换 —— 用新指令覆盖（旧指令将被删除）
  2. 合并 —— 合并两者，去重重叠指令，保留每个指令的最佳版本
  3. 保留现有 —— 保持当前钩子不变，跳过此步骤
你更倾向于哪种方式？"
  • 替换： 用新指令覆盖文件。
  • 合并： 读取现有指令，与新指令比较，生成合并后的集合。删除重复项（意图相同即使措辞不同）。当两条指令覆盖相同模式时，保留更具体或更具可操作性的版本。将最终列表重新按顺序编号。将合并结果写入文件。向用户展示变化（新增N条，删除N条冗余，保留N条现有）。
  • 保留现有： 不执行任何操作，继续。
如果用户不同意： 完全跳过此阶段。

Important Notes

重要说明

  • Data source priority: Plannotator is the first-class path. Claude Code log analysis is the secondary path for users without Plannotator archives.
  • Research integrity: Every file must be read. The value of this analysis comes from completeness. Sampling or skipping undermines the findings.
  • Real data only: Never fabricate quotes, percentages, or patterns. If the data doesn't show a clear pattern, say so honestly rather than inventing one.
  • Let the data lead: The taxonomy, patterns, and instructions should emerge from what's actually in the files. Different users will have completely different denial patterns. A user building mobile apps will have different feedback than one building APIs. Don't assume what the patterns will be.
  • Agent parallelization: For large datasets, maximize parallel agents to reduce wall-clock time. The bottleneck is the largest batch — split it.
  • Structured extraction format: Ask extraction agents to return structured text with consistent delimiters so the reduce agent can parse reliably.
  • The report is the artifact: The HTML dashboard is what the user keeps. It should be beautiful, honest, and useful. Every section should feel like it was written about them specifically, because it was.
  • 数据源优先级： Plannotator是首选路径。Claude Code日志分析是没有Plannotator归档的用户的次要路径。
  • 研究完整性： 必须读取每一个文件。此分析的价值来自完整性。抽样或跳过会削弱发现的可信度。
  • 仅使用真实数据： 不得编造引用、百分比或模式。如果数据未显示清晰模式，如实说明而非编造。
  • 让数据主导： 分类法、模式和指令应从文件中的实际内容得出。不同用户会有完全不同的拒绝模式。构建移动应用的用户与构建API的用户会有不同的反馈。不要假设模式是什么。
  • Agent并行化： 对于大型数据集，最大化并行Agent以减少实际耗时。瓶颈是最大的批次——拆分它。
  • 结构化提取格式： 要求提取Agent返回具有一致分隔符的结构化文本，以便归约Agent能可靠解析。
  • 报告是核心产物： HTML仪表盘是用户保留的内容。它应该美观、真实、有用。每个部分都应该感觉是专门为他们编写的——因为确实如此。",