validate

name	validate
description	Confirm we have actually completed and validated what we planned to accomplish. TRIGGER whenever the user asks you to confirm a task is complete, if any implementation or validation was missed, etc.
argument-hint	[task number or description]
effort	high
model	opus

Context

• The task (or issue, problem, ticket, etc) the user wants to discuss is what they mentioned here: $ARGUMENTS
• If they didn't provide a reference, assume they mean the changes on the current branch relative to the original plan you made

Your task

Phase 1: Understand the Problem

1. If the user did not specify what they want to discuss and you can't deduce it, ask them for that information
2. If you are unclear what the user is asking you to validate, clarify until you're quite sure
3. Read ~/.claude/references/README.md and the reference files relevant to the change scope. Use these invariants as your evaluation criteria throughout.
4. Once you understand the discussion topic, use as many subagents as you need to explore the problem definition and all relevant code paths and documentation and the changes you made
5. Proactively answer every question and follow-up question that occurs to you by exploring the codebase and anything else that would help you

Phase 2: Assess the Solution for Gaps or Mistakes

1. After thoroughly understanding the problem and current solution, compare what you see to the ideal way to achieve the intended goal
2. Was the complete intention of the original task achieved? What evidence proves that?
3. Have all edge cases been handled? What evidence proves that?
4. Is the chosen approach as declarative and straightforward as it could be?
5. Have domain concepts and their evolutions been optimally modelled using custom types?
6. Do all branches have well-designed automated tests? Do the tests we have prove this change introduces no regressions vs what choices the codebase makes and what side effects it emits on the default branch down every relevant logical branch?
7. Can the expected behaviour of every branch be confirmed from the outside — by running the real system and observing its output — without relying on automated tests?
8. If my team says "prove this does not break anything", what can we show them?

Phase 3: Instrumentation Check

For user-facing or behavior-changing changes, verify that observability shipped with the feature:

• North-star metric — the one number expected to move; is it defined?
• Baseline — current value captured before the change?
• Expected direction & size — e.g. +5% conversion, –20% latency
• Time horizon — when will we check? (7 days? 30?)
• Guardrail metrics — what must not get worse (error rate, adjacent funnels)?
• How we'll read it — A/B, before/after, cohort, or qualitative signal defined?

If instrumentation was not shipped in the same change, flag it explicitly. "We'll add analytics later" is a gap — call it out and recommend adding it before or immediately after this ships.

Skip this phase if the change is purely internal (refactor, dev tooling, CI, etc.).