plan-auditlisted

# Plan Audit ## What this skill is — and isn't | Skill | Question it answers | Output | |---|---|---| | `vd:plan` | "Given the chosen approach, what are the steps?" | Phased plan files | | `vd:plan --deep` Phase 6 (red-team) | "What does THIS author's plan assume that isn't true?" | Three hostile questions, same context | | **`vd:plan-audit`** | **"Independently — does this plan hold up against the real codebase and the stated goal?"** | **Severity-tagged audit report (clean-context subagent)** | | `vd:research` | "What do external sources say about X?" | Comparison report with citations | The `--deep` red-team round (in `vd:plan`) lives inside the same conversation that wrote the plan — it shares the author's blind spots. **Plan-audit escapes that** by spawning a subagent with **only** the plan files + audit checklist as input. No conversation history, no author bias. It's a **second pair of eyes**, not a redesign tool. Findings are advisory — the author still owns the plan. ## Hard rules 1. **Never edit source code.** This skill only edits plan files (and only with `--fix`, only HIGH/CRITICAL findings, with per-finding confirmation by default — or single up-front confirmation when `--apply-all` is set). Never touches the actual codebase. 2. **Always use a clean-context subagent.** Inline reasoning shares the same blind spots as the author. The point of audit is independence — `Agent` tool, fresh context, plan files as the only input. 3. **Findings are advisory, not bl