Content Quality Auditor

Content Quality Auditor

Based on CORE-EEAT Content Benchmark. Full benchmark reference: references/core-eeat-benchmark.md

This skill evaluates content quality across 80 standardized criteria organized in 8 dimensions. It produces a comprehensive audit report with per-item scoring, dimension and system scores, weighted totals by content type, and a prioritized action plan.

When This Must Trigger

Use this when content needs a quality check before publishing — even if the user doesn't use audit terminology:

• User asks "is this ready to publish" or "how good is this"
• User just finished writing with seo-content-writer or content-refresher
• PostToolUse hook auto-triggers: after content is written or substantially edited, the hook recommends this audit. When hook-triggered, skip setup questions — audit the content that was just produced.
• Auditing content quality before publishing
• Evaluating existing content for improvement opportunities
• Benchmarking content against CORE-EEAT standards
• Comparing content quality against competitors
• Assessing both GEO readiness (AI citation potential) and SEO strength (source credibility)
• Running periodic content quality checks as part of a content maintenance program
• After writing or optimizing content with seo-content-writer or geo-content-optimizer

What This Skill Does

1. Full 80-Item Audit: Scores every CORE-EEAT check item as Pass/Partial/Fail
2. Dimension Scoring: Calculates scores for all 8 dimensions (0-100 each)
3. System Scoring: Computes GEO Score (CORE) and SEO Score (EEAT)
4. Weighted Totals: Applies content-type-specific weights for final score
5. Veto Detection: Flags critical trust violations (T04, C01, R10)
6. Priority Ranking: Identifies Top 5 improvements sorted by impact
7. Action Plan: Generates specific, actionable improvement steps

Quick Start

Start with one of these prompts. Finish with a publish verdict and a handoff summary using the repository format in Skill Contract.

Audit Content

Audit this content against CORE-EEAT: [content text or URL]

Run a content quality audit on [URL] as a [content type]

Audit with Content Type

CORE-EEAT audit for this product review: [content]

Score this how-to guide against the 80-item benchmark: [content]

Comparative Audit

Audit my content vs competitor: [your content] vs [competitor content]

Skill Contract

Gate verdict: SHIP (no critical issues, dimension scores above threshold) / FIX (issues found but none critical) / BLOCK (a critical trust issue failed — see "Critical Issue to Fix" in the report). Always state the verdict prominently at the top of the report using plain language, not item IDs.

Expected output: a CORE-EEAT audit report, a publish-readiness verdict, and a short handoff summary ready for memory/audits/content/.

• Reads: the target content, content type, supporting evidence, and any prior decisions from CLAUDE.md and the shared State Model when available.
• Writes: a user-facing audit report plus a reusable summary that can be stored under memory/audits/content/.
• Promotes: veto items and publish blockers to memory/hot-cache.md (auto-saved, no user confirmation needed). Top improvement priorities to memory/open-loops.md.
• Next handoff: use the Next Best Skill below once the verdict is clear.

Data Sources

See CONNECTORS.md for tool category placeholders.

With ~~web crawler + ~~SEO tool connected: Automatically fetch page content, extract HTML structure, check schema markup, verify internal/external links, and pull competitor content for comparison.

With manual data only: Ask the user to provide:

1. Content text, URL, or file path
2. Content type (if not auto-detectable): Product Review, How-to Guide, Comparison, Landing Page, Blog Post, FAQ Page, Alternative, Best-of, or Testimonial
3. Optional: competitor content for benchmarking

Proceed with the full 80-item audit using provided data. Note in the output which items could not be fully evaluated due to missing access (e.g., backlink data, schema markup, site-level signals).

Decision Gates

When stopping to ask, always: (1) state the specific value and threshold, (2) offer numbered options with outcomes.

Stop and ask the user when:

• Content is under minimum word count for its type (blog/guide: 300 words; product/landing page: 150 words; FAQ: fewer than 3 entries with 50+ words each) — state the actual count and offer: (1) expand to minimum, (2) continue audit with Insufficient Data flags, (3) cancel
• Content type cannot be auto-detected — state what you detected and ask to confirm before proceeding
• Content is primarily media (video/image) with minimal text — ask whether to audit transcript, alt text, or skip
• More than 50% of a dimension's items are N/A — name the dimension and ask: (1) provide supplementary data, (2) mark entire dimension as Insufficient Data
• Any veto item triggers — flag it immediately with the item ID and ask: (1) stop for immediate fix, (2) continue full audit and flag in report

Continue silently (never stop for):

• Individual Partial scores within a dimension
• Missing SEO tool data (mark items as N/A and continue)
• Low overall score (the report is the deliverable, not a judgment call)
• User not specifying content type (auto-detect and state your assumption)

Instructions

When a user requests a content quality audit:

Step 1: Preparation

### Audit Setup

**Content**: [title or URL]
**Content Type**: [auto-detected or user-specified]
**Dimension Weights**: [loaded from content-type weight table]

#### Critical Trust Check (Emergency Brake)

| Check | Status | Action |
|-------|--------|--------|
| Affiliate links disclosed | ✅ Pass / ⚠️ CRITICAL | [If CRITICAL: "Add disclosure banner at page top immediately"] |
| Title matches page content | ✅ Pass / ⚠️ CRITICAL | [If CRITICAL: "Rewrite title and first paragraph to match"] |
| Data points are consistent | ✅ Pass / ⚠️ CRITICAL | [If CRITICAL: "Verify all data before publishing"] |

If any veto item triggers, flag it prominently at the top of the report and recommend immediate action before continuing the full audit.

Step 2: CORE Audit (40 items)

Evaluate each item against the criteria in references/core-eeat-benchmark.md.

Score each item:

• Pass = 10 points (fully meets criteria)
• Partial = 5 points (partially meets criteria)
• Fail = 0 points (does not meet criteria)

### C — Contextual Clarity

| ID | Check Item | Score | Notes |
|----|-----------|-------|-------|
| C01 | Intent Alignment | Pass/Partial/Fail | [specific observation] |
| C02 | Direct Answer | Pass/Partial/Fail | [specific observation] |
| ... | ... | ... | ... |
| C10 | Semantic Closure | Pass/Partial/Fail | [specific observation] |

**C Score**: [X]/100

Repeat the same table format for O (Organization), R (Referenceability), and E (Exclusivity), scoring all 10 items per dimension.

Step 3: EEAT Audit (40 items)

### Exp — Experience

| ID | Check Item | Score | Notes |
|----|-----------|-------|-------|
| Exp01 | First-Person Narrative | Pass/Partial/Fail | [specific observation] |
| ... | ... | ... | ... |

**Exp Score**: [X]/100

Repeat the same table format for Ept (Expertise), A (Authority), and T (Trust), scoring all 10 items per dimension.

See references/item-reference.md for the complete 80-item ID lookup table and site-level item handling notes.

<!-- runbook-sync start: source_sha256=782eb8827d3139216dbf55154285f72b5fe6d1601acc693bb93d769df5224e2f block_sha256=5053bbe68577b7ca6fd16551244ac6de6b9c7e694be6c400ecef1af0a4df820d -->

§1 · Handoff Schema (authoritative)

Every auditor-class handoff MUST follow this shape. Emitted audit artifact files (e.g., memory/audits/**/*.md) MUST include class: auditor-output in their YAML frontmatter so the PostToolUse Artifact Gate and guarded auditor archive checks can detect them by frontmatter class instead of prose pattern-matching. Files lacking this marker are not treated as audit artifacts regardless of body content.

---
class: auditor-output            # REQUIRED frontmatter marker for emitted audit artifacts
---

status: DONE | DONE_WITH_CONCERNS | BLOCKED | NEEDS_INPUT
objective: "what was audited"
key_findings:
  - title: short issue name
    severity: veto | high | medium | low
    evidence: direct quote or data point
evidence_summary: URLs / data points reviewed
open_loops: blockers or missing inputs
recommended_next_skill: primary next move

# Cap-related fields — AUDITOR-CLASS ONLY
cap_applied: true | false        # REQUIRED for auditors
raw_overall_score: <number>      # REQUIRED for auditors; score before cap
final_overall_score: <number>    # REQUIRED for auditors; score after cap

Legacy compatibility for archived outputs

New auditor-class outputs MUST include the cap-related fields. The Artifact Gate treats missing cap_applied, raw_overall_score, or final_overall_score (unless status: BLOCKED) as a validation failure.

Consumers reading pre-v7.2 archived outputs may apply these defaults:

• cap_applied: false (assume no cap when field missing)
• raw_overall_score: <use final_overall_score> (treat as equal)
• final_overall_score: <use the overall score from the audit, whatever field name>

This compatibility rule is read-time only; it does not permit new auditor artifacts to omit required auditor-extension fields.

Non-auditor skills

Non-auditor skill handoffs follow skill-contract.md §Handoff Summary Format as-is. Cap-related fields do not apply. Non-auditors never emit cap_applied / raw_overall_score / final_overall_score, and MUST NOT use the class: auditor-output frontmatter marker.

§2 · Critical Fail Cap — Decision Table and Worked Examples

How to use this section in Step 4.5: read Worked Example 1 in references/fail-cap-worked-examples.md before computing your own cap and mirror its format literally. Walk the decision table (4 rows) to identify which scenario matches your input. Count veto failures across all dimensions (not per-dimension). Apply the cap rule — it is a ceiling, not a floor.

Rule summary: when any veto item fails, cap the affected dimension and the overall score at 60/100. Show raw and capped side by side in the internal report. Set cap_applied: true in handoff.

Veto items:

• CORE-EEAT: T04, C01, R10 — see references/core-eeat-benchmark.md §Veto Items
• CITE: T03, T05, T09 — see references/cite-domain-rating.md §Veto Items

Decision table

Cap target: always the post-penalty final dimension value, never the raw pre-penalty value. If non-veto items already penalized the dimension, compute the post-penalty number first, then apply the veto cap to that.

Rounding rule (deterministic): all score arithmetic uses math.floor (truncate decimals). 77.5 → 77, not 78. 59.9 → 59, not 60. Applies to raw_overall_score, final_overall_score, dimension scores, and all intermediate calculations. QA and regression tests can rely on this — a re-run on the same inputs always produces the same integer. Worked Example 2 demonstrates: raw_overall = 77.5 appears as raw_overall_score: 77 in the handoff.

Worked examples

Three worked examples (single veto above cap / single veto below cap / 2+ veto BLOCKED path) live in references/fail-cap-worked-examples.md. Read Worked Example 1 there before computing your own cap and mirror its "Before cap / Veto check / After cap / Handoff" format literally.

§3 · Guardrail Negatives (windowed positive reframes)

These signals are POSITIVE under stated conditions. Award points, do not deduct. Conditions are explicit — unconditional positive reframes cause false negatives.

Exception path

If the content is explicitly evergreen or the context contradicts a positive reframe, state the exception in the finding's evidence field. For example:

"Year 2024 appears in title. Content is labeled 'evergreen guide' and aims for 2+ year longevity; the 2024 stamp will date the page unnecessarily. Flagged for R dimension."

Current year reference

The windowed year rule depends on the date at audit time, not a hardcoded year in this file. Evaluate current_year dynamically when applying §3.

§4 · Artifact Gate Checklist (7-item self-check)

Before emitting the handoff, the auditor verifies:

• status is one of the 4 enum values (DONE / DONE_WITH_CONCERNS / BLOCKED / NEEDS_INPUT)
• key_findings is an array (may be empty)
• Every finding has title + severity + evidence
• cap_applied is explicitly set (true or false) — auditor-class requirement
• raw_overall_score present (auditor-class requirement; may equal final_overall_score)
• final_overall_score present UNLESS status == BLOCKED
• evidence_summary non-empty
• recommended_next_skill present

If any check fails, force status: BLOCKED with open_loops: ["artifact_gate_failed: <which check>"].

Reliability note: v7.2.0 adds a PostToolUse hook that re-validates this checklist outside the self-check loop, in a clean LLM context. Self-check is first line of defense (~35% reliable); external hook is second line (~85%). Together: ~95%. Until the hook ships, rely on self-check with awareness that it is not robust against the auditor's own output bias.

§5 · User-Facing Translation Layer

Before rendering to the user, translate internal language. This respects skill-contract.md §Response Presentation Norms which forbids internal jargon in user output.

Forbidden in user-visible output

• Veto item IDs (T04, C01, R10, T03, T05, T09, and any future IDs)
• Phrases combining "dimension" or "capped at" with raw numbers
• Internal field names: cap_applied, raw_overall_score, final_overall_score, gap_type
• Raw score deltas like "82 → 60" as the primary presentation

Required pattern when cap is applied

**Overall Score: 60/100**  *(capped due to 1 critical issue)*

**Critical issue to fix:**
- Missing affiliate disclosure on your product review
  *(search engines and AI engines treat unsigned affiliate content as low-trust)*

**Fix this one item and your score rises to approximately 78.**

Required pattern when status is BLOCKED (multi-veto)

**Status: Cannot score yet** — 2 critical issues need attention first.

1. Missing affiliate disclosure on your product review
2. Data points contradict each other (prices in intro section don't match the comparison table)

Fix these, then rerun the audit for a score.