| 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
- 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.
- Edge cases. Which ones matter? Which are deliberately ignored?
"None" is a claim — make it explicitly, don't leave it unexamined.
- Failures. What fails at runtime — network, partial state, a concurrent
shift, a missing config? Handled, retried (how often, how long), or
explicitly accepted?
- 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?
- 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.
- 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).
- 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.
- 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.
- 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.
