revüe — Proof Workflow
On-brand AI work that has to prove it is ready to ship
Start new thread

revüe — Proof Workflow - On-brand AI work that has to prove it is ready to ship

by•
An open AI review skill that inspects the real artifact, separates proof from assumptions, audits design and marketing output against a brand lock, rejects unapproved claims, and returns ship, ship with changes, caution, or block. MIT-licensed, 108 automated eval cases, local stdlib-only validators, and support for Claude Code, Codex, and Cowork.

Add a comment

Replies

Best
Maker
📌
I built revüe after seeing the same failure pattern in AI-assisted creative work: the first draft looks finished before it is proven. A polished page can still be off-brand. A persuasive metric can still be invented. A Premium layout can still be a generic template with nicer spacing. revüe turns those failure modes into gates: evidence names its source and freshness; colors, fonts, claims, hard noes, and structure can be locked and audited; Premium work clears an additional craft bar; and a ship verdict is invalid when an audit fails. The repository includes 108 eval cases and adversarial fixtures that try hidden colors, obfuscated banned copy, fabricated metrics, and forged audit results. It is open under MIT. I would especially value feedback on where the gates feel too strict and which real-world failure mode deserves the next regression test.

The stdlib-only validators are a really thoughtful choice, keeps the whole thing auditable without dragging in a dozen transitive deps. And shipping 108 eval cases out the gate shows the team actually stress-tested the thing before asking anyone to trust it.

Love the "ship with changes" middle ground, that feels way more useful than a binary pass fail. One thing that would help me actually trust the output: show the exact regex or check that tripped a block, right next to the verdict. When it says "caution" because a headline sounds too marketing-y, I want to see the signal that made it say that so I can fix it fast without digging.

A "why" trace next to each verdict would be huge, even just the specific eval cases that flipped the decision. Right now I can see ship vs block, but when it disagrees with my gut I have to dig through the rules myself to figure out which assumption it flagged.

honestly love that you went stdlib-only for the validators, that kind of restraint is rare. the ship/block/cauction taxonomy is basically a tiny decision framework and it makes the whole thing feel like an actual review partner instead of another generic ai checker.