# Do The Work Before You Offer It

> A reviewer's comment reveals more work than the PR covers, and the courteous-looking reply is "I can extend it to those too if you prefer". That offer spends the one thing a reviewer has least of — a round-trip of attention — to authorise something you could already have finished and measured. Do the work, verify it, then report it; ask only when the answer changes what you build in a way you cannot cheaply undo. A finished patch with numbers is a smaller ask than a question. Use when a draft reply contains a conditional offer, a "whichever you prefer", or a request for permission to do something no one is blocking. Trigger terms: if you prefer, whichever you'd like, shall I, should I also, let me know if, worth fixing, I can extend, happy to, want me to.

- Skill: `serhiy-bzhezytskyy/do-the-work-before-you-offer-it` (Agent Skill)
- Install (CLI): `npx skillmds@latest add serhiy-bzhezytskyy/do-the-work-before-you-offer-it`
- Raw SKILL.md: https://api.skillmd.com/api/skills/serhiy-bzhezytskyy/do-the-work-before-you-offer-it/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: serhiy-bzhezytskyy (https://skillmd.com/u/serhiy-bzhezytskyy)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/serhiy-bzhezytskyy/do-the-work-before-you-offer-it

---


# Do the work before you offer it

## Purpose

A conditional offer feels like deference and reads like collaboration, so it survives every
pass of a draft. But it converts your machine time — which is abundant — into the
reviewer's attention, which in every house measured is the actual constraint on merging.
Worse, it arrives without the information that would let them answer well: "should I fix
the others?" is unanswerable until someone knows how many there are, whether one change
covers them, and whether the suite still passes. Doing the work produces that information
as a by-product, and then there is nothing left to ask.

The asymmetry is the whole point. A reviewer has judgement, context and merge rights; what
they lack is an hour of unattended compute. That is exactly what an offer withholds and a
finished patch supplies.

## When to use

- A draft reply contains "if you prefer", "whichever", "shall I", "want me to", "worth
  doing?", or any sentence whose answer is a permission.
- A review comment implies neighbouring work — more call sites, more tests, a second
  component — and you are deciding whether to include it.
- You are about to ask a maintainer to choose between two things you could try both of.
- You have a hypothesis about scope and are tempted to socialise it instead of measuring it.

## When NOT to use

**The genuine questions** — the cases where asking first is right, not avoidance:

- ⭐ **The answer changes what you build and is expensive to undo**: a public API shape, an
  on-disk format, a new configuration key, which of two incompatible designs to pursue.
- **The work commits you to someone else's scope** — a refactor across files they own, or a
  ticket that is not yours to take.
- **A house rule requires discussion first** (a KIP, "discuss in an issue before coding").
  Then asking *is* the work; see `discuss-in-issue-first`.
- **The unknown is theirs, not yours**: "did you intend this behaviour?" cannot be measured
  from outside.
- **The work is large and the direction genuinely uncertain.** Then ask with a measurement
  attached, so the question costs them one read rather than one investigation.

## The practice (checklist)

- [ ] **Grep the draft for permission-shaped sentences** before anything else:
      ```bash
      grep -inE "if you prefer|whichever|shall I|should I|let me know|worth (fixing|doing)|I can (extend|add|also)|want me to|happy to" DRAFT
      ```
- [ ] **For each hit, ask one question**: *could I answer this myself with machine time I
      already have?* If yes, it is a request for permission to work. Delete it and do the work.
- [ ] **Bound the work first, so "do it" stays cheap.** Enumerate the sites before touching
      any: a sweep, a grep, a count. If the enumeration comes back large enough to change the
      PR's shape, that is a real question — and now it comes with a number.
- [ ] **Look for the one change that covers many sites.** Neighbouring failures usually share a
      cause; a guard inside a shared helper beats N copies of a guard, and it is a smaller diff
      to review.
- [ ] **Verify each site individually AND the whole in order.** Per-site green proves you fixed
      what you claimed; the ordered full run proves you broke nothing. Report both counts.
- [ ] **Rewrite the reply as done-work**: the number, what changed, the verification. Keep only
      the questions that survived step 2 — and state those as constraints you hit, not as
      choices you are handing over.

## Rationalizations

| Shortcut | Why it fails |
|---|---|
| "Asking is polite — it respects their ownership." | It respects the *decision* and spends the *attention*. In houses where 92% of PRs wait more than a month, a round-trip is the expensive currency and the decision is the cheap one. |
| "They might not want the extra scope in this PR." | Then they say so and you drop a commit — cheap, and the measurement stays useful. That is strictly better than them answering a question with no data in it. |
| "It might be wasted work." | An hour of unattended machine time against a review round-trip that can take days. And the "wasted" work still produced the count, which is the reply's best content. |
| "The offer shows I noticed the wider problem." | The fix shows it better, and the number shows it best. Noticing is not a contribution. |
| "I don't know if it's the same cause everywhere." | That is measurable. Run it; if the causes differ, *that* is the finding to report. |
| "It's a design decision and design decisions belong to maintainers." | Only when the design is actually open. Applying an existing helper to eight more call sites is not a design decision, it is typing. |

## RECEIPT

`redis/redis#15636`, 2026-08-13. A core developer reviewed a one-test fix and observed that
*"many tests in this file won't work with `--only`"*, offering a fork: refactor all of them,
or fix the ones that bother us — then tagged a second maintainer for an opinion.

The drafted reply ended:

> *"@[reviewer] if the 8 above are worth fixing in this PR I can extend it to them, or keep
> this one narrow and do them separately — whichever you prefer."*

That sentence was cut with one line of feedback: **"we don't ask before we've done it
ourselves and confirmed it works."**

What doing it cost, in full:

- **one guard inside an existing helper** — `setup_slot_migration_with_delay` populates on
  the source and imports to the destination, so it structurally requires the range to be on
  the source. One line there covered **3 of the 8 failing tests and all 33 of its call
  sites**.
- **five one-line calls** in the tests that write to the source before reaching any helper.
- total diff `+47/-22`, test-only, no production code.

What verifying it cost, and what it proved:

| check | result |
|---|---|
| each of the 8 previously-failing tests, run alone | **8/8 pass** |
| the two tests the PR originally fixed, run alone | still pass |
| ordered full suite | **104 assertions, 0 failures, 349 s** — identical to the pristine baseline |

⇒ The offer would have spent a round-trip in a repo whose median outside PR waits over a
month, to authorise work that took one guard, five lines, and an unattended hour. And the
reply it was replaced by is *shorter*: a count, a three-bullet description of the change,
and one genuinely open constraint that measurement could not resolve —
`validateImportSlotRanges` requires a single owner per range, so a split range cannot be
moved in one call, and no test needs that today.

⚠️ The surviving question is the shape to keep: it is stated as a limit of the
implementation, with the reason, and it is not handed over as a choice.

## Lifecycle

- **Run the grep on every outward-facing draft** — PR body, review reply, issue comment,
  email. Permission-shaped sentences survive prose edits because they read as manners.
- **When a question survives, attach its measurement.** "Should X also do Y?" plus "here is
  what Y would touch and what it would cost" is one read instead of one investigation.
- ⚠️ **A conditional offer inside a *commit message* or a *PR body* is the same defect** — it
  asks a reader to reply to a document. Put the finding in the text and the choice nowhere.
- **Report what the extra work found even if it is dropped.** The count outlives the patch;
  on this receipt the sweep incidentally produced the deterministic reproduction of a second
  open issue.