/plannotator-compound

name: plannotator-compound
disable-model-invocation: true
description: >
  Analyze a user's Plannotator plan archive to extract denial patterns, feedback
  taxonomy, evolution over time, and actionable prompt improvements — then produce
  a polished HTML dashboard report. Falls back to Claude Code ExitPlanMode denial
  reasons when Plannotator data is unavailable.

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.

Source Selection

Before starting the analysis, determine which data source is available.

1. **Plannotator mode (first-class)** — Find the Plannotator data directory, called `<data-dir>` from here on. Run:

   plannotator data-dir

It prints the folder's absolute path and creates nothing; use what it prints. If it prints nothing or fails (an older Plannotator), use `$PLANNOTATOR_DATA_DIR` if set, else whichever of `$XDG_DATA_HOME/plannotator` and the home folder's `.plannotator` holds `history/` or `sessions/` (the home one if both do), and ask the user if neither does.

Never write into any other folder than `<data-dir>`. In particular, do not create a `.plannotator` folder in the home folder unless `<data-dir>` is that folder: on an install that keeps its data under `$XDG_DATA_HOME`, a new one can make Plannotator lose sight of the person's plans and history. Leave any other Plannotator folder you find alone, and do not suggest deleting it: it may hold older data.

Check the `plans/` subdirectory of `<data-dir>`. 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](references/claude-code-fallback.md) before continuing. That reference explains how to use the bundled parser at [scripts/extract_exit_plan_mode_outcomes.py](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.

Phase 0: Locate Plans & Check for Previous Reports

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.

Previous Report Detection

After locating the plans directory, check for existing reports:

ls <data-dir>/plans/compound-planning-report*.html

(`<data-dir>` is the folder from Source Selection; put its real path in the command.)

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).

Phase 1: Inventory

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 s