Overdrive means deliberately spending far more effort than the default because the task has earned it. A normal pass settles for fast and good-enough, and this mode exists for the deliverable that has to hold up under scrutiny. The expense in time and tokens is real, so the first move is confirming the task deserves it: overdrive on a throwaway script is the gold-plating the foundation doctrine warns against, a failure in itself.

What overdrive changes, when the mode is warranted versus wasteful, the cost calculus, the failure modes, and a worked normal-versus-overdrive contrast all live in the overdrive protocol. Read the protocol before engaging the mode.

Steps

Justify the spend. Name why this task clears the overdrive bar: high stakes, irreversibility, a security or financial blast radius, or flagship visibility. Record the rough cost in extra passes against that payoff. The step is done once two written sentences name the stake and confirm the payoff beats the cost. A failed payoff test instead selects the default pass.
Generate independent approaches. Produce two or three distinct solutions, each with its trade-offs stated; cosmetic variants of one idea count as one. Score the candidates against the stated stake. The step is done when the candidate count is at least two and a one-line rationale names the chosen approach over the rejected ones.
Verify every claim against real output. Run the code, the query, or the command, and read what came back before writing the claim. Capture the observed output beside each claim the deliverable makes. The step is done when no load-bearing claim rests on assumption and each one cites the output that confirms it.
Enumerate the edge cases. List the boundary, empty, large, malformed, and concurrent inputs the task implies, then handle or explicitly defer each listed case. The step is done when the enumerated list is exhausted and each listed case carries a resolution or a recorded reason to skip it.
Self-critique adversarially. Argue against the deliverable the way a hostile reviewer would: name its weakest assumption, its likeliest failure, and the spot a critic attacks first. Address each objection raised. The step is done when the strongest objection has a written answer or an accepted, documented limitation.
Cross-check with tools and tests. Run skill-gate --strict at the repo root, or the project's lint, type, and test gates, against the change. The step is done when the gates exit zero, with any remaining failure recorded as a known finding rather than left silent.
Decide done or stop. Confirm steps 1 through 6 each reported their completion criterion, and confirm the effort stayed aimed at the stake, with no drift into polish nobody asked for. The deliverable is done when every step is checked off and one sentence states that the rigor matched the stakes.