Let one model write and another check

I need copy that sounds like me, but a fluent sentence can carry a claim the records do not support. I therefore give Codex the full brief to write from and have Claude check every claim against its source before it ships.

Give the writer the whole job

I start with the audience, the purpose and the source material. The writer needs to know who the work is for and what it should help them do. I put those decisions in the brief, so the first draft has a job to fulfil and I have a clear standard for reviewing it.

The brief also names the voice and the limits: first person, UK English, concrete tools and no invented results. Those are working constraints, so they go to the writer with the facts. A request to make copy sound confident would leave the most important decisions unstated.

I include examples of the site’s existing language as a voice reference. But those examples are not permission to import another claim. The fact sheet supplies the evidence; the voice files show how the words should feel. Keeping those roles clear makes the review possible.

Write from a bounded set of facts

Codex writes and edits the copy. I give it the facts it may use and tell it to leave unsupported detail out. That boundary helps when a story would read more smoothly with an extra date or a neat explanation that the records simply do not contain.

A command needs the same care as a result. If I want a reader to copy it, the source must contain that command. A plausible instruction is not enough. Exact wording also matters for acceptance criteria, where changing a condition can change the job itself.

The writer records where the claims came from. The checker can therefore work back from a sentence to the record behind it, instead of checking whether it sounds familiar. Missing evidence should produce a note for me, rather than an invented bridge in the story.

Ask a different model to check the claims

Claude’s job is to check the facts against the records, not to reward a good sentence. The repo records this division explicitly: Codex writes and edits; Claude reviews facts.

The welcome-sequence PRD says Codex writes the copy and Claude checks every claim. The scorecard PRD records Codex writing and Claude checking against my records. Those jobs have different outputs, but the same division of work: write from the brief, check against the evidence.

I also sent the new door copy back through Codex. The repo keeps that request with the PRD, so a returning session can see who was meant to do the work. The decision that Claude reviews facts stays with the copy rules, ready for the review.

Check the meaning as well as the number

The commit figures include work from my Claude Code and Codex sessions under my name, so I say that where I show the figures. Removing merge commits makes the count more useful, but it does not turn agent work into something I typed myself.

When a fact remains unsettled, I leave it out or flag it for checking. That gives me a specific question to resolve. Quietly smoothing over the gap would make later editing harder because the finished sentence would hide the uncertainty that produced it.

Review the words that will actually ship

Rewriting a reviewed claim can change its meaning, so I keep the source attached through the edits. If the revision changes a number, a promise or the scope of a result, Claude checks that claim again. The check belongs to the wording that will ship.

These words were made the same way.

Try the division on a piece of work your team knows well. Give the writer a full brief and the checker the records behind it. The useful output is copy you can trace back to evidence, with any remaining question visible to the person making the decision.

What the setup gives me

Models, one writing and one checking
2
PRDs naming the split: welcome sequence and scorecard
2