owner-review

name	owner-review
description	The definition-of-done gate. Run before declaring any unit of work done or finished — before merging an auto-ship, handing back a draft PR, closing an issue, or listing an item as "shipped" in a shift report. Nine ownership questions plus a short close-out posted on the PR/issue. Any unanswerable question flips the item to a lesser bucket instead of shipping a hole.

Owner Review

The why is docs/ownership.md: done is a property of the problem, not the diff, and you are the owner — there is no PM, QA department, or downstream colleague who will think about what you haven't. This skill is the gate that makes a "done" claim honest.

It reviews ownership, not code correctness. The codex-pr loop reviews the diff; this runs beside it and asks whether the problem is over.

When to run

Before any act that asserts "done":

• merging an auto-ship (graveyard bucket 1) — after the codex loop passes, before gh pr merge
• handing back a prep draft PR (bucket 2) — the close-out goes in the PR body so the user reviews a finished thought, not a code dump
• closing an issue as completed
• listing an item under "Shipped" in a shift report or brief

Not for proposals, briefs, or shaped epics — nothing shipped, nothing to own yet. Not a substitute for the codex review loop.

The nine questions

1. Problem. State the problem this ends, in one sentence, without naming the solution. ("Migrate X to Y" is a solution; "it fails for customer X" is a problem.) If you can't, you have a solution in search of its problem — route back through shape-an-epic.
2. Edge cases. Which ones matter? Which are deliberately ignored? "None" is a claim — make it explicitly, don't leave it unexamined.
3. Failures. What fails at runtime — network, partial state, a concurrent shift, a missing config? Handled, retried (how often, how long), or explicitly accepted?
4. Data. Does data need migrating or cleaning? What invariant does the change assume about the shape of the data that you haven't confirmed against the real thing?
5. Verified by running it. You exercised the change yourself — CLI, browser, script, the actual query, a demo, screenshots. Green checks, tsc-clean, and codex-clean are properties of the artifact; this question asks about the problem. The only exemptions: verification would be destructive/unsafe, or there is genuinely no automation path — and either one must be stated in the close-out, never silently skipped.
6. Lands where it runs. Merged is not deployed. Is it live in the place it operates — deployed, feature flag on, the skill actually loadable, the doc actually linked from the index — and confirmed working there? For judgment-shaped work, the observation contract is instrumented in this same diff (see observation-mode).
7. Peripheral vision. Who else needs to know? A sister division → an interoffice memo. The user → a line in the brief. A convention changed → the canon doc updated in the same PR. Knowing that X changed how Z works can save hours of someone else's debugging.
8. Follow-ups. Anything worth checking later — logs in a week, a metric after real traffic — gets an observing-register entry with a dated, runnable signal query. A registered check, never a mental note.
9. The pride gate. Am I proud of this? Would I show it to John Carmack and say "here's what I built, under these constraints, with these tradeoffs"? If not, the answer is never "ship quietly" — it's fix it, or name the constraint that makes this the right call and let it stand scrutiny.

The close-out

A short comment (or PR-body section) titled Owner close-out, posted at the moment of the done-claim. Not a nine-line ritual recital — only the load-bearing answers, in tight prose or bullets:

• the problem this ends (one sentence)
• how it was verified by running it (or the stated exemption)
• where it's live and how that was confirmed
• what's under observation / registered as follow-up, if anything
• who was told, if anyone needed to be

A question with an uninteresting answer is omitted. A question with no answer means you are not done — see routing below. The close-out is what makes the ownership claim auditable later: a future shift reading the PR can see what was owned, not just what was merged.

The routing rule

An unanswerable question never ships as a silent hole — it flips the item to the bucket whose name is honest:

• can't verify by running it, can't confirm it lands → auto-ship becomes prep: draft PR, with the unanswered question named in "Things to push back on"
• can't state the problem → prep becomes proposal: shape-an-epic it
• follow-up wanted but the signal can't be instrumented → the observation-mode fallback: route to prep, or use the non-code signal carve-out

Failing the gate is not failure — it's triage working. Declaring done anyway is the failure: it implicitly assumes someone else will do the thing you haven't thought about, which is the one prohibited move.