validate

# Validate ## Establish intent before judgment Resolve advice versus acceptance from the caller's request and already settled context first. Explicitly selecting Validate, asking to establish that original acceptance is met, or requesting an acceptance verdict or independent proof of completion selects this route, even when phrased as "review this". Suggestions or a second look belong to [Review](../review/SKILL.md). Generic checking or readiness questions do not by themselves select acceptance. Supplying acceptance criteria identifies what to inspect, not which kind of judgment the caller wants. If the purpose remains ambiguous, ask whether the caller wants advice or an acceptance judgment and wait for the answer. Do not issue a verdict, acceptance conclusion or readiness approval while intent is unresolved; missing intent is not a `NOT_PROVEN` verdict. After acceptance intent is established, freshly judge the exact candidate against accepted intent, return `PASS`, `FAIL`, or `NOT_PROVEN`, and stop. The author cannot provide binding PASS. Advisory findings cannot substitute for this fresh exact-subject judgment. Read RPI [boundaries](../rpi/references/boundaries.md) before judgment; load helper flags and storage details from [mechanics](references/mechanics.md) when needed. If the required boundary resource is missing or unreadable, name the path and report that judgment is blocked; do not issue a verdict from remembered or inferred boundary rules. Unrelated authorized i...