pan-wizard 3.35.0 → 3.37.0

package/commands/pan/audit-deployment.md

@@ -1,386 +0,0 @@
----
-name: pan:audit-deployment
-group: System
-description: Audit a PAN Wizard deployment — verify installation integrity, project health, and draft enhancement specs
-argument-hint: <target-directory> [--enhancements] [--repair]
-allowed-tools:
-  - Read
-  - Bash
-  - Write
-  - Glob
-  - Grep
-  - AskUserQuestion
----
-<objective>
-Audit a directory where PAN Wizard was installed and a project was run. Verify installation integrity, validate project artifacts, assess workflow execution quality, and optionally produce a featureAI-format enhancement spec that superplan.md can consume for development planning.
-</objective>
-
-<execution_context>
-This command operates on a TARGET directory (not the PAN source repo). The target must be provided as the first argument.
-</execution_context>
-
-<process>
-
-<step name="parse_args">
-**Parse arguments:**
-
-Extract target directory path from the first argument. It is REQUIRED.
-
-```
-TARGET_DIR = first positional argument
-ENHANCEMENTS_FLAG = "--enhancements" present?
-REPAIR_FLAG = "--repair" present?
-```
-
-If no target directory is provided, ask the user:
-> Which directory should I audit? Provide the full path to the folder where PAN Wizard was installed and a project was run.
-
-Validate the directory exists before proceeding.
-</step>
-
-<investigate_before_judging>
-Never report a file as missing, broken, or misconfigured without reading it first.
-For every audit check: read the actual file, verify its contents, then state the finding with evidence.
-Do not speculate about file contents based on filenames alone.
-</investigate_before_judging>
-
-<step name="installation_audit">
-**Phase 1 — Installation Integrity Audit**
-
-Check the PAN Wizard installation artifacts in the target directory. Determine which runtime was used (Claude, Gemini, OpenCode, Codex, Copilot) by checking for config directories:
-
-```
-Claude:   <target>/.claude/
-Gemini:   <target>/.gemini/
-OpenCode: <target>/.opencode/
-Codex:    <target>/.codex/
-Copilot:  <target>/.github/ (local install) or ~/.copilot/ (global)
-```
-
-For the detected runtime config directory (CONFIG_DIR), audit ALL of the following:
-
-**1.1 Core Files (CRITICAL)**
-- [ ] `CONFIG_DIR/pan-wizard-core/VERSION` exists — read and record version
-- [ ] `CONFIG_DIR/pan-wizard-core/CHANGELOG.md` exists
-- [ ] `CONFIG_DIR/pan-file-manifest.json` exists — parse and validate JSON
-- [ ] `CONFIG_DIR/package.json` exists — should contain `{"type":"commonjs"}`
-
-**1.2 Core Modules**
-- [ ] `CONFIG_DIR/pan-wizard-core/bin/pan-tools.cjs` exists (CLI dispatcher)
-- [ ] `CONFIG_DIR/pan-wizard-core/bin/lib/` directory exists
-- Every `bin/lib/*.cjs` file listed in `pan-file-manifest.json` exists on disk (the manifest is the authoritative expected set — never hardcode a module count)
-
-**1.3 Workflows, Templates, References**
-- [ ] `CONFIG_DIR/pan-wizard-core/workflows/` — non-empty, every manifest-listed workflow present
-- [ ] `CONFIG_DIR/pan-wizard-core/templates/` — non-empty, every manifest-listed template present
-- [ ] `CONFIG_DIR/pan-wizard-core/references/` — non-empty, every manifest-listed reference present
-
-**1.4 Commands**
-- For Claude/Gemini: `CONFIG_DIR/commands/pan/` — every manifest-listed command file present (a `--unified-skills` install has none: check `./.agents/skills/pan-*/SKILL.md`, and for Claude also `CONFIG_DIR/skills/pan-*/SKILL.md`)
-- For OpenCode: `CONFIG_DIR/commands/` — every manifest-listed `pan-*.md` present (flat, one file per command)
-- For Copilot: `CONFIG_DIR/skills/pan-*/SKILL.md` — every manifest-listed skill directory present
-- For Codex: the SHARED skills tree, not `CONFIG_DIR` — `./.agents/skills/pan-*/SKILL.md` for a local
-  install, `~/.agents/skills/pan-*/SKILL.md` for a global one. Codex has no `skills/` of its own; if you
-  look under `.codex/` you will find no commands and wrongly report a broken install.
-
-**1.5 Agents**
-- [ ] `CONFIG_DIR/agents/` — every manifest-listed agent file present
-- Verify key agents exist: pan-planner, pan-executor, pan-verifier, pan-debugger
-
-**1.6 Hooks** (not OpenCode: its install copies no hooks — check `CONFIG_DIR/plugins/pan-wizard.js` instead)
-- [ ] `CONFIG_DIR/hooks/pan-statusline.js` exists
-- [ ] `CONFIG_DIR/hooks/pan-check-update.js` exists
-- [ ] `CONFIG_DIR/hooks/pan-context-monitor.js` exists
-
-**1.7 Settings/Config**
-- [ ] Settings file exists (settings.json / opencode.json / config.json)
-- [ ] Hooks are registered — Claude `settings.json`: SessionStart, PostToolUse, SubagentStop, Stop, statusLine; Gemini `settings.json`: SessionStart, AfterAgent, PreCompress and AfterTool (the last two for state re-injection; no statusLine); Codex: `.codex/hooks.json`; Copilot: `.github/hooks/pan.json`
-- [ ] Hook commands point to existing files
-
-**1.8 Manifest Integrity**
-- Read `pan-file-manifest.json`
-- For each file in the manifest, verify it exists on disk
-- Flag any MISSING files (manifest says exists, disk says no)
-- Flag any MODIFIED files (hash mismatch) — these are user customizations, not errors
-- Flag any ORPHANED files (on disk but not in manifest)
-
-Record all findings with severity: CRITICAL (missing core), WARNING (missing optional), INFO (modifications).
-</step>
-
-<step name="project_audit">
-**Phase 2 — Project Artifacts Audit**
-
-Check `.planning/` directory in the target:
-
-**2.1 Core Planning Files**
-- [ ] `.planning/config.json` — exists, valid JSON, has expected keys (`model_profile`, `commit_docs`, `workflow`, `budget`)
-- [ ] `.planning/project.md` — exists, has "What This Is", "Core Value", "Requirements" sections
-- [ ] `.planning/state.md` — exists, has "Current Position", "Performance Metrics" sections
-- [ ] `.planning/roadmap.md` — exists, has phase table
-- [ ] `.planning/requirements.md` — exists if project used requirements tracking
-
-**2.2 Phase Directories**
-- Scan `.planning/phases/` for numbered phase directories
-- For each phase directory:
-  - [ ] At least one `*-plan.md` file exists (phase was planned)
-  - [ ] A matching `*-summary.md` file exists (phase was executed)
-  - [ ] A `*-verification.md` file exists (phase was verified)
-- Count: total phases, phases with plans, phases verified, phases with gaps
-
-**2.3 Research Artifacts** (if brownfield/research was enabled)
-- [ ] `.planning/research/` directory exists
-- Check for stack.md, features.md, architecture.md, pitfalls.md
-- [ ] `.planning/codebase/` directory exists (brownfield)
-
-**2.4 State Consistency**
-- Parse state.md "Current Position" — extract phase number
-- Count actual phase directories — do they match?
-- Check roadmap.md phase count vs actual directories
-- Check `.planning/phases/*/.continue-here*.md` (pause writes `.continue-here.md`): resuming does not delete it (only the transition workflow removes a completed phase's handoffs), so its presence alone does not mean the session was never resumed
-
-**2.5 Config Sanity**
-- Validate config.json values are within expected ranges
-- `model_profile`: "quality" | "balanced" | "budget"
-- `commit_docs`: boolean
-- `workflow.*` toggles (research, plan_check, verifier, ...): boolean — except `workflow.phase_reports`, an object (`enabled`, `open`, `theme`, `index`)
-- `budget`: `default_points` numeric, `enforce` boolean
-</step>
-
-<step name="workflow_quality_audit">
-**Phase 3 — Workflow Execution Quality**
-
-Assess how well the project workflow was followed:
-
-**3.1 Planning Quality**
-For each phase with plan files (`*-plan.md`, e.g. `01-01-plan.md`):
-- Does it have clear objectives?
-- Does it reference requirements?
-- Are plans sequential with dependencies noted?
-- Grade: Complete / Partial / Stub
-
-**3.2 Verification Coverage**
-- Count phases with verification.md vs total phases
-- Check if verifications have pass/fail outcomes
-- Flag phases that were executed but never verified
-
-**3.3 Commit History** (if git repo)
-- Check if `.planning/` is tracked in git (config.json commit_docs)
-- Look for atomic commit patterns (one commit per plan)
-- Check for PAN-style commit messages
-
-**3.4 Session Continuity**
-- Check for `.planning/phases/*/.continue-here*.md` files (a pause happened at some point; nothing removes them on resume)
-- Check state.md session logs for gaps
-- Look for evidence of context loss (repeated work, contradictory decisions)
-
-**3.5 Todo Management**
-- Check `.planning/todos/` directory
-- Count pending vs completed
-- Flag stale todos (captured but never addressed)
-</step>
-
-<step name="report">
-**Phase 4 — Generate Audit Report**
-
-Format findings as a structured report:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- PAN Deployment Audit
- Target: <target-directory>
- Date: <YYYY-MM-DD>
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-## Summary
-
-| Category               | Status   | Score |
-|------------------------|----------|-------|
-| Installation Integrity | ✓/⚠/✗   | N/N   |
-| Project Artifacts      | ✓/⚠/✗   | N/N   |
-| Workflow Quality        | ✓/⚠/✗   | N/N   |
-| Overall                | HEALTHY / DEGRADED / BROKEN | N% |
-
-Runtime: <detected runtime>
-PAN Version: <version from VERSION file>
-Phases: <completed>/<total>
-Verification Coverage: <N>%
-
-## Installation Integrity
-
-### Critical Issues
-- [I-C01] <description> — <fix>
-
-### Warnings
-- [I-W01] <description> — <suggestion>
-
-### Info
-- [I-I01] <description>
-
-### Modified Files (User Customizations)
-- <file> — hash mismatch (expected: abc..., actual: def...)
-
-## Project Artifacts
-
-### Critical Issues
-- [P-C01] <description> — <fix>
-
-### Warnings
-- [P-W01] <description> — <suggestion>
-
-### Phase Health
-| Phase | Planned | Plans | Verified | Status |
-|-------|---------|-------|----------|--------|
-| 01    | ✓       | 3     | ✓        | Complete |
-| 02    | ✓       | 5     | ✗        | Unverified |
-
-## Workflow Quality
-
-### Observations
-- Planning quality: <grade>
-- Verification coverage: <N>%
-- Commit discipline: <grade>
-- Session continuity: <grade>
-
-### Recommendations
-1. <actionable recommendation>
-2. <actionable recommendation>
-```
-
-If `--repair` flag was provided, attempt auto-fixes for repairable issues:
-- Regenerate missing settings.json with default hook config
-- Create missing .planning/config.json with defaults
-- Remove `.planning/phases/*/.continue-here*.md` files the user confirms are stale
-
-Report repairs performed.
-</step>
-
-<step name="enhancements">
-**Phase 5 — Enhancement Spec Generation** (only if `--enhancements` flag)
-
-Based on audit findings, generate a featureAI-format enhancement spec at `docs/specs/deployment_audit_findings_featureai.md` in the PAN SOURCE repository (NOT the target directory).
-
-The spec MUST follow this exact format to be consumable by superplan.md:
-
-```markdown
-# [Enhancement Title] — Feature Specification
-
-**Generated:** <YYYY-MM-DD>
-**Version:** 1.0
-**Status:** Proposed
-**Source:** Deployment audit of <target-directory>
-
----
-
-## Problem Statement
-
-[Describe the problems discovered during the audit. What is broken, missing, or suboptimal in PAN Wizard based on real-world deployment evidence?]
-
-## Demand Evidence
-
-| Evidence Type | Source | Finding |
-|---|---|---|
-| Deployment audit | <target-dir> | <specific finding> |
-| ... | ... | ... |
-
-## Success Criteria
-
-~~~
-SC-1: <measurable criterion>
-SC-2: <measurable criterion>
-~~~
-
-## Design
-
-[Proposed changes to PAN Wizard to address the findings]
-
-### Architecture
-
-[How the fix/enhancement integrates with existing PAN architecture]
-
-## Feature Ladder
-
-| Version | Scope | Value | Effort |
-|---|---|---|---|
-| **v0 (MVP)** | <scope> | <value> | <effort> |
-| **v1** | <scope> | <value> | <effort> |
-
-## Implementation Tasks
-
-| # | ID | Title | Files | Effort | Pts | Priority |
-|---|---|---|---|---|---|---|
-| 1 | A.1 | <task> | <files> | S/M/L | N | P1-P4 |
-
-### Dependency Graph
-
-~~~
-A.1 ──> A.2 ──> A.3
-~~~
-
-## Test Plan
-
-| Level | Count | What It Catches |
-|---|---|---|
-| Unit | N+ | <description> |
-| Integration | N+ | <description> |
-
-## Risk Register
-
-| Risk | Probability | Impact | Mitigation |
-|---|---|---|---|
-| <risk> | Low/Med/High | Low/Med/High | <mitigation> |
-
----
-
-*Generated by /pan:audit-deployment — <YYYY-MM-DD>*
-```
-
-Group findings into logical enhancement categories:
-1. **Installer gaps** — Missing files, broken hooks, manifest issues
-2. **Workflow gaps** — Missing verification, planning quality
-3. **Template gaps** — Templates that don't match real-world needs
-4. **Documentation gaps** — Unclear processes discovered during audit
-5. **Tooling gaps** — Features PAN should have but doesn't
-
-For each category with findings, generate a separate featureAI spec OR consolidate into one spec if findings are cohesive.
-
-Ask the user before writing specs:
-> The audit found N enhancement opportunities across M categories. Should I generate featureAI specs for superplan.md to plan development? [Yes/No]
-</step>
-
-<step name="final_summary">
-**Final Summary**
-
-Display a concise summary:
-
-```
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
- Audit Complete
-━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
-
-Score: N% (HEALTHY / DEGRADED / BROKEN)
-Critical: N | Warnings: N | Info: N
-
-Installation: <status>
-Project: <status>
-Workflow: <status>
-
-Enhancements drafted: N specs → docs/specs/
-```
-
-If enhancements were generated:
-> Enhancement specs written. Run superplan.md or /pan:milestone-new to plan development work.
-
-If repairs were performed:
-> N issues auto-repaired. Re-run /pan:audit-deployment to verify.
-</step>
-
-</process>
-
-<constraints>
-- NEVER modify the target directory's .planning/ content unless --repair is explicitly passed
-- NEVER modify the target directory's PAN installation files (read-only audit)
-- Enhancement specs are written to the PAN SOURCE repo docs/specs/, NOT the target directory
-- If the target directory IS the PAN source repo, refuse with: "Cannot audit the PAN source repository. Use a separate deployment directory."
-- All file reads are defensive — missing files are findings, not crashes
-- Do not expose file hashes, absolute paths, or credentials in the report
-</constraints>

package/commands/pan/dashboard.md

@@ -1,22 +0,0 @@
----
-name: pan:dashboard
-group: Observability
-description: Alias for /pan:hud — generate the single-page HTML dashboard of the bot army and project
-argument-hint: "[--out <file>] [--open] [--stdout]"
-allowed-tools:
-  - Read
-  - Bash
----
-
-<objective>
-`/pan:dashboard` is a discoverability alias for **`/pan:hud`** (ADR-0035). It generates the same single-page, self-contained HTML dashboard of the project and its bot army.
-
-Run it exactly like `/pan:hud`:
-
-```
-pan-tools hud [--out <file>] [--open] [--stdout]
-```
-
-See **`/pan:hud`** for the full panel list, flags, JSON result shape, and runtime compatibility. The two commands are interchangeable.
-</objective>
-

package/commands/pan/discord.md

@@ -1,19 +0,0 @@
----
-name: pan:discord
-group: Community
-description: Join the PAN Discord community
----
-
-<objective>
-Display the Discord invite link for the PAN community server.
-</objective>
-
-<output>
-# Join the PAN Discord
-
-Connect with other PAN users, get help, share what you're building, and stay updated.
-
-**Invite link:** https://discord.gg/pan-wizard
-
-Click the link or paste it into your browser to join.
-</output>

package/commands/pan/mcp-bridge.md

@@ -1,143 +0,0 @@
----
-name: pan:mcp-bridge
-group: External tools
-description: Discover available MCP tools and recommend which ones apply to a phase. Discovery-only; auto-invocation deferred.
-argument-hint: "list | recommend <phase> [--max N] [--min-score N] | cache [--servers <json>] [--runtime <name>]"
-allowed-tools:
-  - Read
-  - Bash
-  - Write
----
-
-<objective>
-Surface Model Context Protocol (MCP) tools visible to the host runtime and recommend which ones might apply to a specific phase plan.
-
-Reduced scope from Spec B v1's X-7: **discovery and recommendation only**. Auto-injection of MCP tools into planner context and auto-invocation from executor agents are deliberately deferred and still unscheduled (the v3.5 target passed without them). This kept v3.3 narrow and avoids coupling PAN to Claude Code's MCP schema stability.
-</objective>
-
-Each subcommand runs `node ~/.claude/pan-wizard-core/bin/pan-tools.cjs bridge <list|recommend|cache> [flags]`. The CLI verb is `bridge`, not `mcp-bridge`: `pan-tools mcp-bridge` is an unknown command.
-
-<subcommands>
-
-### `list`
-
-Show cached MCP tools with server grouping and schemas.
-
-```
-/pan:mcp-bridge list
-```
-
-**Output (JSON):**
-```json
-{
-  "cached_at": "2026-04-18T12:34:56Z",
-  "runtime": "claude",
-  "server_count": 3,
-  "tool_count": 12,
-  "tools": [
-    { "server": "linear", "name": "linear.updateTicket", "description": "...", "schema": {...} },
-    ...
-  ],
-  "source": "cache" | "empty"
-}
-```
-
-When `source: "empty"`, nothing has seeded the cache yet: no hook or host writes it, only `cache --servers` (or an external script). See the `cache` subcommand for manual seeding.
-
-### `recommend <phase>`
-
-Given a phase number, match cached MCP tools against the phase's plan text and return tools ranked by keyword relevance.
-
-```
-/pan:mcp-bridge recommend 7
-/pan:mcp-bridge recommend 12 --max 5 --min-score 2
-```
-
-**Flags:**
-- `--max N` — cap recommendations (default 10)
-- `--min-score N` — minimum keyword hit count (default 1)
-
-**Output (JSON):**
-```json
-{
-  "phase": "7",
-  "phase_name": "API refactor",
-  "runtime": "claude",
-  "total_candidates": 12,
-  "recommendations": [
-    {
-      "server": "linear",
-      "name": "linear.updateTicket",
-      "description": "Update a Linear issue",
-      "score": 3,
-      "hits": ["linear", "ticket", "update"]
-    }
-  ]
-}
-```
-
-Scoring is naive keyword frequency with word boundaries — not semantic embeddings. A tool's name and description are tokenized into keywords (≥3 chars); each match in the phase plan text scores 1 point.
-
-### `cache`
-
-Write or inspect the MCP tools cache at `.planning/bridge/available-tools.json`.
-
-```
-# Inspect current cache (prints the same JSON as `list`)
-/pan:mcp-bridge cache
-
-# Seed cache from scripted discovery (for testing or external pipeline)
-/pan:mcp-bridge cache --runtime claude --servers '[{"name":"linear","tools":[{"name":"linear.updateTicket","description":"Update ticket"}]}]'
-```
-
-Nothing else writes this file: no hook or installer step populates it, so `list` and `recommend` see only what this command (or an external script) has recorded.
-
-</subcommands>
-
-<workflow>
-
-**New to a project with MCP tools?** Run `/pan:mcp-bridge list` to see what's available. If empty, nothing has seeded the cache: record each server with its tools, `/pan:mcp-bridge cache --servers '[{"name":"<server>","tools":[{"name":"<tool>","description":"…"}]}]'`, taking the tool names and descriptions from the MCP tools your session has loaded. A server recorded without `tools` adds no tool to `list` (only `server_count` counts it, and `source` then reads `cache`) and nothing to `recommend`, and the host runtime's MCP config names only the servers and how to start them. Each runtime keeps that config somewhere different: Claude Code in `.mcp.json` at the project root (project scope) or `~/.claude.json` (user and local scopes), OpenCode in `opencode.json`, Copilot in `.github/mcp.json`, Codex in its own config, Gemini in its settings file.
-
-**Planning a phase that might touch external systems?** Run `/pan:mcp-bridge recommend <phase>` to get a ranked shortlist. Copy relevant tool names into the phase plan's "External tools" section so the executor knows to invoke them.
-
-**Pre-milestone review:** walk through each remaining phase with `/pan:mcp-bridge recommend` to catch "we should have automated this via Linear/Slack/etc." realizations before shipping.
-
-</workflow>
-
-<caveats>
-
-**Discovery is a cache, not a live probe.** Only `cache --servers` (or an external script) populates `.planning/bridge/available-tools.json`; no hook or host writes it. PAN does not query MCP servers directly — that would require runtime-specific HTTP or IPC integration this command deliberately avoids.
-
-**Keyword scoring is crude.** "Postgres" and "PostgreSQL" are different tokens; `postgresql` in a plan won't match a `postgres.query` tool unless the plan also says "postgres." Tune your plan language or expand tool descriptions to improve matches.
-
-**No runtime is special.** Each runtime PAN installs into reads MCP servers from its own config (see the workflow section above); the cache schema is generic, so whatever lists a runtime's servers can populate the same file.
-
-**No automatic invocation.** This command never calls MCP tools. It tells you what's available and what might apply. The actual invocation happens via the host runtime's normal tool-use flow (Claude Code's tool calls, etc.) when the executor agent decides to use a recommended tool.
-
-</caveats>
-
-<runtime_compatibility>
-
-| Runtime | list | recommend | cache |
-|---------|------|-----------|-------|
-| Claude Code | Full once seeded | Full once seeded | Full |
-| OpenCode | Full once seeded | Full once seeded | Full |
-| Gemini CLI | Full once seeded | Full once seeded | Full |
-| Codex CLI | Full once seeded | Full once seeded | Full |
-| Copilot CLI | Full once seeded | Full once seeded | Full |
-
-On every runtime, `list` reports zero tools (`source: "empty"`) and `recommend` an empty `recommendations` list with a `reason` until `cache --servers` (or an external script) populates the cache; no host or hook writes it.
-
-</runtime_compatibility>
-
-<future_scope>
-
-Explicitly deferred from v3.3 (documented in ADR-0024 / Spec B v2 notes):
-
-1. **Auto-inject recommended tools into planner context** — requires a stable MCP schema contract and a plan-template extension. Unscheduled.
-2. **Auto-invoke MCP tools from executor agent** — requires permission-gating and per-tool safety review. Unscheduled.
-3. **Cross-runtime tool discovery** — filling the cache automatically from each runtime's own MCP config and servers. No timeline; needs ecosystem signal.
-
-Until those land, this command is the minimum viable integration: you see what's there, you get suggestions, you decide manually.
-
-</future_scope>

package/commands/pan/milestone-cleanup.md

@@ -1,19 +0,0 @@
----
-name: pan:milestone-cleanup
-group: Milestone
-description: Archive accumulated phase directories from completed milestones
----
-<objective>
-Archive phase directories from completed milestones into `.planning/milestones/v{X.Y}-phases/`.
-
-Use when `.planning/phases/` has accumulated directories from past milestones.
-</objective>
-
-<execution_context>
-@~/.claude/pan-wizard-core/workflows/milestone-cleanup.md
-</execution_context>
-
-<process>
-Follow the cleanup workflow at @~/.claude/pan-wizard-core/workflows/milestone-cleanup.md.
-Identify completed milestones, show a dry-run summary, and archive on confirmation.
-</process>

package/commands/pan/milestone-gaps.md

@@ -1,35 +0,0 @@
----
-name: pan:milestone-gaps
-group: Milestone
-description: Create phases to close all gaps identified by milestone audit
-allowed-tools:
-  - Read
-  - Write
-  - Bash
-  - Glob
-  - Grep
-  - AskUserQuestion
----
-<objective>
-Create all phases necessary to close gaps identified by `/pan:milestone-audit`.
-
-Reads milestone-audit.md, groups gaps into logical phases, creates phase entries in roadmap.md, and offers to plan each phase.
-
-One command creates all fix phases — no manual `/pan:add-phase` per gap.
-</objective>
-
-<execution_context>
-@~/.claude/pan-wizard-core/workflows/milestone-gaps.md
-</execution_context>
-
-<context>
-**Audit results:**
-Glob: .planning/v*-milestone-audit.md (use most recent)
-
-Original intent and current planning state are loaded on demand inside the workflow.
-</context>
-
-<process>
-Execute the plan-milestone-gaps workflow from @~/.claude/pan-wizard-core/workflows/milestone-gaps.md end-to-end.
-Preserve all workflow gates (audit loading, prioritization, phase grouping, user confirmation, roadmap updates).
-</process>