Writing for Wire - Edit Styleguides, Not Source Code

You control Wire's output by editing markdown files, not code. The styleguide at docs/_styleguide.md shapes every page Claude writes. Topic overrides let you set different rules for different sections. This guide shows how, using two fictional businesses:

• AutoFix München. Car repair shop. 45 service pages in German. Topics: services, standorte, blog.
• CompareStack. SaaS comparison site. 200+ vendor profiles in English. Topics: vendors, comparisons, guides.

What a Styleguide Controls

The same page generated with two different styleguides produces entirely different output. Here is the same vendor page, a brake inspection service, run through each site's styleguide:

The content engine is identical. The styleguide is the only difference.

The Personality Trick

Give Claude a role in the first lines of your styleguide. The role determines vocabulary, sentence structure, and what Claude assumes about the reader.

AutoFix styleguide opening:

## Editorial Rules for autofix-muenchen.de

You are a straightforward mechanic explaining repairs to car owners.
Write as if the customer is standing in front of you at the counter.
Use simple language. Avoid technical jargon unless you explain it immediately.

Output:

Ihre Bremsscheiben sind abgenutzt. Das merken Sie am Quietschen beim Bremsen. Der Wechsel dauert etwa zwei Stunden und kostet zwischen 180 und 350 Euro pro Achse, je nach Fahrzeugmodell.

CompareStack styleguide opening:

## Editorial Rules for comparestack.com

You are a senior analyst writing for CTOs evaluating enterprise software.
Assume the reader manages 50+ software licenses and understands TCO.
Write with precision. Every claim needs a source or a data point.

Output:

ABBYY FlexiCapture supports on-premise deployment with HIPAA-compliant document routing. Annual licensing starts at $48,000 for the base tier (ABBYY pricing page, January 2026). Organizations processing over 500,000 pages per month should evaluate the per-page model, which drops below $0.03 at volume.

The role statement is the single highest-impact line in your styleguide. Change the role, and the entire output shifts.

Good and Bad Styleguide Rules

Claude follows instructions literally. Vague rules produce vague output. Rigid rules produce broken prose. Contradictory rules produce unpredictable results.

Rules That Fail

Rules That Work

The pattern: good rules have a binary test. Claude can check each sentence against the rule and get a yes/no answer.

Banned Word Lists

Banned words eliminate the filler language that makes every page sound the same. Put them in a dedicated section of your styleguide.

AutoFix banned words:

## Verbotene Wörter

Verwende niemals diese Wörter oder Varianten davon:
erstklassig, führend, innovativ, Ihr Experte, modernste,
hochqualifiziert, langjährige Erfahrung, Kompetenz, Leidenschaft

CompareStack banned words:

## Banned Words

Never use these words or their variants:
best-in-class, industry-leading, seamless, cutting-edge, robust,
next-generation, world-class, turnkey, synergy, end-to-end

Banned words force Claude to replace marketing fluff with specifics. The output becomes more useful to readers because every sentence must carry information.

AI Writing Tells

LLMs have stylistic habits that mark content as machine-generated. Readers and search engines are increasingly tuned to detect these. Your styleguide should explicitly ban the most common patterns.

Em-dashes

The most recognizable AI writing tell. Claude uses em-dashes (-- in markdown, rendered as long dashes) to connect clauses instead of using periods, semicolons, or colons. Human writers use em-dashes occasionally. Claude uses them in nearly every paragraph.

Without the rule (Claude's default):

Wire detects overlapping pages through GSC analysis and resolves them -- merge the weaker page or differentiate both. The audit runs locally -- no API calls needed -- and produces a full report in under a second.

Two em-dashes in two sentences. This reads as AI-generated to anyone familiar with the pattern.

With the styleguide rule:

No emdashes. Use periods, semicolons, colons, or commas instead.
Emdashes are a known AI writing pattern.

Output after the rule:

Wire detects overlapping pages through GSC analysis and resolves them: merge the weaker page or differentiate both. The audit runs locally with no API calls and produces a full report in under a second.

Same information, no em-dashes. The colon introduces the list naturally. The parenthetical becomes a simple clause.

Other Common AI Tells

The banned words list and the em-dash rule together eliminate most AI tells. Test with --dry-run after adding them. If Claude's output still reads as AI-generated, look for patterns in the preview and add specific rules.

Tone Spectrum

The same content, explaining a brake pad replacement, shifts dramatically with small styleguide changes. Here are five levels from formal to casual:

Two to three lines in the styleguide control which level Claude writes at. You do not need a long rulebook. You need the right two lines.

Section Structure Enforcement

Tell Claude exactly which sections every page must contain. This ensures consistent structure across hundreds of pages.

AutoFix service pages (docs/services/_create.md):

## Page Structure

Every service page MUST contain these sections in this exact order:

1. ## Das Problem -- What symptom the customer notices
2. ## Diagnose -- How we identify the root cause
3. ## Ablauf der Reparatur -- Step-by-step repair process
4. ## Kosten -- Price range with factors that affect cost
5. ## Wann sollten Sie kommen? -- Warning signs and timing advice

Do not add other H2 sections. Do not skip any section.
Do not reorder these sections.

CompareStack vendor pages (docs/vendors/_create.md):

## Page Structure

Every vendor profile MUST contain these sections in this exact order:

1. ## Overview -- What the vendor does, founding year, HQ, employee count
2. ## Key Features -- Top 5 features with evidence (benchmarks, case studies)
3. ## Pricing -- Published tiers or "contact for pricing" with context
4. ## Recent Updates -- Product changes in the last 12 months, with dates
5. ## Verdict -- Who should consider this vendor, and who should not

Do not add other H2 sections. Do not merge sections.

Claude follows explicit section lists reliably. Without them, Claude invents its own structure, and every page ends up different.

Source Requirements

Specifying which sources Claude should cite controls the credibility of the output.

AutoFix:

## Quellen

Für Sicherheitsaussagen: zitiere ADAC, TÜV, oder DEKRA mit Datum.
Für Kosten: nenne Preisspannen aus eigener Erfahrung, keine externen Quellen.
Für technische Daten: zitiere Herstellerangaben (Bosch, Continental, Brembo).

Without this rule, Claude cites random automotive blogs. With it, every safety claim links to ADAC or TÜV, sources German car owners already trust.

CompareStack:

## Sources

For market size claims: cite Gartner, Forrester, or IDC with publication date.
For feature claims: cite the vendor's own documentation or changelog.
For user sentiment: cite G2, Capterra, or TrustRadius with review count.
Never cite competitor marketing pages as neutral sources.

Source requirements serve two purposes: they make the content more trustworthy to readers, and they prevent Claude from hallucinating citations. When Claude knows it must cite Gartner specifically, it either finds a real Gartner data point or omits the claim entirely.

Testing Your Changes

Never deploy a styleguide change without testing it. The --dry-run flag writes output to a .preview file without changing the actual page.

Workflow:

# 1. Edit your styleguide
vim docs/_styleguide.md

# 2. Run one page with --dry-run
python -m wire.content refine services/bremsen --dry-run

# 3. Compare the preview to the current page
# Wire prints a diff automatically

# 4. If it looks right, run without --dry-run
python -m wire.content refine services/bremsen

Change one rule at a time. If you change five rules and the output is wrong, you cannot tell which rule caused the problem.

Topic-Level Overrides

AutoFix needs different voices for different sections. Blog posts use casual "Du-Form" to feel approachable. Service pages use professional "Sie-Form" to signal expertise. Same site, different rules.

File tree:

docs/
  _styleguide.md          # Site-wide rules (applies to everything)
  services/
    _create.md             # Override for service pages
    _refine.md             # Override for service page updates
    bremsen/index.md
    oelwechsel/index.md
  blog/
    _create.md             # Override for blog posts
    _refine.md             # Override for blog post updates
    winterreifen/index.md
  standorte/
    muenchen/index.md      # Uses site-wide rules (no override)

docs/services/_create.md (professional):

Schreiben Sie in der Sie-Form.
Jede Seite braucht mindestens eine Quelle (ADAC, TÜV, oder Hersteller).
Fachbegriffe immer erklären.

docs/blog/_create.md (casual):

Schreib in der Du-Form.
Lockerer Ton, kurze Sätze.
Keine Quellenangaben nötig -- das ist ein Blog, kein Gutachten.

Wire checks for docs/{topic}/_{action}.md before falling back to the built-in prompt. If the file exists, it replaces the default entirely. The site-wide styleguide is still prepended, so your banned words and role definition apply everywhere, but the section structure and tone come from the topic override.

Real Styleguide Evolution

Most styleguides go through three drafts. The first draft captures the customer's instinct. The second fixes what Claude misinterprets. The third removes what turned out to be unnecessary. Here are five examples from different industries, each showing the actual progression.

A physiotherapy practice (German, 40 pages)

Draft 1 — what the owner wrote:

Wir sind eine moderne Physiotherapie-Praxis in Freiburg.
Schreiben Sie professionell und vertrauenswürdig.
Unsere Schwerpunkte sind Rücken, Schulter und Knie.

What went wrong: Claude produced generic medical content that could have come from any practice. Every page opened with "Als moderne Physiotherapie-Praxis bieten wir..." The word "modern" appeared 47 times across 40 pages. No personality, no specific methodology.

Draft 2 — after reviewing 3 pages:

## Rolle
Du bist ein erfahrener Physiotherapeut, der Patienten erklärt,
warum etwas wehtut und was sie selbst tun können.
Schreib, als würdest du einem Patienten auf der Liege erklären,
was sein Problem ist.

## Verbotene Wörter
modern, ganzheitlich, individuell, kompetent, langjährig,
auf höchstem Niveau, State of the Art

## Stimme
Du-Form. Kurze Sätze. Erkläre Anatomie mit Alltagsvergleichen,
nicht mit Fachlatein. "Dein Meniskus funktioniert wie ein
Stoßdämpfer" statt "Der Meniscus lateralis fungiert als
Puffer im Kniegelenk."

What changed: Pages started opening with the patient's symptom, not the practice's credentials. "Deine Schulter schmerzt nachts? Das liegt meistens daran, dass..." instead of "Unsere Praxis bietet professionelle Schulterbehandlungen." The banned word list killed the filler, and the analogy instruction forced Claude to explain clearly.

Draft 3 — after running the full site: Removed the line about Rücken/Schulter/Knie. Claude already knew the topics from the page slugs. Added one line: "Jede Seite endet mit einer konkreten Übung, die der Patient zuhause machen kann." This single addition made every page immediately more useful than competitors.

A tax advisory firm (German, 60 pages)

Draft 1:

Wir sind eine Steuerberatungskanzlei in Hamburg.
Unsere Mandanten sind KMU und Freiberufler.
Schreiben Sie fachlich korrekt und verständlich.

What went wrong: Claude wrote like a textbook. Technically correct but unreadable. Sentences averaged 35 words. Every page explained tax law from first principles instead of answering the question the client actually asked.

Draft 2:

## Rolle
Du bist ein Steuerberater, der seinem Mandanten am Telefon
erklärt, was er tun muss. Der Mandant hat keine Lust auf
Paragraphen. Er will wissen: Was muss ich tun? Was kostet es?
Bis wann?

## Struktur
Jede Seite beantwortet genau EINE Frage, die Mandanten
mindestens einmal pro Monat stellen. Der erste Absatz
beantwortet die Frage direkt. Dann kommt das "Warum".
Dann kommen die Ausnahmen.

## Quellen
Zitiere BMF-Schreiben oder BFH-Urteile mit Aktenzeichen.
Keine Steuertipps-Blogs. Keine Wikipedia.

## Verboten
Grundsätzlich, im Rahmen von, in Bezug auf, diesbezüglich,
es sei darauf hingewiesen, nicht unerheblich

What changed: Pages flipped from "Gemäß §4 Nr. 11 UStG sind Versicherungsumsätze grundsätzlich steuerfrei..." to "Dein Versicherungsumsatz ist steuerfrei. Punkt. Die Details stehen im §4 Nr. 11 UStG, aber hier ist, was das für deine nächste Voranmeldung bedeutet." The banned bureaucratic phrases forced Claude to write like a person.

Draft 3: Added "Nenne immer die aktuelle Frist mit Datum. Nicht 'zeitnah' oder 'demnächst'." This eliminated vague time references and made every page actionable.

A SaaS comparison site (English, 200 pages)

Draft 1:

We compare enterprise software products.
Write objectively. Include pricing and features.
Target audience: CTOs and IT decision makers.

What went wrong: Claude wrote marketing copy disguised as comparison. Vendor pages read like press releases. "Acme offers a powerful suite of enterprise-grade tools" appeared in various forms on every page. No actual data, no criticism, no useful differentiation.

Draft 2:

## Role
You are a senior analyst who has personally tested every product
you write about. You have no vendor relationships. You owe
nobody a favorable review. Your reader is spending $50K+ and
needs the truth, not marketing.

## Rules
- Every feature claim needs a source: vendor docs, changelog, or
  independent benchmark. No unsourced superlatives.
- Include at least one concrete weakness per vendor. A page without
  criticism is a press release, not a review.
- Pricing: published tiers with dates. If pricing is hidden,
  say "contact for pricing" and explain what this usually means
  (enterprise-only, negotiated, minimum commitment).
- Never use: best-in-class, industry-leading, seamless, robust,
  cutting-edge, next-generation, end-to-end, turnkey

## Structure
Overview → Features (top 5 with evidence) → Pricing →
Recent Changes (last 12 months, with dates) → Verdict
(who should buy, who should not)

What changed: Pages became genuinely useful. Vendor weaknesses appeared naturally: "Acme's OCR accuracy drops to 71% on handwritten forms (internal benchmark, Acme docs v3.2). If handwriting is your primary use case, evaluate Rossum or Textract first." The "no vendor relationships" framing made Claude write as a skeptic, not a promoter.

Draft 3: Added "Dont overwrite, integrate. When new information arrives, add it to the relevant section with a date. Never delete older information unless it is factually superseded." This prevented refine passes from replacing old benchmarks with newer but less detailed data.

A B2B marketing agency (German, 70 pages)

Draft 1:

Wise Relations ist eine B2B-Marketing-Agentur.
Wir schreiben über SEO, KI im Marketing und Content-Strategie.
Der Ton ist kompetent und auf Augenhöhe.

What went wrong: "Kompetent und auf Augenhöhe" is too vague. Claude interpreted it differently on every page. Some pages read like academic papers. Others read like LinkedIn posts. The inconsistency across 70 pages was worse than any single tone would have been.

Draft 2:

## Rolle
Du bist ein erfahrener B2B-Marketingberater, der Geschäftsführern
erklärt, warum ihre aktuelle Strategie Geld verbrennt und
was stattdessen funktioniert. Du bist direkt, nicht arrogant.
Du zeigst Zahlen, nicht Meinungen.

## Stimme
Sie-Form. Keine Ausrufezeichen. Keine rhetorischen Fragen
im Fließtext (nur in Überschriften erlaubt).

## Verboten
ganzheitlich, Synergien, Mehrwert, auf Augenhöhe,
360-Grad, Full-Service, maßgeschneidert, Leidenschaft

## Daten
Jeder Artikel enthält mindestens eine konkrete Zahl:
Kosten, Conversion Rates, Zeitaufwand, ROI.
Keine Zahl = kein Artikel.

## Quellen
Zitiere Studien von HubSpot, Semrush, Ahrefs oder
Branchenverbänden. Keine eigenen Studien erfinden.

What changed: The banned word list killed the agency jargon that made every page sound the same. The mandatory data point rule forced substance. Pages shifted from "Content-Marketing ist ein ganzheitlicher Ansatz" to "Ein B2B-Blogartikel kostet im Schnitt 350-500 Euro bei einer Agentur (HubSpot, 2025). Wire produziert den gleichen Artikel für 0,06 Euro."

Draft 3: Added visual component rules — "Nutze Stat-Boxen für einzelne Kennzahlen. Nutze Vergleichstabellen statt Fließtext, wenn mehr als 3 Optionen verglichen werden." This made pages scannable without changing the writing itself.

A consulting firm with two sites (German, 200 pages)

Draft 1:

Helm & Nagel berät Unternehmen zur KI-Strategie.
Professioneller Ton, C-Level-Publikum.

What went wrong: Two problems. First, the firm also runs a separate product site (Konfuzio). Without explicit boundaries, Claude mentioned Konfuzio on consulting pages, blurring the line between independent advice and product promotion. Second, "C-Level" alone produced jargon-heavy pages that even the CEO found unreadable.

Draft 2:

## Rolle
Du bist ein Management-Berater, der Vorständen erklärt,
wo KI ihrem Unternehmen konkret Geld spart. Nicht theoretisch.
Nicht visionär. Konkrete Prozesse, konkrete Einsparungen.

## Wichtig
Erwähne NIEMALS Konfuzio, Produkte der Helm & Nagel GmbH,
oder eigene Software auf diesen Seiten. Dies ist eine
unabhängige Beratungsseite. Jede Produkterwähnung zerstört
die Glaubwürdigkeit.

## Struktur
Jeder Artikel enthält mindestens einen KPI oder ROI-Wert.
"KI in der Buchhaltung spart 12 Stunden pro Woche bei
einem mittelständischen Unternehmen" statt
"KI optimiert Buchhaltungsprozesse."

## Internes Verlinken
5 Themensilos. Verlinke primär innerhalb des Silos.
Cross-Silo-Links nur wenn thematisch zwingend.

What changed: The explicit "never mention Konfuzio" rule solved the product-promotion bleed immediately. The KPI requirement transformed pages from thought leadership fluff into actionable business cases. Cross-linking rules prevented the site from becoming an interlinked mess where every page linked to every other page.

Draft 3: Added "Wenn du eine KI-Anwendung beschreibst, nenne immer die Voraussetzungen: Datenmenge, Datenqualität, IT-Infrastruktur. Keine KI-Empfehlung ohne Kontext." This prevented the common consulting-site problem of overselling AI capabilities.

The Pattern

Every styleguide follows the same evolution:

1. Draft 1 starts with who the company is. This produces generic content because Claude already knows how to write about the industry. What it doesn't know is how THIS company talks about it.

2. Draft 2 fixes the voice by adding a role, banned words, and structure. This is the highest-impact rewrite. Most styleguides stabilize here.

3. Draft 3 adds one or two rules discovered by reading the output. These are always specific: "end with an exercise," "always include a deadline date," "never mention the sister product." You cannot predict these rules in advance. They emerge from seeing what Claude gets wrong.

A good styleguide is 200-400 words. If yours is longer, you are probably writing rules that duplicate what the built-in prompts already enforce.

Common Mistakes

Styleguide longer than the content it governs. A 2,000-word styleguide for pages that average 500 words means Claude spends more tokens reading rules than writing content. Keep your styleguide under 500 words. Move topic-specific rules to topic overrides.

Rules that conflict with each other. "Write short paragraphs (2-3 sentences)" combined with "Include comprehensive technical details for every feature" creates an impossible constraint. Claude compromises by writing medium paragraphs with medium detail. Exactly what nobody wanted. Pick one priority per section.

Not testing with --dry-run. A single misplaced rule can shift the tone of every page on the site. Always run --dry-run on one page before committing a styleguide change. The diff output shows exactly what changed and why.

Ignoring topic overrides when topics need different voices. If your blog and your product pages sound the same, readers cannot tell them apart. Use topic-level _{action}.md files to set distinct voices. The styleguide handles shared rules (banned words, source requirements). The topic override handles voice and structure.

Writing rules as suggestions instead of commands. "Try to avoid passive voice" gives Claude an escape hatch. "Never use passive voice in headings" does not. Claude treats "try to" as optional. State rules as absolutes.