skills: mandatory adversarial review in content-write-blog (#8044)

* skills: add mandatory adversarial review to content-write-blog

Every finished draft gets reviewed by fresh-context agents with refutation
missions (fact/code/reader/positioning lenses) before any PR; implementer
fixes, reviewers re-review, loop until a round returns zero confirmed
findings. Version 2026.7.9.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* skills: adversarial review runs every applicable lens, regardless of post size

One reviewer per applicable lens (fact/reader/positioning always, code when
present) replaces the 'at least two' floor; subagents-vs-workflow named as
an implementation choice, not a review-depth choice.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

* skills: adversarial review is Step 10 of the process, not an appendix

Numbered into the step sequence as the final gate before any PR; Step 9
hand-off now points to it as 'complete Step 10 before opening any PR'.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
Co-authored-by: Ankur Datta <64993082+ankur-arch@users.noreply.github.com>

Author: 3 people

.claude/skills/content-write-blog/SKILL.md

@@ -2,7 +2,7 @@
 name: content-write-blog
 description: Use when the operator wants to write a blog post, draft a blog article, start a new post for the Prisma blog, or publish to prisma.io/blog.
 metadata:
-  version: "2026.7.8"
+  version: "2026.7.9"
 ---
 
 # Write Blog Post
@@ -146,10 +146,31 @@ End by giving the operator, in a short block:
 - The path to the post file (within their checkout).
 - The author profile path, if one was scaffolded.
 - A reminder that the repository workflow is theirs: create a feature branch, commit the skeleton (and author profile), push, and open the pull request following the blog repo's contribution process. The pull request should be opened as a **draft** until the post is fleshed out.
-- A clear next-step instruction: _"Edit the post to flesh out each section, keep it consistent with positioning and free of AI slop (see Writing quality), run the `content-seo-geo` skill in this repo to optimize the finished draft for search engines and AI answer engines, then branch, commit, push, and open a draft PR per the blog repo's contributing guide."_
+- A clear next-step instruction: _"Edit the post to flesh out each section, keep it consistent with positioning and free of AI slop (see Writing quality), run the `content-seo-geo` skill in this repo to optimize the finished draft for search engines and AI answer engines, then complete Step 10 before opening any PR."_
 
 Do not claim the post is "done" or "ready" — it is a skeleton handed back to the operator.
 
+## Step 10: Adversarial review
+
+The final step of the process, and the gate to a pull request: once the skeleton has been fleshed into a finished draft and the `content-seo-geo` pass is done, the draft is reviewed by agents that did not write it, in separate context windows. The author (human or agent) wants the post to ship; a reviewer with a fresh context and a refutation mission does not share that bias. A blog post is a set of falsifiable claims — prices, version numbers, benchmark figures, API behaviors, links — and the reviewers' job is to falsify them.
+
+### How to run it
+
+Spawn one reviewer agent per applicable lens, every lens that applies, regardless of post length. The fact, reader, and positioning lenses apply to every post; the code lens applies whenever the post contains runnable code. Whether the reviewers run as plain subagents or as an orchestrated review workflow is an implementation choice, not a review-depth choice: a workflow's vote-counting and automated re-review loops pay off when findings are numerous, but the lenses and rules are identical either way. Rules that make the isolation real:
+
+1. **Reviewers receive only the draft file path and their mission.** Never include the writing conversation, the pitch, the outline, or any statement of what the post intends or why it is correct. A prompt that says "review this post, which correctly explains X" has already contaminated the reviewer.
+2. **Each reviewer gets a refutation mission, and skepticism is the default.** "Find reasons this is wrong" outperforms "check whether this is right."
+3. **Distinct lenses, one per reviewer** — diversity catches what redundancy misses. The lenses:
+   - **Fact refuter**: attack every number, price, version, date, and named behavior. Verify each against the live primary source (vendor pricing page, official docs), not from memory. Report any claim whose source does not say what the post says.
+   - **Code refuter** (posts with code): run every sample fresh against the stated versions. Report anything that does not compile, run, or produce the shown output.
+   - **Reader skeptic**: where does the post confuse, overclaim, contradict itself, or read like marketing? Where would a knowledgeable reader stop trusting it?
+   - **Positioning refuter**: report claims that contradict the positioning doc or overstate product status (GA claims, superlatives, unverified benchmarks).
+4. **The implementer fixes; reviewers re-review.** Findings come back to the authoring session, which applies fixes. Re-run the reviewers on the fixed draft. Repeat until a round produces no confirmed findings. The implementer never marks its own finding as resolved without a reviewer pass confirming it.
+
+### Completion criterion
+
+The draft is ready for the operator's PR when the most recent review round returned zero confirmed findings, and the operator has been given the final round's summary (findings found and fixed per round) so they can judge the review's depth, not just its verdict.
+
 ## Writing quality
 
 The lead you draft, and the prose the author later writes over your stubs, ship to prisma.io/blog as public content. Draft the lead to this bar, and name the same bar in the hand-off so the author holds it: