Human Review Gate

Reviewing a draft in chat costs more the better the draft gets. You describe an edit in prose, wait for the agent to apply it, then re-read the whole piece to check it understood you. Three small changes become three round-trips and a full re-read. And there is no way to say "this claim needs a source" or "does this land?" without derailing the edit loop, because everything you type is treated as an instruction.

The Human Review Gate moves that work onto a page. The agent opens a review session, hands you a link, and blocks. You read the draft in the real post template and change what you want changed, in place. Every edit saves straight to the draft as you make it. When you have also said whatever needed saying, you press Done once.

What you get on the page

The draft renders in the live post template, with the real typography, spacing, and media. You are judging the thing itself, not a markdown approximation of it.

• Edit in place, saved as you go. Click any paragraph and it becomes its markdown source, right where it sits. Change it, click away, and it renders again. The change is written to the draft at that moment, not held back until you finish. Empty it out and the block is gone.
• Edit the headline. The title and subtitle are editable the same way. They are separate fields on the post rather than part of the body, so they travel as their own before and after values.
• Comment on the exact words. Select any span of text and leave a note attached to that span. It shows in the rail on the right, highlighted where it belongs. A comment does not have to be an instruction: "needs a source" and "does this land?" are useful things to say and they no longer cost you an edit cycle.
• Comment on things that are not text. The hero image and other non-text elements are individually selectable, so you can say what is wrong with the picture without describing which picture you mean.
• Delete without explaining. Mark an element for deletion and move on. The deletion travels as an explicit operation, so nothing depends on the agent inferring intent from a sentence.
• Resolve as you go. Comments can be resolved and unresolved, and they survive a reload. You can leave the tab, come back, and pick up where you were.

Your edits are live. What you are reading is the draft itself, so there is no version of it sitting somewhere waiting to be approved.

Edit by voice

On a post, you can also speak an edit instead of typing one. Tap the voice button in the bottom-right corner (or press Space on desktop) and talk, the way you would in the ChatGPT or Claude apps. It is a live conversation: Claude hears you as you speak, answers out loud straight away, and stops the moment you talk over it. Say what you want changed and it works out which text you mean from the whole draft. The change lands in place and it says in a few words what it changed. If it has a question or a suggestion, it says that instead, and its last line stays on screen beside the button. Tap the button again to end the conversation. It also hangs up on its own after 45 seconds of quiet, and after 15 minutes at most.

Live conversation runs on ElevenLabs, with Claude as the model, using the same ElevenLabs key as the rest of BlackOps. The key needs write access to ElevenLabs Agents (it sets up its agent on first use) as well as Text to Speech and Speech to Text. During a live conversation the draft is sent to ElevenLabs as part of the agent's instructions, the same way it goes to the model in the other modes. If you want to pin the agent rather than have it found by name, set ELEVENLABS_REVIEW_AGENT_ID to its id. The agent is now "BlackOps review editor v2", which can change the title and subtitle; a pinned id still pointing at the first agent can't, so point it at the new one or remove it. When live conversation is not available (the key lacks that access, or the browser can't make the connection), the button falls back to the turn-by-turn mode and says why once: it sends what you said when you pause, answers, then listens again.

• The title is the title. "The title" or "the headline" means the post's title field, never a heading in the body, and "the subtitle" means the subtitle. Claude does exactly what you asked: "make the title about BlackOps, not Claude" rewrites the title and leaves the rest of the post alone. It changes every mention only when you say to.
• Saying what to change. Just say it: quote the words ("change 'quietly' to 'fast'"), describe the part ("the intro is too long"), or name a paragraph by number. One request can change several paragraphs, like swapping a word everywhere. Click a paragraph first and "this" means that one. If what you said fits more than one place, you hear a short question instead of a guess. Adding, removing or reordering whole paragraphs is done on the page.
• Undo. "Undo that" reverts the last voice edit, everything it touched. The Undo voice edit button at the top does the same, during a live conversation too.
• Seeing a change land. When Claude changes a paragraph, the words it replaces are struck through and fade, then the new words come in with a short orange wash. Once the save goes through, a thin line draws down the paragraph's edge with a small Saved. If the save fails, the paragraph says Not saved until a later save works. Headings, lists and other non-prose blocks swap straight away and only get the mark. With reduced motion turned on in your system settings, nothing moves, but the wash and the mark still show.
• Your brand voice. Every edit made here, from a typed comment, a spoken edit or a live conversation, is written to your site's brand voice: its tone and style rules go to the model with the draft. Hard bans are enforced on the result, not just asked for, so an em dash the model writes anyway is turned into a comma or a full stop before it reaches your draft. That happens in the edit itself, for every kind of edit: the page runs each change Claude makes through the site's rules before it lands (even the text you watch stream in), and the save checks Claude's text against them again on the server. What you type yourself is saved exactly as you typed it, and Undo puts back exactly what was there.
• Where it works. Desktop and mobile Safari/Chrome. The button always says what it is doing: Tap to talk, Listening, Thinking, Editing or Speaking.

The Changes list

Above the comments, the Changes list shows every change made while the page is open, newest first: Claude's, by voice or from a comment, and your own. Each one says what it touched (title, subtitle, a paragraph), who made it and when, with the old words struck through and the new ones marked. Each has its own undo, so you can take back an older change and keep the ones after it. If a newer edit has changed the same text since, that change's undo waits and says so, because undoing it would throw the newer edit away. Undo the newer one first.

A change Claude made also has a flag. Flag it when the edit was wrong, with a note if you like. That marks it in the edit log below.

The edit log

Every edit Claude makes on the review page is recorded, so a bad one can be looked at afterwards. One record per typed comment or spoken edit, and one per live conversation with each turn added as it happens. Each keeps what you said, the draft as the model saw it and the exact prompt, the model's answer, any tool calls, what changed (old and new), what the brand voice's hard bans rewrote, and whether you undid or flagged it. Records are private to the site.

Read them back from an agent with get_review_edit_log (the latest edits, only flagged ones, one session's, or one edit in full) and mark one with flag_review_edit. The same data is at GET /api/v2/review-sessions/edit-log. The log needs the review_edit_log migration; until it runs, edits work as before and just aren't recorded.

Typed comments work the same way as spoken edits. A comment that asks for a change rewrites its paragraph as soon as you post it, with an Undo on the comment. A note that asks for no change, like a question or praise, stays open. Press Done when you have finished. It saves, proofreads the draft and sends you a summary that lists anything still open.

What the agent receives

Your edits come back as a positional diff, and the agent is told they are already applied. Only the blocks you actually touched appear in it. That distinction matters more than it sounds: a full-body replacement invites the agent to re-read everything and quietly restyle paragraphs you never looked at. An operation list says exactly what changed and leaves the rest provably alone.

The diff is a record rather than a task. Because your edits went straight into the draft, an agent that re-applied them would double-apply your change.

Comments are the part the agent acts on. Each comes back anchored to the passage it was written about. The agent reads what you changed, acts on your comments, honours the deletions, and re-runs the proofreader before anything is published.

Comments that survive edits

An anchor is stored as the quoted text plus a window of the words around it, not as a character position. Character positions are the obvious approach and the wrong one: edit a paragraph near the top of a post and every position below it shifts, so every comment underneath now points confidently at the wrong words. That is the worst way for a review tool to fail, because it fails silently.

Instead, each comment is re-located when the page loads. If the text is still there it re-attaches, even if it has moved because you inserted three paragraphs above it. If the wording drifted slightly it re-matches and says so. And if the text it was about is genuinely gone, the comment is marked orphaned and shown as orphaned, rather than being re-homed onto whatever now occupies that spot. You always know which of those happened.

Access and expiry

The review link carries its own access token, so there is no login step. Open it on your phone, on a second machine, wherever you actually read.

Links expire, 24 hours by default. That is deliberate: the agent is waiting on this session, and a link that never expires is a way to wedge it forever. An abandoned review resolves on its own and reports itself as expired rather than blocking indefinitely. Re-opening review for the same post returns the session you already have instead of minting a second link, so two conflicting sets of edits can never be submitted against the same draft.

Comments live with the session and expire with it. They are working notes for the review in front of you, not a permanent editorial record attached to the published post.

Using it from an agent

Two tools drive the gate:

• create_review_session takes a post UUID and returns the review URL. Give the URL to the reviewer.
• get_review_feedback reads the session. It returns pending while you are still working, submitted with {diff, comments, deletions, title, subtitle} once you press Done, and expired if the link lapsed. diffAlreadyApplied is true: the edits are in the draft already.

An agent that has opened a review session should not publish that post until the reviewer presses Done and the comments have been acted on.