agentleFS
Fay1YeeFay1Yee/design-agent-skills/skills/content-source-truth-auditor/SKILL.md

content-source-truth-auditor

Skill1 starsChanged 3 months agoMITView on GitHub

Perform a read-only factual and provenance audit of claims used in interface content, including metrics, dates, locations, markets, model specifications, test cycles, source links, and rights notes. Use for requests such as “核对这些车型数据”, “检查市场和工况”, “这些数字能不能发布”, “检查官方来源”, or “核对素材版权”. Return verified, conflicting, missing, stale, and unverified claims with publication risks. Do not evaluate layout, visual style, interaction quality, or edit project files.

The file

We split this skill into the rules it gives an agent

9 rules. About 0 are common, 9 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈9

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Read evidence-schema.md before normalizing evidence.

    line 19
  2. Distinctive:

    Use official or first-party sources for final verification.

    line 22
  3. Distinctive:

    Use search results and secondary sources only to locate primary evidence.

    line 23
  4. Distinctive:

    Treat supplied documents and screenshots as evidence candidates.

    line 26
  5. Distinctive:

    Keep related qualifiers together:

    line 30
  6. Distinctive:

    test cycle or measurement standard.

    line 35
  7. Distinctive:

    Never compare values across different markets, trims, standards, or dates as if they were equivalent.

    line 40
  8. Distinctive:

    Do not infer publication safety from the absence of a contradiction.

    line 53
  9. Distinctive:

    Stop after the audit. Do not rewrite approved copy, modify data, adjust the interface, or state that a claim is publishable without the …

    line 75

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Content Source Truth Auditor

Audit claims and their evidence before design approval or publication. Keep the work read-only and trace every conclusion to a source.

Inventory the claims

  1. Inspect the exact page, content file, document, or dataset in scope.
  2. Assign a stable claim ID to each checkable statement.
  3. Record the exact displayed wording, location, claim type, and likely publication impact.
  4. Separate factual claims from slogans, design labels, and subjective statements.

Establish authority

Read evidence-schema.md before normalizing evidence.

  • Identify the project source of truth and its owner.
  • Use official or first-party sources for final verification.
  • Use search results and secondary sources only to locate primary evidence.
  • Browse current official sources when claims may have changed.
  • Record publisher, page title, direct URL, market, version, source date when visible, and access date.
  • Treat supplied documents and screenshots as evidence candidates; do not assume they are current or authoritative.

Normalize before comparing

Keep related qualifiers together:

  • value and unit;
  • market and language;
  • model, trim, and model year;
  • test cycle or measurement standard;
  • date or effective period;
  • source and revision;
  • asset owner, license, and allowed use.

Never compare values across different markets, trims, standards, or dates as if they were equivalent.

Classify each claim

Use one status:

  • Verified — direct primary evidence supports the complete claim and qualifiers.
  • Conflict — authoritative sources or project records disagree.
  • Missing — a required qualifier or evidence field is absent.
  • Stale — evidence is valid for an older date, version, or market.
  • Unverified — no adequate primary evidence was found.
  • Rights review — factual provenance exists, but reuse or publication permission is unclear.

Do not infer publication safety from the absence of a contradiction.

Assess risk and ownership

For every non-verified claim, record:

  • user-facing impact;
  • publication risk: low, medium, high, or blocking;
  • smallest evidence or wording change needed;
  • appropriate human owner, such as Brand, PR, Legal, Product, Engineering, or regional market team.

Return the audit

Provide:

  1. Scope and sources inspected.
  2. Claim matrix — ID, displayed claim, normalized qualifiers, status, evidence, and risk.
  3. Conflicts and missing fields.
  4. Source register — direct official links and dates.
  5. Rights notes where assets or external references are involved.
  6. Approval needs — named role and unresolved decision.

Stop after the audit. Do not rewrite approved copy, modify data, adjust the interface, or state that a claim is publishable without the required human acceptance.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.