Create an AI de-slopifier QA system for every piece of content

In Google Docs, collect at least five approved pieces that represent the brand at its best and five rejected or AI-sounding examples that show what the team wants to avoid. Include multiple formats such as blog sections, LinkedIn posts, emails, landing pages, and sales assets so the system does not overfit to one channel. Label each sample with format, audience, author, approval status, date, and whether the content is safe to use as a training example. Annotate specific passages for specificity, proof, sentence rhythm, hooks, structure, jargon, tone, credibility, useful detail, and banned patterns. Separate content that is weak because of style from content that is risky because of accuracy, product claims, customer references, or legal concerns. Ask the content owner or marketing lead to confirm that the approved examples are still current and that rejected examples accurately represent undesirable patterns. Save the source set as a versioned reference document and link every future rubric rule back to one or more examples.

Prepare the approved and rejected examples, annotations, brand voice notes, channel expectations, claim rules, and reviewer terminology. Open Claude, start a new content-QA rubric chat, and paste the prompt below into the main chat composer. Include the example set, annotations, voice principles, audience expectations, legal or product constraints, and current banned phrases as source inputs. Ask Claude to create a practical scoring rubric with categories, observable criteria, severity, examples, reviewer actions, and clear distinctions between style, credibility, and claim risk. Copy the rubric into Airtable and save the Claude conversation link or output reference with the source document. Test the rubric against at least three approved and three rejected pieces and compare its scores with human reviewer judgments. Revise any rule that is vague, channel-blind, impossible to verify, or likely to penalize intentional voice and sentence variation.

Create a practical AI-content de-slop QA rubric from these approved and rejected examples.

Source inputs:
- Approved content examples with annotations: {{good_examples}}
- Rejected or AI-sounding examples with annotations: {{bad_examples}}
- Brand voice principles: {{brand_voice_notes}}
- Audience and channel expectations: {{audience_and_channel_rules}}
- Product, legal, and claim-review constraints: {{claim_constraints}}
- Current banned phrases and patterns: {{existing_pattern_library}}

Return:
1. QA categories
2. Observable scoring rules from 1-5
3. Blocking, Needs Edit, and Optional severity definitions
4. Common AI tells and generic structures
5. Specificity and proof checks
6. Voice and sentence-rhythm checks
7. Claim-risk and credibility checks
8. Reviewer action for each failure type
9. Before-and-after examples grounded in the source set
10. Human approval checklist

Make the rubric practical for B2B marketing content. Do not treat every polished sentence, transition, or repeated term as an AI failure.

In Airtable, create fields for phrase or pattern, issue category, severity, channel, example, reason, approved exception, replacement guidance, source example, date added, owner, and review status. Add obvious clichés, vague trend openers, inflated claims, generic transitions, empty intensifiers, formulaic conclusions, repetitive sentence structures, and suspicious formatting habits. Store patterns as explainable rules rather than isolated words so reviewers understand the context in which a phrase becomes a problem. Include an Approved Exception field for required product language, regulated terminology, quotations, or phrases that are acceptable in a specific channel. Deduplicate similar entries and assign one canonical rule to avoid a library that is impossible to maintain. Review the first version with Content, Product Marketing, Brand, and any legal or product reviewers who own claim risk. Publish a read-only reviewer view and keep editing rights limited to named owners with a monthly review date.

Prepare the content draft, approved rubric, phrase library, brand voice, channel, audience, objective, source notes, and claim constraints before review. Open Claude, start a new content-QA chat, and paste the prompt below into the main chat composer. Include the complete draft, rubric, banned-pattern library, intended audience, channel, source evidence, and any sections the writer intentionally wants to preserve as source inputs. Ask Claude to identify issues by severity, quote the exact passage, explain the failure, recommend a minimal fix, and separate style problems from proof or claim risks. Copy the annotated report and revised draft into Google Docs and save the Claude conversation link or output reference in the review header. Reject suggestions that remove useful specificity, flatten the writer’s voice, introduce unsupported claims, or rewrite passages that already pass the rubric. Route blocking claim, legal, product, or customer-reference issues to the correct human owner instead of accepting an AI rewrite as resolution.

Review this content against the approved de-slop QA system.

Source inputs:
- Content draft: {{content_draft}}
- QA rubric and scoring rules: {{qa_rubric}}
- Banned phrase and pattern library: {{banned_phrase_library}}
- Intended audience, channel, and objective: {{content_context}}
- Brand voice and approved examples: {{brand_voice}}
- Source evidence and required claims: {{source_evidence}}
- Product, legal, customer, and claim constraints: {{claim_constraints}}
- Passages or stylistic choices to preserve: {{preserve_notes}}

For each issue, return:
1. Severity: Blocking, Needs Edit, or Optional
2. Exact line or phrase
3. Issue category
4. Why it weakens quality, credibility, or accuracy
5. Minimal suggested fix
6. Whether human specialist review is required
7. Relevant rubric or pattern rule

Then provide a revised version that fixes only Blocking and Needs Edit issues. Preserve meaning, useful detail, author voice, and intentional structure. Do not invent proof or make the content more generic.

Run the revised Google Docs draft through Grammarly for grammar, clarity, repetition, and readability, but review every suggestion before accepting it. Use Writer to check approved terminology, product naming, style-guide rules, capitalization, and any governed language available to the team. Create a claims table for every statistic, customer statement, product capability, competitor comparison, outcome, quotation, and time-sensitive assertion. Record the claim, source URL or document, source date, reviewer, approval status, and whether the language must be qualified. Route product, customer, legal, compliance, security, or competitive claims to the appropriate owner rather than resolving them as copy edits. Keep style feedback separate from claim-review comments so ownership and blocking status remain clear. Advance the draft only when every blocking claim has an approved source, approved wording, or an explicit decision to remove it.

Assign one accountable content owner to perform the final read-aloud pass in Google Docs after AI, grammar, terminology, and claim reviews are complete. Read the piece exactly as the audience will encounter it and note awkward rhythm, missing context, repetitive structure, unnatural transitions, generic claims, and sentences the reviewer would be uncomfortable saying aloud. Evaluate whether the audience will find it useful, whether the brand would publish it under a named leader, and whether it sounds like a person with direct experience wrote it. Limit comments to changes that affect usefulness, accuracy, credibility, voice, or comprehension rather than personal wording preference. Resolve all blocking comments, confirm required reviewers, and record Approve, Approve with Minor Edits, or Reject with the reviewer and date. Compare the final version with the original draft to ensure editing did not remove the strongest detail, opinion, evidence, or distinctive phrasing. Lock the approved version and keep later channel formatting separate from substantive copy changes.

At the end of each review batch, export or summarize the Airtable issues by category, severity, writer, prompt source, content type, channel, and final resolution. Open Claude, start a new QA-system improvement chat, and paste the prompt below into the main chat composer. Include the issue log, current rubric, pattern library, rejected suggestions, human overrides, approval outcomes, and sample sizes as source inputs. Ask Claude to identify recurring patterns, upstream prompt causes, reviewer disagreement, rules producing false positives, and changes that may reduce future cleanup. Copy the analysis into the monthly QA review record and save the Claude conversation link or output reference with the Airtable view. Have the content owner approve each rubric, pattern, or upstream-prompt change and record the rationale, effective date, owner, and test plan. Retire rules that are obsolete or consistently overruled and measure whether approved changes reduce blocking issues, editing time, and reviewer disagreement in the next cycle.

Analyze this content-QA issue log and recommend evidence-based improvements.

Source inputs:
- Current-period issue log: {{issue_log}}
- Current QA rubric: {{qa_rubric}}
- Phrase and pattern library: {{pattern_library}}
- Human overrides and rejected AI suggestions: {{human_overrides}}
- Approval outcomes and editing time: {{approval_metrics}}
- Content types, channels, writers, and source prompts: {{content_context}}
- Sample size and review period: {{measurement_context}}

Return:
1. Most frequent blocking and needs-edit issues
2. Patterns by content type, channel, writer, or source prompt
3. Likely upstream causes
4. Rules generating false positives or reviewer disagreement
5. Rubric rules to keep, revise, add, or retire
6. Pattern-library changes
7. Upstream prompt or process changes
8. Recommended owner for each change
9. Next-cycle test and success metric
10. Limitations caused by sample size or inconsistent logging

Separate observed patterns from hypotheses. Do not recommend broad rule changes when the sample is too small.