Plan Validation — 8-Dimension Quality Check

Validates a plan file against 8 dimensions to catch gaps before implementation begins. Does NOT replace Gate 1 (human approval). Supplements it with systematic checks.

For green-field harness sprints (generator↔evaluator loop), use mk:sprint-contract instead. mk:validate-plan operates on plans from mk:plan-creator (cook flow only).

When to Use

• After Gate 1 approval, before Phase 2 (Test)
• When /mk:cook detects a COMPLEX task (auto-suggested)
• When user wants to stress-test a plan before committing to implementation
• When user says "validate this plan", "check my plan", "is this plan complete"

8 Validation Dimensions

Workflow

1. Load plan file — Read from tasks/plans/YYMMDD-name/plan.md
2. Check each dimension — Evaluate against pass criteria
3. Produce validation report — Pass/fail per dimension with findings
4. Route result:

• All 8 PASS → proceed to Phase 2
• Any FAIL → return to planner with specific revision requests
• WARN (partially met) → user decides: proceed or revise

Output Format

## Plan Validation: [Plan Name]

| #   | Dimension               | Status         | Finding            |
| --- | ----------------------- | -------------- | ------------------ |
| 1   | Scope Clarity           | PASS/FAIL/WARN | [specific finding] |
| 2   | Acceptance Criteria     | PASS/FAIL/WARN | [specific finding] |
| 3   | Dependencies Resolved   | PASS/FAIL/WARN | [specific finding] |
| 4   | Risks Identified        | PASS/FAIL/WARN | [specific finding] |
| 5   | Architecture Documented | PASS/FAIL/WARN | [specific finding] |
| 6   | Test Strategy           | PASS/FAIL/WARN | [specific finding] |
| 7   | Security Considered     | PASS/FAIL/WARN | [specific finding] |
| 8   | Effort Estimated        | PASS/FAIL/WARN | [specific finding] |

**Result:** [N]/8 passed | [Action: proceed / revise dimensions X,Y]

Whole-Plan Consistency Sweep (final pre-emit step)

After scoring the 8 dimensions and BEFORE emitting the validation report, run a cross-file consistency check on the plan directory.

Why: Distributed plans (plan.md + N × phase-*.md) drift after edits. One phase gets renamed; another phase still references the old name. Each phase reads as self-consistent but the plan as a whole is contradictory.

Procedure:

1. Re-read plan.md and every phase-*.md in the plan dir
2. Build a delta of: renamed entities, scope changes, dropped features, decision changes
3. Grep every plan file for stale references to renamed/dropped items
4. Reconcile contradictions across files (not only the file that surfaced them)

Output: Append a sweep_failures block to the validation report. Sweep failures DO NOT auto-FAIL — they surface inconsistencies the human must reconcile before Phase 3.

sweep_failures:
  - phase-02.md:18  references `userController` (renamed to `authController` in plan.md:42)
  - phase-04.md:8   declares scope item that plan.md:62 marks out-of-scope

Skip conditions: plan has only plan.md (no phase files); plan dir not found.

Source: Adapted from external verification-role guidance for whole-plan consistency sweeps.

Integration with Cook Workflow

In /mk:cook, validation runs automatically for COMPLEX tasks:

Gate 1 (plan approved) → mk:validate-plan → Phase 2 (Test)

For STANDARD tasks, validation is optional (user-triggered). For TRIVIAL tasks, validation is skipped.

Gotchas

• Not the same as `validate-plan.py`: The script at mk:plan-creator/scripts/validate-plan.py validates plan file structure (required sections exist). This skill validates plan content quality (are acceptance criteria binary? are risks identified?). Both can run — they check different things.

Relationship to plan-creator v2.3.1

Note: plan-creator's step-06 now includes an enhanced validation interview with detection keywords and section mapping. mk:validate-plan focuses on 8-dimension structural validation, which is complementary — not a replacement.

What This Skill Does NOT Do

• Does NOT replace Gate 1 — human approval still required
• Does NOT modify plan files — read-only analysis
• Does NOT generate tests — that's Phase 2 (tester agent)
• Does NOT block Gate 1 — runs after Gate 1, before Phase 2