# The One-Lane Review Starter Kit From "Applied AI for Marketing Ops" (appliedaiformops.com) by Lily Luo. This is a working version of the multi-model review system I used to build lilyluo.ai: roughly 100 verdicts across three model families, for under $2, with every verdict and appeal saved where I can reread them. **Pick your level:** - **Level 1 — Manual.** Two chat tabs, 15 minutes, no tools. Start here. - **Level 2 — The full setup.** For Claude Code or Cowork users who can grab an API key and use a folder structure. A scaled-down version of the exact system that reviewed my site. - **Level 3 — Hand it to your agent.** Paste this whole file to your AI agent and say "set this up for me." The last section is written as instructions for the agent. **The one rule at every level: the model that wrote the draft never reviews it.** Independence matters more than intelligence here. --- ## Level 1: One review lane by hand (15 minutes) ### Step 1. Pick one rule you care about A lane checks a draft against a rule, not against "make it better." Examples that work well for marketing teams: - Claims: "Flag every claim with a number, a date, or a superlative, and say whether the attached fact sheet backs it up." - Brand voice: "Flag every sentence that violates the attached voice guide, quote it, and say which rule it breaks." - Compliance: "Flag every statement about pricing, guarantees, or competitors, and rate how risky it is." ### Step 2. Gather the context The reviewer is only as good as what it knows. Attach the source of truth your rule depends on: the fact sheet, the voice guide, the claims library. In my build, the only reviewer that caught the real errors was the one that held my history. Context beats capability. ### Step 3. Run the review Open a chat with a model that did NOT write the draft (drafted in ChatGPT? review in Claude or Gemini; free tiers are fine). Paste this, then the context, then the draft: ``` You are a reviewer with one job. Check the draft below against this rule: [YOUR RULE FROM STEP 1] Use the attached reference material as the source of truth. Do not rewrite the draft. Do not comment on anything outside your rule. Return your review in exactly this format: verdict: pass / revise / block findings: - severity: high / medium / low quote: "[the exact words from the draft]" issue: [what is wrong, in one sentence] suggestion: [the smallest fix that resolves it] notes: [anything the format above could not capture] Rules for you: quote exactly, never paraphrase. If you are not sure a finding is real, include it with severity low and say you are unsure. "block" means: do not publish until a human resolves this. ``` ### Step 4. Save the verdict, then rule on it Paste the verdict into a doc or a column in your campaign QA sheet with four extra fields: date, which model, which draft version, and your ruling — **accept**, **reject**, or **waive**, with one line on why. Expect most findings to be noise or overreach; the lane pays for itself on the rare catch and on the questions it forces you to answer in writing. ### Step 5. Keep two things for yourself The veto and the passwords. The reviewer proposes; you rule. Use models your company has already approved; the separation of duties is what transfers, not my model lineup. --- ## Level 2: The full setup (Claude Code or Cowork, an afternoon) This is how I actually ran it. The pieces: a folder structure, one or two cheap API keys, role files that define each lane, and verdicts saved as structured files you can grep a month later. ### The folder ``` review/ roles/ one markdown file per review lane verdicts/ one file per review: role--draft--model.json appeals.md your written rulings, dated .env API keys live here .gitignore must include .env — keys never get committed ``` Keep the folder in git if you can. Version-controlled verdicts are an audit trail you can publish or hand to a stakeholder; mine publish with my site's repo. ### The keys Reviewing is the cheap models' job. DeepSeek, Kimi (Moonshot), and GLM (z.ai) all sell pay-as-you-go API keys; a few dollars covers months of review work. My 100-verdict build came to under $2. Put keys in `.env`: ``` DEEPSEEK_API_KEY=... MOONSHOT_API_KEY=... ``` Two practical notes from my build: providers run out of quota at inconvenient times, so treat any missing key as "that reviewer is benched today" rather than an error; and if your company restricts providers, a cheap tier of an approved model (Claude Haiku, for instance) does the same job. The drafter/reviewer separation is the point, not the vendor. ### The role files One markdown file per lane, three sections each: the single rule, the reviewer prompt (Level 1, Step 3), and pointers to the context files the lane needs. My real lanes, in order of value: fact-checker, voice-checker, sensitivity-reviewer, and three focus-group personas (a peer, a hiring manager, a recruiter). Start with one. ### The verdict format Every review comes back as a small structured file, named `role--draft--model.json`: ``` { "role": "fact-checker", "draft": "homepage-v2", "model": "deepseek-chat", "at": "2026-07-10T17:54:00Z", "verdict": "revise", "findings": [ { "severity": "high", "quote": "the exact words the reviewer flagged", "issue": "what is wrong, in one sentence", "suggestion": "the smallest fix that resolves it" } ], "notes": "" } ``` The fields matter more than the format. Who reviewed, which model, when, the exact quote, how serious. That's what lets you reread a call a month later. ### Running a review From Claude Code or Cowork, one instruction does it: > Read `review/roles/fact-checker.md` and the draft at [path]. Send the role's prompt, its context files, and the draft to DeepSeek using the key in `.env`. Save the verdict to `review/verdicts/` using the naming convention. Do not apply any fixes. Then rule in `appeals.md`: accept, reject, or waive, dated, with the reason. Waive in writing even when you're sure. My sensitivity lane once returned six high-severity findings; I waived all six, and the ruling file says why: the lane exists to force the question, not to win it. ### Scaling Add a second lane only after the first catches something real. When a ruling reveals a general preference, fold it into the role file or the context docs so the next review starts smarter. --- ## Level 3: For your AI agent *Human: paste this whole file to your agent and say "set this up for me." Agent: follow this section literally.* 1. Ask the human one question first: chat-window version (Level 1) or folder version (Level 2)? Build only what they choose. 2. For Level 2: create the folder structure above; confirm `.gitignore` covers `.env` before anything else. Ask the human which provider keys they have; treat missing providers as benched, not broken. 3. Create the first role file WITH the human: ask for the rule and the context files. Do not invent either. 4. To run a review: send the role file's prompt, context, and draft to a model that did not write the draft. If you drafted it, hand the review to a different model, or at minimum a fresh session with no drafting context. Save the verdict verbatim in the format above. 5. Bring findings to the human as a numbered list. Never apply a fix without a ruling. Record every ruling in `appeals.md`, dated, with the reason. 6. When rulings reveal a general preference, propose (never silently apply) an update to the role file or context docs. 7. Never publish, send, or deploy anything from a review lane. Verdicts advise; humans rule. --- Questions, or a lane that caught something good? Contact lily@lilyluo.ai.