agentleFS
karerokarero/website-builder/skills/website-content-guide/SKILL.md

website-content-guide

Skill9 starsChanged 30 days agoMITView on GitHub

Create and maintain a new site's CONTENT_GUIDE.md and BRAND.md — Tone of Voice and EEAT (Experience/Expertise/Authoritativeness/Trust) signals — so every page hangs off one source of truth for HOW it says it. Reads positioning from POSITIONING.md (owned by website-positioning, which runs first); it does not redefine positioning. Use at the start of a new site (step 3 of the new-website pipeline, after website-positioning), before writing page copy, and whenever reviewing/editing copy for voice. Pairs with the tone test (tests/tone.spec.ts) which hard-enforces the voice rules. Trigger phrases: "content guide", "tone of voice", "brand voice", "is this on brand", "EEAT", "E-E-A-T", "write the content guide", "set up the brand doc", "review the copy", "does this sound like AI".

1 other project uses a version of this.

Adopted by

Most recently taken up by

The file

We split this skill into the rules it gives an agent

1 rule. About 0 are common, 1 is distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    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:

    Do this for the reader's trust.

    line 135

≈ “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

Website content guide & voice

Owns the how it says it layer of a new site: tone of voice and EEAT signals, captured in the per-site docs that everything downstream reads. Positioning (what you offer, for whom, the market category) is owned by website-positioning and worked out first; this guide reads it from POSITIONING.md and must stay consistent with it — it does not redefine it. A quick "does this still read clearly to a stranger" check on an already-built site is website-positioning-check, not this guide — it's a read-only diagnostic, not a voice/EEAT audit.

Outputs

  • CONTENT_GUIDE.md (from the new-website skill's templates/content-guide.md) — ToV rules, EEAT checklist, page inventory with target titles, per-page-type copy templates, new-page checklist. Reads positioning/audience from POSITIONING.md.
  • POSITIONING.md is owned by website-positioning; this guide consumes it and must not restate the positioning (single source of truth).
  • BRAND.md is owned by website-design-system, but its positioning line comes from POSITIONING.md — keep them consistent. Each of its two parts, the palette and the logo, has its own source: what the owner brought or chose at new-website §2b (her own colours or logo, or the ones the optional website-brand-kit helped her to) stands, and is not changed here. A part she neither brought nor wanted help with keeps the starter's default until website-design-system fills it.
  • STORY.md (optional, owned by website-story): when present, the home page's section order in the per-page-type copy template comes from its seven-section map. The voice rules here apply unchanged.

How to use

  1. Positioning comes first: website-positioning has already produced POSITIONING.md (what you offer, for whom, the market category). Read it and build the voice on top of it. Then pull insights: run customer-research for ICP + voice-of-customer, and content-strategy if topic planning is needed. Feed the findings in.
  2. Copy the template to CONTENT_GUIDE.md and fill every [BRACKET].
  3. For actual page copy, hand off wording to copywriting, then apply the voice rules below and run the tone test.

Tone of voice — the hard rules (enforced by the tone test)

These mirror the tone guards proven on earlier production sites. The test is the source of truth; the guide explains the why.

  • No em dashes (—). Comma, period, or colon instead.
  • Active voice; proof over claims.
  • Exempt: genuinely quoted customer/human voice — wrap in <blockquote>, <q>, or add data-tov-exempt. Do not use this to smuggle brand copy past the rules.

Role words (not checked by the tone test): where a page calls the reader by a role (owner, user, client or member), say once, before the page first uses the word to say who does what, that it means the reader. Call the people behind the site by name or "we", not by the same role word.

The rules below are lexical (specific words/mechanisms to avoid) and differ by language — apply the subsection that matches the site's content language.

English content

  • No contractions. Long form: "cannot", "it is", "you are", "we are".
  • No buzzwords: supercharge, world-class, leverage, unlock, seamless, robust, cutting-edge, empower, holistic, revolutionary, synergy, next-level (trim/extend per brand).
  • Speak to the reader as "you".

German content

English's "no contractions" rule has no German equivalent — German doesn't contract "cannot" into "can't" the way English does, so there's no parallel mechanism to enforce. The real formality lever in German is register: informal "du" vs. formal "Sie" — and, more important than which one you pick, staying consistent with that choice for the entire page. Mixing "du" and "Sie" mid-page doesn't read as a stylistic choice; it reads as a translation error.

  • Pick du or Sie per brand, then hold it for the whole page. This is a per-brand decision, not a universal rule — record the choice explicitly in BRAND.md/CONTENT_GUIDE.md so every page follows the same one. A community/consumer brand aiming for approachable and informal typically picks "du" throughout; a B2B/enterprise or public-sector brand more often picks "Sie" — either is fine as long as it's consistent.
  • This is the German answer to "speak to the reader as 'you'" — the du/Sie choice above settles it; don't treat "you" as a separate, unresolved question for German copy. tone.spec.ts machine-checks the unambiguous mixing cases (lowercase du-family vs. capitalized "Kontaktieren Sie ..." imperatives on one page); subtler shifts still need a human read.
  • No buzzwords: ganzheitlich, nahtlos, Synergie(n), Synergieeffekt(e/en), bahnbrechend, revolutionär, wegweisend, erstklassig, hochmodern, maßgeschneidert (Swiss spelling "massgeschneidert" is caught too — the enforced test doesn't fold ß↔ss, so both spellings are listed explicitly), zukunftsweisend, transformativ, unschlagbar, entfesseln/entfesselt, Spitzenreiter (trim/extend per brand).
  • AI-tell phrases to avoid:
    • "In der heutigen ... Welt" (the enforced test tolerates up to two modifiers and compound Welt-nouns like "Geschäftswelt")
    • "Es ist wichtig zu betonen/beachten/erwähnen, dass..."
    • "Zusammenfassend lässt sich sagen,..."
    • "Lassen Sie uns / Lass uns / Lasst uns eintauchen / einen Blick werfen"

EEAT — build it in from the start

Google calls these signals E-E-A-T: Experience, Expertise, Authoritativeness and Trust. It says E-E-A-T "itself isn't a specific ranking factor", but that "using a mix of factors that can identify content with good E-E-A-T is useful", and that of the four "trust is most important" (Google). Ship the signals, not just claims:

  • Experience/Expertise: named authors with a real bio and a stable schema @id; first-hand specifics and dates; inline citations on claim-heavy copy (what a citation holds: Claims on the page, below).
  • Authoritativeness: sameAs profiles that actually resolve (LinkedIn, GitHub, public register); Organization schema; corroborating external mentions.
  • Trust: imprint/legal entity page, clear contact, privacy page, last-updated timestamps, HTTPS, zero broken links.

Claims on the page. Give every figure what a reader needs to check it:

  • Every figure carries its source, its date and what it counts: "120 clients since 2019", not "120+ happy clients"; a survey says who was asked and when.
  • Name the seller. A study by a company that sells what it measures says so.
  • Keep the finding apart from your conclusion: first what the source found, then what the business takes from it.
  • Put each figure in the facts-check list (value, source, owner), so every page says the same.

Do this for the reader's trust; don't promise that it raises AI citations.

The author/Organization/sameAs plumbing lives in website-seo-geo (schema) and config.ts/SAME_AS; this skill decides what those signals should be.

Done means

CONTENT_GUIDE.md filled, voice consistent with POSITIONING.md and BRAND.md, and the tone test green after any copy change (npm test runs tone.spec.ts).

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.