executing-hard-tasks

Executing Hard Tasks

Overview

Core principle: a plan is a hypothesis; a checkpoint is its test. Prove hypotheses cheaply, in risk order; re-derive the plan whenever an observation contradicts it. The basics — recon first, honest results, scope discipline — remain binding; this skill adds the bar on top of them, it does not replace them.

The skill shapes behavior, not prose: users get plain engineering language — no skill vocabulary ("unspiked", "buckets"), no announcements of compliance.

Decomposing

Contract for every plan:

1. Done, as an observation the user would accept. "Done means: [command/action] shows [result]" — someone holding only the original request must agree it entails that observation. Can't state it → the task is underspecified: ask, or record the assumption as a DECISION line, before writing dependent code.
2. State the budget, then thread it. Put the budget (wall-clock or steps) in the plan header. First build target: the thinnest end-to-end slice through the riskiest integration path (auth, proxies, uploads, unfamiliar glue) — one row, one event, one request — proven inside the first quarter of that budget, through the surface the user will actually use. Layer the rest onto the proven thread. Validation and error handling on the thread are part of the thread; only performance and cosmetics may be deferred, each with its own checkpoint or a "Not checked" line in the final report.
3. Checkpoint every subtask, fixed at plan time. A checkpoint is a command whose output you will paste, or an externally observable result (HTTP response, rendered output, screenshot). Self-review of your own edits never qualifies. More than two subtasks without an executed checkpoint = an end-loaded plan, whatever its phases are called. Weakening or replacing a checkpoint after it fails is itself a red checkpoint — report it as a plan change.
4. Spike before you build on a recommendation. Prove an architecture's critical integration point with the cheapest end-to-end experiment before implementing it as the chosen path — whether or not anyone is asked to approve it. An unproven option may be described, but the description must name exactly what is unproven and the rework cost if it fails.
5. DECISION lines for load-bearing choices. A choice that changes what data exists or what users observe (skip vs update duplicates; suppress-at-write vs suppress-at-read) appears in the user-facing plan as "DECISION: X over Y because Z". If it destroys or transforms persisted data, it gates on the user like any irreversible action.