whiplash git:20261003.26b28abA

Immutable. This exact content never changes and is served at /api/v1/blob/b6d689814df969fc.

---
name: whiplash
description: Critically review a work product, fix supported material issues, and repeat verification and review until no material issue remains. Use only when explicitly invoked.
disable-model-invocation: true
---

# Hope Whiplash

Use only when the person invokes `$hope:whiplash`, `/hope:whiplash`, or the
host's equivalent skill command or picker. Continue follow-ups within that
invoked task without requiring another invocation. Ordinary requests and calls
from another skill do not activate this skill; continue authorized work through
the ordinary workflow. Reading a shared reference does not invoke its skill.

Critically examine the work against its intended purpose and real use, fix
supported material issues, and review the result again. Be strict about the
work and respectful toward people.

Read `../write/references/writing-standard.md` for user-facing language.

## Scope

Use the named target or the active work established in the conversation. Keep
its agreed purpose, scope, and constraints through every round. Invocation
authorizes reversible local edits to that target and directly related support
material. Carry forward existing authority for other actions; invocation alone
does not authorize commits, pushes, publication, or changes to external systems.

Honor a review-only request by reporting checked findings without edits. Ask
only when missing information or a consequential decision changes the result,
or an action needs authority not already given. Continue independent authorized
work while an answer is pending.

## Review, fix, and repeat

Use the conversation, relevant sources, and the person's constraints to choose
the review's focus, depth, and format. Do not fill a fixed checklist, require a
finding count, or impose a report template.

Test important claims in concrete situations and consider simpler ways to meet
the same goal. Challenge your own findings with evidence that could overturn
them, and make only changes warranted by their practical impact.
Distinguish demonstrated defects from uncertain explanations or missing
evidence; do not manufacture criticism. Reject unsupported findings with a
reason, and reopen settled findings or decisions only when new evidence changes
their basis.

Fix supported issues in coherent batches and verify the affected behavior with
appropriate checks and required project verification. After each batch, review
the latest result for unresolved issues, regressions, and material problems
missed earlier. Reconsider the original target as well as the changed parts;
do not narrow the scope or weaken the criteria merely to obtain an empty review.

Use independent reviewers when their perspective is worth the time or the
person requests them. Preserve independence with fresh contexts grounded in
the target, constraints, and evidence, separate from the author's conclusions.
Judge findings by evidence, not reviewer agreement. Disclose any limit on
requested independence.

## Finish

Continue without another request until the latest review finds no unresolved
material issue in scope and required verification is complete. A review of an
earlier version does not clear later edits. One clear review of the latest
result is enough; do not repeat unchanged reviews or invent work to fill a round.

If fixes cycle, the same unresolved cause persists without concrete progress,
or a required decision, evidence, access, or user-specified budget prevents
completion, report the remaining issue and what would unblock it. Complete
independent work first. Do not describe an interrupted or blocked run as clean.

Report consequential fixes, verification, and remaining limits concisely. For
review-only work, lead with the most consequential supported findings, their
evidence, and useful next actions, then finish once they have been checked. If
no material issue is found, say so without implying the work is defect-free.