• Do NOT modify plan files, phase files, or codebase files — this skill only writes the audit report
• Read ALL phase files, not just a sample — the value of this audit is completeness
• Ground findings in actual codebase files, not just plan documents
• When you claim a phase targets a file that doesn't exist, verify with Glob first
• Distinguish between intentional design choices and actual discrepancies

TaskList

1. Read existing tasks with

   TaskGet

   for each task ID
2. Find the first task with status

   pending

   or

   in_progress

3. Resume from that task — do NOT recreate the task list

Task 1: Read the master plan
Task 2: Read all phase files and extract metadata
Task 3: Build dependency graph
Task 4: Assess data flow consistency
Task 5: Evaluate phase ordering
Task 6: Identify stale artifacts
Task 7: Cross-check "Done" phases against codebase
Task 8: Assess risk for pending phases
Task 9: Write audit report
Task 10: Return summary

in_progress

completed

reviews/planning/

{plan-folder}/reviews/planning/flow-audit.md

• plans/250202-voice-assistant/reviews/planning/flow-audit.md

• plans/250202-api-refactor/reviews/planning/flow-audit.md

reviews/planning/

Note: Per-phase template/codebase reviews go in the same folder — see

/review-plan

. Code/implementation reviews go in

reviews/code/

— see

/code-review

.

{plan-folder}/plan.md

1. Phase table — all phases with titles, status, and any noted issues
2. ADRs / Decision Log — decisions that constrain phase design
3. Critical Issues section — known problems already documented
4. Architectural North Star — patterns all phases must follow

• Declared dependencies (from frontmatter

  dependencies:

  field)
• Implicit dependencies (phase references data/files/services created by another phase but doesn't declare it)
• What downstream phases depend on it

status: deprecated

1. Source consistency — Do all phases agree on where data comes from?
2. Schema consistency — Do phases that share data structures use the same types/interfaces?
3. Pattern consistency — Is there one architectural pattern or do different phases use contradictory approaches?
   • Example: Some phases have components query the database directly while others expect data passed via context/props
4. Table/entity naming — Do all phases reference the same table names consistently?
5. File path consistency — Do phases reference files that actually exist at those paths?

1. Infrastructure before consumers — Are foundational phases (schemas, services, APIs) ordered before phases that use them?
2. Producers before consumers — Does the phase that creates data run before phases that read it?
3. Refactoring order — For refactoring plans, is the new system built before the old system is deprecated/removed?
4. Test timing — Are testing phases positioned to test code that already exists?
5. Cleanup last — Are deprecation, migration, and drop phases at the end?

• A consumer phase runs before its data producer
• A centralized service is created AFTER the things that should use it
• Tests are written before the code they test exists
• Cleanup runs before all references are migrated

1. Pick 2-3 "Done" phases that make testable claims (e.g., "created table X", "updated file Y", "added field Z to interface")
2. Use Glob/Grep to verify the claim holds in the codebase
3. Check if

   {plan-folder}/reviews/code/phase-{NN}.md

   exists for each "Done" phase — a passing code review verdict is stronger evidence than file existence alone
4. Flag any "Done" phases whose deliverables can't be found

1. [Critical] {Description} — Fix before continuing implementation
2. [High] {Description} — Fix before implementing affected phases
3. [Medium] {Description} — Fix for plan hygiene
4. [Low] {Description} — Nice to have

undefined

1. Report location — file path
2. Overall assessment — one-line verdict
3. Critical/High issues count — how many need attention before implementation continues
4. Top 3 findings — the most impactful discoveries
5. Recommendation — whether to proceed, fix first, or restructure

1. Run

   TaskList

   to see all tasks and their status
2. Find the

   in_progress

   task — that's where you were
3. Run

   TaskGet {id}

   on that task to read full details
4. Continue from that task — don't restart from the beginning

TaskList → find in_progress or first pending → TaskGet → continue work → TaskUpdate (completed) → next task

• Source files are read-only — do NOT modify plan files, phase files, or codebase files. The only file you write is the audit report at

  {plan-folder}/reviews/planning/flow-audit.md

• All phases — read every phase file, not just a sample
• Codebase grounding — verify at least 2-3 "Done" phase claims against actual code. Use file paths from the phases themselves (implementation steps list target files)
• No template checking — that's

  /review-plan

  's job. Focus on flow, not format
• Severity calibration — only mark issues as Critical if they would cause implementation failure. Use High for likely problems, Medium for hygiene issues, Low for suggestions
• Pipeline awareness —

  /implement

  checks the plan review verdict before building. Your audit report influences whether implementation proceeds or blocks