Content Accuracy Review Skill

How to use it

1. Create a folder named content-accuracy-review in your Codex skills directory.
2. Save the skill below as SKILL.md inside that folder.
3. Ask Codex to review a project's content for factual accuracy, source support, or outdated claims.

Example prompts

SKILL.md

---
name: content-accuracy-review
description: Audit project content for factual accuracy, source support, outdated dates, fabricated quotes, unsupported claims, misleading SEO copy, and stale documentation. Use when the user asks to review whether a website, README, landing page, article, app copy, marketing page, technical explainer, or other repository content is accurate or truthful.
---

# Content Accuracy Review

## Overview

Use this skill to turn a vague request like "check whether this project's content is accurate" into a source-backed editorial and factual review. Prioritize correctness over style; only suggest copy changes when they fix accuracy, sourcing, or misleading framing.

## Workflow

1. Inventory likely content files with `rg --files`, prioritizing pages, README files, metadata, schema markup, localized strings, docs, and seed data.
2. Extract factual claims: dates, names, titles, institutions, product capabilities, statistics, quotes, legal/medical/financial/security claims, and "latest/current" wording.
3. Separate stable claims from unstable claims. Browse for unstable claims, recent claims, niche claims, public figures, security research, software behavior, prices, laws, policies, or anything with a meaningful chance of having changed.
4. Prefer primary sources: official docs, papers, project pages, standards, company announcements, registry pages, and source repositories. Use reputable secondary reporting only to corroborate or contextualize.
5. Compare project text against sources. Flag unsupported certainty, wrong dates, fabricated or paraphrased quotes presented as quotes, missing caveats, over-broad generalizations, and SEO titles that distort the source.
6. Fix the content when the user asked for improvement or when the request implies action. Keep edits scoped to factual accuracy unless asked for broader rewriting.
7. Validate with the repository's available checks, such as lint, typecheck, tests, or build. If no checks exist, state that clearly.

## Review Standards

- Do not treat plausible content as true without evidence.
- Do not leave a direct quote unless it matches the source and is attributed. If the text is a summary, label it as a summary.
- Replace relative dates like "new", "recent", "last year", and "as of today" with absolute dates when clarity matters.
- Preserve nuance from sources: "tested", "reported", "demonstrated", "potentially vulnerable", and "confirmed exploited" mean different things.
- Mark claims as unverified or remove them when no reliable source is found.
- Add links for further reading when source support is central to the page.
- Keep the user's voice and project structure where possible.

## Reporting

When reviewing only, report findings first, ordered by severity, with file and line references. For each issue, include:

- The inaccurate or unsupported claim
- The source-backed correction
- The risk to readers if left unchanged

When editing, summarize the corrections made and list verification commands. Include source URLs in the final answer when external facts drove the changes.