plannotator-compound

What it does

Analyzes a user's Plannotator plan archive to identify denial patterns, classify feedback into a taxonomy, track evolution over time, and generate actionable prompt improvements, culminating in a polished HTML dashboard report. If Plannotator data is missing, it falls back to Claude Code ExitPlanMode denial reasons.

How it works

The skill defines a multi-phase workflow:

• Source Selection: chooses between Plannotator data (plans/ with *-denied.md) or Claude Code fallback mode by inspecting data locations and existence of files. If neither data source is available, it prompts the user for directories.
• Phase 0: Locate Plans & Check for Previous Reports: in Plannotator mode, verify the plans directory has *-denied.md files; in Claude Code fallback mode, run the bundled parser per the fallback reference. Detect previous reports and propose incremental vs full analysis choices when a prior report exists.
• Phase 1: Inventory: count all file types ( --approved.md, --denied.md ), determine date range from filenames, compute total days spanned, and calculate revision rate (denied / (approved + denied)). If incremental, also report new files after cutoffDate and new date range. Compute average lines per approved plan via wc -l across all -*-approved.md files. Extract dates from filenames to establish ranges.
• Phase 2: Map — Parallel Extraction: read every in-scope denied file, extracting per-file data: plan topic, denial reason, what was asked to change, feedback type, notable phrases, annotations, and date. Each file entry is formatted with a header [filename] and structured fields. Extraction is performed in batches with parallel Haiku agents, writing results to /tmp/compound-planning/extraction-{batch-name}.md. The instruction emphasizes reading all in-scope files without skipping and using model: "haiku".
• Phase 3: Reduce — Pattern Analysis: use Sonnet agents to aggregate extractions into a comprehensive analysis. If extraction files are 20 or fewer, a single Sonnet agent processes all; if more, use a two-stage reduce producing partial reduces then a final reduce. The reduction prompt requires generating: Denial Reason Taxonomy, Top Feedback Patterns, Recurring Phrases, What the Reviewer Values, What Agents Consistently Get Wrong, Structural Requests, Evolution Over Time, and Actionable Prompt Instructions, plus a percentage of denials addressed by these instructions.
• Phase 4: Generate the HTML Dashboard: create a self-contained HTML file saved to the user’s plans directory with a versioned filename (compound-planning-report.html for the first report, then compound-planning-report-v2.html, etc.), reflecting whether the run is incremental or full. The content is a single, self-contained dashboard that presents the analyses and findings.

When to use it

Use when you have a Plannotator plan archive available under a user data directory (Plannotator data) or when fallback Claude Code data is available. Use incremental mode if there is a previous report detected; otherwise run a full analysis.

What it can touch

• Data sources: Plannotator data directory (PLANNOTATOR_DATA_DIR or ~/.plannotator) with plans/ and *-denied.md files; fallback Claude Code data under ~/.claude/projects/.
• Output and work directories: /tmp/compound-planning/ for extraction outputs; the final HTML dashboard saved to the user’s plans directory. File paths and tool names are referenced exactly as in the workflow (e.g., *-denied.md, compound-planning-report.html, /tmp/compound-planning/, haiku, sonnet).

Caveats

• The workflow requires access to the specified data paths and reads all denied files in scope; it does not skip files in Phase 2. It relies on the existence of *-denied.md for in-scope data in Plannotator mode and falls back to a bundled Claude Code parser if necessary. The instruction notes that the analysis is multi-phase and results are written to discrete output files per batch and a final HTML dashboard. The process may produce different outputs depending on whether it runs in incremental or full mode, and on the availability of prior reports. The summary highlights the need to read every file in scope and to avoid skipping content during extraction and reduction.