The Ratification Docket: Let the Grill Ask, Let One Page Answer

A developer has an invoice leak to close and three documents between them and the fix: a postmortem with nine recommendations, a tenant-isolation proposal with fourteen proposed items, and spike notes with five open questions. That’s twenty-eight items, plus three questions nobody has written down yet. The usual way through a pile like that is a walkthrough in the terminal, one item at a time, in the documents’ own codes, so answering “P-7” means opening the proposal to learn what P-7 is. The developer, the company and the incident below are fictional, built to show how my ratification-docket skill works when it’s paired with Matt Pocock’s grill-with-docs. The pairing isn’t fictional. I’ve run it for real twice, on a product I’m building.

What the ratification docket does

ratification-docket is a Claude Code skill for one moment: a piece of work has produced proposed decisions, and someone has to ratify, amend or reject them. It runs in five steps.

First, it collects every proposed item across the documents in scope, with what each proposes, who owns it, and what happens by default if nobody answers. It checks ground truth before anything else, so nobody rules on a stale premise: has the work already started, has a date already passed.

Second, it maps how the documents overlap. Where two cover the same ground, the later one supersedes the earlier (replaces what it decided), retimes it (same work, new date), reinforces it, or conflicts with it. That map is where a review goes wrong most quietly, so it gets attacked before you see it. Independent agents each take one group of claims and try to refute them, quoting the text that decides each one. A completeness critic then asks what the map missed. Anything the critic finds becomes an explicit sub-question on a card, never a footnote.

Third, it collapses items into decisions. Thirty-one items aren’t thirty-one decisions. One ruling often answers three items, and some items are information only.

Fourth, it builds a page of decision cards and publishes it as an artifact (a private web page Claude hosts for you) with its own store, so every click is saved and can be read back.

The cards are why the skill exists. My first attempts walked me through decisions in my documents’ own codes, and every line added a lookup instead of removing one, so each card now asks its question in plain words and carries the evidence it needs.

Fifth, it reads your answers back as data, writes a dated decision record, and updates every status line the rulings touch.

The page is not the record. The dated decision file is.

The fictional run end to end. You touch two boxes: the page and your answers.

Why it pairs with grill-with-docs

grill-with-docs is Matt Pocock’s skill for the start of a change, when the plan is fuzzy and the vocabulary isn’t settled. The grilling skill it delegates to puts its instruction bluntly: “Interview the user relentlessly until you reach a shared understanding.” It asks in numbered rounds, and every question carries a recommended answer, worded so that “yes” accepts it. Facts are looked up by sub-agents and never asked of you. It challenges terms that clash with the glossary and cross-checks your claims against the code. It writes settled vocabulary into GLOSSARY.md and hard decisions into ADRs (architecture decision records, files in docs/adr/, one per decision). An ADR is offered only when a decision is hard to reverse, surprising without context, and a real trade-off.

Its own page is honest about the gap. It calls “the most serious open complaint” the fact that no record links each resolved answer to a spec, a ticket and a test, and it says plainly that everything beyond the glossary and the ADRs lives in the conversation and nowhere else. The glossary holds vocabulary, and most sessions produce no ADR. And the questions arrive as rounds in chat, so you answer at the terminal’s pace.

The docket fills the part of that gap where answers live only in the conversation. The grill’s discipline decides what must be asked, and checks every premise against the code first. The docket is the channel you answer through and the record the answers land in.

I’ve paired them twice on a product I’m building, invoking both in the same turn each time. Both times the reader sub-agents surveyed the code and documents before a single question reached me. Then, instead of an interview in chat, the questions came back as a docket. The first run produced 22 decisions, and I took the recommendation on all of them. The second produced 17, and I departed from the recommendation four times; each departure is named in the record. Both runs put the cards through a refuter and a completeness critic before I saw them. In the second, the refuter found factual errors in the cards, and in both the survey surfaced premises in my own framing that the documents didn’t support.

A fictional session: the PDF that crossed customers

Tallowick is an invoicing app for small agencies, with a Postgres database, a Node API, and invoice PDFs rendered to object storage and served through a CDN (the cache in front of the storage). For 41 minutes on a Tuesday, a customer opening an invoice PDF could be served a cached PDF belonging to another customer. The CDN’s cache key was the PDF’s path, and paths were numbered per invoice, not per customer. Two customers were affected, and 7 PDFs crossed the line.

Three documents sit on the developer’s desk:

• The postmortem, with 9 recommendations (R-1 to R-9).
• A tenant-isolation proposal from an earlier session, with 14 proposed items (P-1 to P-14). P-1 says Postgres row-level security (RLS) should enforce the boundary, keyed on account_id.
• Spike notes on RLS overhead, with 5 open questions (Q-1 to Q-5) and the measurements.

The developer invokes both skills in the same turn:

> /grill-with-docs /ratification-docket Grill me on the tenant-isolation proposal, the PDF postmortem and the RLS
  spike. Check every claim against the code. Ask me through a docket, not the terminal.

Claude narrates what it does before any page exists (invented output, like the rest of this session):

● Loaded grill-with-docs (grilling, domain-modeling) and ratification-docket.
● Three readers surveying the code, the postmortem, the proposal and the spike notes.
● Survey back. One premise does not hold:
  The proposal keys RLS on account_id. In the code, accounts are billing accounts,
  and one organization can own several: 212 organizations do. RLS on account_id
  would hide part of an organization's own invoices from its own users.
  Not settling this in chat. It becomes card A0; recommendation: the organization.
● Two questions no document asks: who may bypass the boundary for support,
  and whether the old PDF paths stay guessable.
● Items: 9 recommendations + 14 proposed + 5 open questions + 3 from the survey = 31.
● Supersession map: P-7 retimes R-4. P-3 conflicts with R-2. R-8 reinforces P-12.
● Refuters and a completeness critic checked the map; corrections folded in.
● Collapsed 31 items into 12 decisions in three parts. Cannot be skipped: B1, B2.
● Docket published. Answer there and tell me when you're done.

The premise catch is the reason the grill belongs in the same turn. The proposal said “account” and meant “customer.” The code says an account is a billing account, and an organization, the agency that is the actual customer, can own several of them. Ship the proposal as written and the database would hide part of an organization’s own invoices from its own staff. Nobody asked that question in any document, because everyone believed they already agreed on the word. The grill didn’t argue the point with the developer in chat. It turned it into the docket’s first card, with a recommendation.

Reading the docket

The fictional docket’s header: six terms defined once, and a rail that follows you down the page.

The header defines six terms once, up front: organization, customer boundary, RLS, signed URL, CDN and p95. Any other term gets defined inside the card that needs it. The side rail counts decisions made and lists the two cards you cannot skip.

Card A0, the grill’s catch: a plain question, the evidence, and the default if you skip it.

Every card has the same anatomy, in the same order. The title is a plain question: where is the customer boundary, the billing account or the organization? Two or three sentences of context carry the evidence, here the fact that 212 organizations own more than one billing account. Each option says what it gets you and what it costs, and one carries a “recommended” tag. A line reads “If you skip this” and says, in plain words, what happens by default. At the bottom, a collapsed “where this comes from” line holds the item codes, P-1, P-2 and the survey finding. That line is for the read-back, not for you. You never need a code to answer.

Card B1, pinned because the postmortem and the proposal give opposite answers.

B1 is pinned because two documents contradict each other. The postmortem says keep caching PDFs and add the organization id to the cache key. The proposal says stop caching PDFs and serve each through a signed URL, a link to one file that expires after a few minutes. There’s no honest default when your own documents disagree, so the card can’t be skipped. Its context frames the trade: the key fix closes this bug, and signed URLs close the whole class. Its cost evidence is concrete. PDFs are 3 percent of CDN traffic, and an uncached PDF came back from storage at a p95 of 210 ms (95 of 100 requests were faster). A sub-question asks the signed URL’s lifetime as three chips: 10 minutes, 1 hour, 24 hours.

Card B2: no recommendation, and a default that would break a promise.

B2 asks how to tell the two affected customers, and it offers no recommendation. That’s a relationship call, and the card says so. It’s pinned for the other reason the skill allows: the default isn’t a legitimate choice. The postmortem promised notice within 7 days, and today is day 5. Skipping the card lets that promise lapse. Under the options sits a one-line why box, where you can say why you chose what you chose.

Ruling

The developer works through eleven of the twelve cards in about twenty minutes without opening a document. They take the recommendation on nine. On A3, support access, they choose an impersonation token (support signs in as the customer, with RLS still on) instead of the recommended database role that bypasses RLS. On C2 they decline to pause feature work. Both departures get a why line. B2 they leave open: the two affected customers deal with Tallowick’s founder, not with them, so the call is the founder’s.

They share the page with the founder from its Share menu, so the founder can use it too, and pin a comment to card B2: “Yours. Pick one; the why line is for you.”

Sharing the page: the one thing a terminal cannot do

This is the part of the docket I value most. A Claude Code session is one person’s. Nobody else can open its questions, comment on them, or answer the one that is really theirs. You can paste the transcript to them, but a pasted transcript doesn’t save what they click.

A docket is a page, and that changes it. The skill publishes it private, so only I can open the link. I share it from the page’s Share menu, in my browser; Claude can’t share it from the session. Someone I let use the page saves answers to the same store the read-back reads, so their picks and why lines land exactly where mine do. Someone who can only view it sees the cards and whatever is saved, and can’t change anything. Everyone with the page open sees the same answers, live.

The page’s Share menu: private until I invite someone, and it happens here in the browser, never from the session.

In the fictional session, the founder opens the page on their phone and picks (c), both: a personal email today and a formal report within the week. In the why line they write, “I’d rather they hear it from me before they read it from us.” Then they reply in the B2 thread. On the developer’s screen the pick appears, and the rail turns to twelve of twelve.

It’s one ballot, not a vote. The page holds one set of answers, so when two people answer the same card, the last saved pick stands. To hand a card to someone, do what the developer did: leave it open, share the page, and tell them which card. The why line is where they say why in their own words, and the record still names one decider.

Comments work for anyone the page is shared with. Each one is pinned to a place on the page and opens a thread. Claude doesn’t see a thread until I send it from the page, with “Send to Claude” on a reply or by mentioning @claude in it. Then the session reads the thread along with the answers, and can reply into it. The developer sends the B2 thread.

Card B2’s thread: the handover, and the reply with Send to Claude ticked so the read-back can quote it.

Twelve of twelve. B2 counts as the founder’s own call: there was no recommendation to take.

The read-back

Then the developer types one word, and Claude reads the page’s store back as data:

> answered
● Reading the page's saved answers: 12 of 12.
● 9 on the recommendation. B2 had none; chosen on the page: (c), email today, report
  within the week. why: "I'd rather they hear it from me before they read it from us."
● Read the B2 comment thread you sent; it is quoted in the decision record.
● Departures, named in the record:
  A3  impersonation token that keeps RLS on, not the bypass role
      why: "I'd rather support never holds a key that ignores the boundary."
  C2  no pause on feature work
      why: "Two people; the leak fix is one person's week."
● Wrote docs/decisions/2026-10-14-tenant-isolation.md
● GLOSSARY.md: Organization, Billing account, Customer boundary
● Wrote docs/adr/0007-customer-boundary-is-the-organization.md
● Proposal status lines: P-1, P-2 Accepted as amended (org_id). P-3 Accepted.
  P-11 Rejected (A3). P-13, P-14 Deferred.
● Postmortem: R-1 done today (purge). R-2 superseded by the signed-URL ruling.
  R-4 scheduled. R-6 answered.
● Nothing has been built. The record exists, so the leak fix can start.

Because both skills were loaded, the apply step follows the grill’s conventions as well as the docket’s. The three terms the grill settled go into the glossary. The boundary ruling gets an ADR because it passes all three of the grill’s tests: hard to reverse, surprising without context, a real trade-off. Everything else goes into the dated decision record, which holds each ruling with its why. Where the developer gave no reason, the why is the reasoning of the recommendation they adopted. B2’s why is the founder’s own line, taken from the page. The two departures are named, because those are the lines a later reader needs most.

How to get the best out of it

Invoke both in the same turn. The grill decides what must be asked and checks it against the code. The docket asks it on one page instead of in rounds at the terminal. The read-back writes every answer into a file, so no answer lives only in the conversation.

Let the survey run before any question reaches you. The most valuable card is often the one no document asked. A0 came from a premise the code contradicted, and no amount of careful reading of the proposal would have found it, because the proposal was where the wrong premise lived.

Point it at every document that proposes something, not just one. Contradictions surface in the supersession map, and you only get a map when there’s more than one document to map. B1 exists because the postmortem and the proposal were read together. Read separately, each looks settled.

Rule from the page, not the chat. Answering on the page keeps every decision in view at once, with its default. Where you depart from a recommendation, write the why line. The record names departures either way, but a departure with a reason is one a later reader can trust.

Share the card that isn’t yours. Leave it open, share the page with the person who owns the call, and say which card in a comment. The record then holds that person’s own why, not your guess at it.

Read back before you build. The page collects; it doesn’t record. Until the dated decision file exists and the status lines are updated, nothing has been decided as far as the repo knows. In both of my real runs, nothing was built until that file existed.

Installing ratification-docket

The ratification-docket skill is open source in claude-skills. One command installs it:

npx skills add seevali/claude-skills --skill ratification-docket

Or, in Claude Code, add the repository as a plugin marketplace and install it from there:

/plugin marketplace add seevali/claude-skills
/plugin install ratification-docket@claude-skills

To run the pairing, name both skills in the same turn. grill-with-docs runs only when you type it.

Neither skill makes the decisions. The grill makes sure the right questions get asked, and asked against the code instead of your memory of it. The docket makes sure you can answer them all in one sitting, on a page you can hand to whoever owns the call, and that your answers outlive the conversation.

---

The views expressed here are my own. The Tallowick session is fictional, built to show the skills; the two paired runs it draws on are from a product I’m building.