Plan Validate

<!-- PROMPT-ENHANCE:STEP-TASK-ANCHOR:START -->

[BLOCKING] Execute skill steps in declared order. NEVER skip, reorder, or merge steps without explicit user approval. [BLOCKING] Before each step or sub-skill call, update task tracking: set in_progress when step starts, set completed when step ends. [BLOCKING] Every completed/​skipped step MUST include brief evidence or explicit skip reason. [BLOCKING] If Task tools are unavailable, create and maintain an equivalent step-by-step plan tracker with the same status transitions.

<!-- PROMPT-ENHANCE:STEP-TASK-ANCHOR:END -->

Quick Summary

Goal: Force every assumption-laden plan decision and every preservation-critical behavior through explicit user confirmation BEFORE implementation — by interviewing the user with critical questions that validate assumptions and surface issues — so no unstated assumption silently reaches code.

Workflow:

1. Detect Plan Type — Classify plan (bugfix/​feature/​migration/​refactor) to weight question categories
2. Read Plan — Parse plan.md + phase files for decisions, assumptions, risks
3. Extract Topics — Scan architecture, assumptions, tradeoffs, risks, scope keywords
4. Generate Questions — Formulate concrete questions with 2-4 options each
5. Interview User — Present questions using configured count range
6. Document Answers — Add Validation Summary section to plan.md

Key Rules:

• MUST ATTENTION use AskUserQuestion — NEVER auto-decide on behalf of user
• NEVER ask about non-decision points — only genuine choices affecting implementation
• Bugfix plans ALWAYS trigger Preservation question (keywords: fix, bug, regression, broken, defect)
• NEVER modify phase files — only document what needs updating

First Principle — Easy to Change

The success metric of every coding decision is future change cost. DRY, SRP, abstraction, design patterns, naming, layering, tests — every technique exists to serve one goal: making the next change cheaper.

Evaluating code, refactor, test, abstraction, ask: does this make next change cheaper or more expensive?

• Reject "best practices" raising change cost (premature abstraction, speculative generality, leaky indirection, ceremony without payoff).
• Name real enemies in findings: coupling, hidden state, duplicated knowledge, unclear intent, irreversible decisions exposed too early.
• Simpler design easy to change beats sophisticated design that isn't.

Apply this lens before invoking any specific rule, pattern, or checklist below — if a downstream rule raises change cost, this principle wins.

---

Phase 0: Detect Plan Type

Classify plan type BEFORE generating questions — drives question category weighting:

Bugfix detection is BLOCKING — NEVER skip Preservation question when fix/​bug/​regression/​broken/​defect keywords present.

Plan Resolution

1. $ARGUMENTS provided → use that path
2. Check ## Plan Context section → use active plan path
3. No plan found → ask user to specify path or run /​plan first

Configuration (from injected context)

Check ## Plan Context section:

• mode — auto/​prompt/​off behavior
• questions — range like 3-8 (min-max)

Use as hard constraints.

Workflow

Step 1: Read Plan Files

Read plan directory:

• plan.md — overview + phases list
• phase-*.md — all phase files
• Flag: decision points, assumptions, risks, tradeoffs

Step 2: Extract Question Topics

Step 3: Generate Questions

Format rules:

• 2-4 concrete options per question
• Mark recommended with "(Recommended)" suffix
• "Other" option automatic — do NOT add
• Surface implicit decisions

Examples:

Category: Architecture
Question: "How should validation results be persisted?"
Options:
1. Save to plan.md frontmatter (Recommended) — updates existing plan
2. Create validation-answers.md — separate answers file
3. Don't persist — ephemeral validation only

Category: Assumptions
Question: "Plan assumes API rate limiting not needed. Correct?"
Options:
1. Yes, not needed for MVP
2. No, add basic rate limiting now (Recommended)
3. Defer to Phase 2

Category: Preservation (MANDATORY when title/​frontmatter: fix, bug, regression, broken, defect)
Question: "List 2-3 inputs where CURRENT code is correct. Will fix change behavior on any?"
Options (multi-select):
1. "Current code correct on: {input A}. Fix preserves behavior." (Recommended)
2. "Current code correct on: {input B}. Fix CHANGES behavior because: {justification}"
3. "Current code has NO preserved-correctness inputs — every input was broken" (rare; requires confirmation)
4. "Unsure — need to investigate" (STOP: run /​plan preservation analysis)

Follow-up rules:

• Option 2 selected → plan.md Preservation Inventory MUST cite Preservation TC asserting new behavior is intended
• Option 4 selected → return BLOCKED status, recommend /​plan before proceeding
• Option 3 selected → AskUserQuestion follow-up: "Confirm: current code has NO preserved invariant? [Yes, every input broken / No, missed some — re-investigate]"

Step 4: Interview User

Use AskUserQuestion — NEVER skip or auto-answer.

Rules:

• Use question count from ## Plan Context → Validation: mode=X, questions=MIN-MAX
• Group related questions (max 4 per tool call)
• Focus: assumptions, risks, tradeoffs, architecture
• MANDATORY IMPORTANT MUST ATTENTION: if plan introduces new tech/​packages, ask: "Plan uses {lib}. Were alternatives evaluated? Confirm choice or research more?"

Step 5: Document Answers

Add ## Validation Summary to plan.md:

## Validation Summary

**Validated:** {date}
**Questions asked:** {count}

### Confirmed Decisions

- {decision 1}: {user choice}
- {decision 2}: {user choice}

### Action Items

- [ ] {changes needed based on answers}

NEVER modify phase files — only document what needs updating.

Output

After validation:

• Questions asked count
• Key decisions confirmed
• Items flagged for plan revision
• Recommendation: proceed to implementation OR revise plan first

Next Steps

MANDATORY IMPORTANT MUST ATTENTION — NO EXCEPTIONS after completing, use AskUserQuestion to present:

• "/​cook (Recommended)" — Begin implementation with validated plan
• "/​refine" — If plan needs PBI refinement first
• "Skip, continue manually" — User decides

---

[BLOCKING] MUST ATTENTION use AskUserQuestion to interview user. Completing without asking ≥1 question = violation.

[IMPORTANT] Use TaskCreate to break ALL work into small tasks BEFORE starting — including tasks for each file read. For simple tasks, AI MUST ATTENTION ask user whether to skip.

External Memory: Complex/​lengthy work → write findings + results to plans/​reports/ — prevents context loss.

Evidence Gate: MANDATORY IMPORTANT MUST ATTENTION — every claim requires file:line proof or traced evidence with confidence % (>80% act, <80% verify first).

<!-- SYNC:nested-task-creation -->

Nested Task Expansion Contract — For workflow-step invocation, the [Workflow] ... row is only a parent container; the child skill still creates visible phase tasks.

1. Call TaskList first. If a matching active parent workflow row exists, set nested=true and record parentTaskId; otherwise run standalone.
2. Create one task per declared phase before phase work. When nested, prefix subjects [N.M] $skill-name — phase.
3. When nested, link the parent with TaskUpdate(parentTaskId, addBlockedBy: [childIds]).
4. Orchestrators must pre-expand a child skill's phase list and link the workflow row before invoking that child skill or sub-agent.
5. Mark exactly one child in_progress before work and completed immediately after evidence is written.
6. Complete the parent only after all child tasks are completed or explicitly cancelled with reason.

Blocked until: TaskList done, child phases created, parent linked when nested, first child marked in_progress.

<!-- /​SYNC:nested-task-creation --> <!-- SYNC:task-tracking-external-report -->

Task Tracking & External Report Persistence — Bootstrap this before execution; then run project-reference doc prefetch before target/​source work.

1. Create a small task breakdown before target file reads, grep, edits, or analysis. On context loss, inspect the current task list first.
2. Mark one task in_progress before work and completed immediately after evidence; never batch transitions.
3. For plan/​review work, create plans/​reports/​{skill}-{YYMMDD}-{HHmm}-{slug}.md before first finding.
4. Append findings after each file/​section/​decision and synthesize from the report file at the end.
5. Final output cites Full report: plans/​reports/​{filename}.

Blocked until: task breakdown exists, report path declared for plan/​review work, first finding persisted before the next finding.

<!-- /​SYNC:task-tracking-external-report --> <!-- SYNC:critical-thinking-mindset -->

Critical Thinking Mindset — Apply critical thinking, sequential thinking. Every claim needs traced proof, confidence >80% to act. Anti-hallucination: Never present guess as fact — cite sources for every claim, admit uncertainty freely, self-check output for errors, cross-reference independently, stay skeptical of own confidence — certainty without evidence root of all hallucination.

<!-- /​SYNC:critical-thinking-mindset --> <!-- SYNC:sequential-thinking-protocol -->

Sequential Thinking Protocol — Structured multi-step reasoning for complex/​ambiguous work. Use when planning, reviewing, debugging, or refining ideas where one-shot reasoning is unsafe.

Trigger when: complex problem decomposition · adaptive plans needing revision · analysis with course correction · unclear/​emerging scope · multi-step solutions · hypothesis-driven debugging · cross-cutting trade-off evaluation.

Format (explicit mode — visible thought trail):

1. Thought N/​M: [aspect] — one aspect per thought, state assumptions/​uncertainty
2. Thought N/​M [REVISION of Thought K]: ... — when prior reasoning invalidated; state Original / Why revised / Impact
3. Thought N/​M [BRANCH A from Thought K]: ... — explore alternative; converge with decision rationale
4. Thought N/​M [HYPOTHESIS]: ... then [VERIFICATION]: ... — test before acting
5. Thought N/​N [FINAL] — only when verified, all critical aspects addressed, confidence >80%

Mandatory closers: Confidence % stated · Assumptions listed · Open questions surfaced · Next action concrete.

Stop conditions: confidence <80% on any critical decision → escalate via AskUserQuestion · ≥3 revisions on same thought → re-frame the problem · branch count >3 → split into sub-task.

Implicit mode: apply methodology internally without visible markers when adding markers would clutter the response (routine work where reasoning aids accuracy).

Deep-dive: see /​sequential-thinking skill (.claude/​skills/​sequential-thinking/​SKILL.md) for worked examples (API design, debugging, architecture), advanced techniques (spiral refinement, hypothesis testing, convergence), and meta-strategies (uncertainty handling, revision cascades).

<!-- /​SYNC:sequential-thinking-protocol --> <!-- SYNC:project-reference-docs-guide -->

Project Reference Docs Gate — Run after task-tracking bootstrap and before target/​source file reads, grep, edits, or analysis. Project docs override generic framework assumptions.

1. Identify scope: file types, domain area, and operation.
2. Required docs by trigger: always docs/​project-reference/​lessons.md; doc lookup docs-index-reference.md; review code-review-rules.md; backend/​CQRS/​API backend-patterns-reference.md; domain/​entity domain-entities-reference.md; frontend/​UI frontend-patterns-reference.md; styles/​design scss-styling-guide.md + design-system/​design-system-canonical.md; integration tests integration-test-reference.md; E2E e2e-test-reference.md; feature docs/​specs feature-spec-reference.md + spec-system-reference.md + spec-principles.md; behavior/​public-contract/​spec-test-code sync workflow-spec-test-code-cycle-reference.md; derived spec index/​ERD/​reimplementation guides spec-system-reference.md + source Feature Specs under docs/​specs/; architecture/​new area project-structure-reference.md.
3. Read every required doc. If docs/​project-config.json, the docs index, lessons.md, CLAUDE.md, AGENTS.md, or any task-required reference doc is missing or stale, auto-run /​project-init or the narrow lower-level route (/​project-config, /​docs-init, /​scan-all, /​scan --target=<key>, /​claude-md-init) before ordinary project-specific work. If Codex mirrors or AGENTS.md are missing/​stale, ask the user to run /​sync-codex; do not auto-run it.
4. Before target work, state: Reference docs read: ... | Not applicable: ....

Ready when: scope evaluated, required docs checked/​read or setup route completed, lessons.md confirmed, citation emitted.

<!-- /​SYNC:project-reference-docs-guide --> <!-- SYNC:understand-code-first -->

Understand Code First — HARD-GATE: Do NOT write, plan, or fix until you READ existing code.

1. Search 3+ similar patterns (grep/glob) — cite file:line evidence
2. Read existing files in target area — understand structure, base classes, conventions
3. Run python .claude/​scripts/​code_graph trace <file> --direction both --json when .code-graph/​graph.db exists
4. Map dependencies via connections or callers_of — know what depends on your target
5. Write investigation to .ai/​workspace/​analysis/ for non-trivial tasks (3+ files)
6. Re-read analysis file before implementing — never work from memory alone. — why: long context drifts from the file; the file is ground truth
7. NEVER invent new patterns when existing ones work — match exactly or document deviation. — why: divergent patterns fragment the codebase and slow every future reader

BLOCKED until: - [ ] Read target files - [ ] Grep 3+ patterns - [ ] Graph trace (if graph.db exists) - [ ] Assumptions verified with evidence

<!-- /​SYNC:understand-code-first --> <!-- SYNC:plan-quality -->

Plan Quality — Every plan phase MUST ATTENTION include test specifications.

1. Add ## Test Specifications section with TC-{FEATURE}-{NNN} IDs to every phase file
2. Map every functional requirement to ≥1 TC (or explicit TBD with rationale)
3. TC IDs follow TC-{FEATURE}-{NNN} format — reference by ID, never embed full content
4. Before any new workflow step: call TaskList and re-read the phase file
5. On context compaction: call TaskList FIRST — never create duplicate tasks
6. Verify TC satisfaction per phase before marking complete (evidence must be file:line, not TBD)

Mode: TDD-first → reference existing TCs with Evidence: TBD. Implement-first → use TBD → /​spec [mode=tests] fills after.

<!-- /​SYNC:plan-quality --> <!-- SYNC:cross-service-check -->

Cross-Service Check — Microservices/​event-driven: MANDATORY before concluding investigation, plan, spec, or feature doc. Missing downstream consumer = silent regression.

Boundary	Grep terms
Event producers	Publish, Dispatch, Send, emit, EventBus, outbox, IntegrationEvent
Event consumers	Consumer, EventHandler, Subscribe, @EventListener, inbox
Sagas/​orchestration	Saga, ProcessManager, Choreography, Workflow, Orchestrator
Sync service calls	HTTP/​gRPC calls to/​from other services
Shared contracts	OpenAPI spec, proto, shared DTO — flag breaking changes
Data ownership	Other service reads/​writes same table/​collection → Shared-DB anti-pattern

Per touchpoint: owner service · message name · consumers · risk (NONE / ADDITIVE / BREAKING).

BLOCKED until: Producers scanned · Consumers scanned · Sagas checked · Contracts reviewed · Breaking-change risk flagged

<!-- /​SYNC:cross-service-check --> <!-- SYNC:ai-mistake-prevention -->

AI Mistake Prevention — Failure modes to avoid on every task:

Check downstream references before deleting. Deleting components causes documentation and code staleness cascades. Map all referencing files before removal. Verify AI-generated content against actual code. AI hallucinates APIs, class names, and method signatures. Always grep to confirm existence before documenting or referencing. Trace full dependency chain after edits. Changing a definition misses downstream variables and consumers derived from it. Always trace the full chain. Trace ALL code paths when verifying correctness. Confirming code exists is not confirming it executes. Always trace early exits, error branches, and conditional skips — not just happy path. When debugging, ask "whose responsibility?" before fixing. Trace whether bug is in caller (wrong data) or callee (wrong handling). Fix at responsible layer — never patch symptom site. Assume existing values are intentional — ask WHY before changing. Before changing any constant, limit, flag, or pattern: read comments, check git blame, examine surrounding code. Verify ALL affected outputs, not just the first. Changes touching multiple stacks require verifying EVERY output. One green check is not all green checks. Holistic-first debugging — resist nearest-attention trap. When investigating any failure, list EVERY precondition first (config, env vars, DB names, endpoints, DI registrations, data preconditions), then verify each against evidence before forming any code-layer hypothesis. Surgical changes — apply the diff test. Bug fix: every changed line must trace directly to the bug. Don't restyle or improve adjacent code. Enhancement task: implement improvements AND announce them explicitly. Surface ambiguity before coding — don't pick silently. If request has multiple interpretations, present each with effort estimate and ask. Never assume all-records, file-based, or more complex path. Keep domain concepts out of generic/​shared/​infrastructure layers. A reusable layer (shared library, framework, infra module) must reference NO consumer-specific domain concept — tenant/​customer/​product IDs, business entities, feature rules. The leak compiles and runs, so it passes review silently while coupling the "reusable" layer to one consumer. Push domain fields/​logic down into the consumer via subclass or composition.

<!-- /​SYNC:ai-mistake-prevention --> <!-- SYNC:understand-code-first:reminder -->

IMPORTANT MUST ATTENTION search 3+ existing patterns and read code BEFORE any modification. Run graph trace when graph.db exists.

<!-- /​SYNC:understand-code-first:reminder --> <!-- SYNC:plan-quality:reminder -->

IMPORTANT MUST ATTENTION include ## Test Specifications with TC IDs per phase. Call TaskList before creating new tasks.

<!-- /​SYNC:plan-quality:reminder --> <!-- SYNC:cross-service-check:reminder -->

IMPORTANT MUST ATTENTION microservices/​event-driven: scan producers, consumers, sagas, contracts in task scope. Per touchpoint: owner · message · consumers · risk (NONE/​ADDITIVE/​BREAKING). Missing consumer = silent regression.

<!-- /​SYNC:cross-service-check:reminder --> <!-- SYNC:critical-thinking-mindset:reminder -->

MUST ATTENTION apply critical thinking — every claim needs traced proof, confidence >80% to act. Anti-hallucination: never present guess as fact.

<!-- /​SYNC:critical-thinking-mindset:reminder --> <!-- SYNC:sequential-thinking-protocol:reminder -->

MUST ATTENTION apply sequential-thinking — multi-step Thought N/​M, REVISION/​BRANCH/​HYPOTHESIS markers, confidence % closer; see /​sequential-thinking skill.

<!-- /​SYNC:sequential-thinking-protocol:reminder --> <!-- SYNC:ai-mistake-prevention:reminder -->

MUST ATTENTION apply AI mistake prevention — holistic-first debugging, fix at responsible layer, surface ambiguity before coding, re-read files after compaction.

<!-- /​SYNC:ai-mistake-prevention:reminder --> <!-- SYNC:task-tracking-external-report:reminder -->

• MANDATORY Bootstrap task tracking before target work; transition one task at a time.
• MANDATORY Persist plan/​review findings to plans/​reports/ incrementally and synthesize from disk.

<!-- /​SYNC:task-tracking-external-report:reminder --> <!-- SYNC:project-reference-docs-guide:reminder -->

• MANDATORY After task-tracking bootstrap and before target/​source work, read required project-reference docs and cite Reference docs read: ....
• MANDATORY Always include lessons.md; project conventions override generic defaults.
• MANDATORY If project config, root instruction files, or any required reference doc is missing, stop and run or ask the user to run /​project-init.

<!-- /​SYNC:project-reference-docs-guide:reminder --> <!-- SYNC:nested-task-creation:reminder -->

• MANDATORY Parent workflow rows do not replace child phase tracking; expand phases and link the parent when nested.
• MANDATORY Orchestrators pre-expand child skill phases before invocation; use [N.M] $skill-name — phase prefixes and one-in_progress discipline.

<!-- /​SYNC:nested-task-creation:reminder --> <!-- PROMPT-ENHANCE:STEP-TASK-CLOSING:START -->

Prompt-Enhance Closing Anchors

IMPORTANT MUST ATTENTION follow declared step order for this skill; NEVER skip, reorder, or merge steps without explicit user approval IMPORTANT MUST ATTENTION for every step/​sub-skill call: set in_progress before execution, set completed after execution IMPORTANT MUST ATTENTION every skipped step MUST include explicit reason; every completed step MUST include concise evidence IMPORTANT MUST ATTENTION if Task tools unavailable, maintain an equivalent step-by-step plan tracker with synchronized statuses

<!-- PROMPT-ENHANCE:STEP-TASK-CLOSING:END -->

Closing Reminders

IMPORTANT MUST ATTENTION Goal: Force every assumption-laden plan decision and every preservation-critical behavior through explicit user confirmation BEFORE implementation — so no unstated assumption silently reaches code.

• MANDATORY IMPORTANT MUST ATTENTION break work into small todo tasks using TaskCreate BEFORE starting
• MANDATORY IMPORTANT MUST ATTENTION validate decisions with user via AskUserQuestion — NEVER auto-decide
• MANDATORY IMPORTANT MUST ATTENTION detect plan type (Phase 0) BEFORE generating questions — bugfix ALWAYS triggers Preservation
• MANDATORY IMPORTANT MUST ATTENTION add final review task to verify work quality
• MANDATORY IMPORTANT MUST ATTENTION NEVER modify phase files — document what needs updating only
• MANDATORY IMPORTANT MUST ATTENTION for bugfix plans, trigger Preservation question (keywords: fix, bug, regression, broken, defect)

Anti-Rationalization:

[TASK-PLANNING] Before acting, analyze task scope and systematically break it into small todo tasks and sub-tasks using TaskCreate.

---

Closing reminder — Easy to Change is the success metric. Every finding, test, refactor, and abstraction must answer one question: does this make the next change cheaper or more expensive? If it doesn't reduce future change cost, reject it. Coupling, hidden state, duplicated knowledge, and unclear intent are the real enemies — call them out by name.