guest-contributor-article（客座撰稿人文章）

Guest Contributor Article

Ghostwrite an SEO article in a guest contributor's authentic voice. We do 80% of the work, they get the byline and a plug for their platform.

Core principle: Every claim, recommendation, and story in the article must trace to something the contributor actually said or published. If you can't source it, flag it or cut it.

When to Use This Skill

• Writing an article for the OpenEd blog under a guest contributor's byline
• The contributor has agreed (or is being pitched) to lend their name
• You have access to their source material (blog, podcast, articles, talks)

Prerequisite skills loaded automatically:

• ghostwriter - AI pattern detection, voice transformation
• quality-loop - 5-judge quality gates

The Anti-Hallucination Rule

This is the #1 risk in ghostwriting. The LLM will confidently fabricate:

• Book titles the contributor never recommended
• URLs that don't exist (Bookshop.org, Amazon links)
• Quotes they never said
• Statistics they never cited
• Programs or organizations they never mentioned

The fix: Every section of the outline must cite its source BEFORE drafting begins. If a claim has no source, it gets one of three treatments:

1. [VERIFIED] - Traced to a specific blog post, article, podcast, or talk
2. [INFERRED] - Reasonable inference from their body of work (flag for contributor review)
3. [PLACEHOLDER] - Marked with [NOTE FOR CONTRIBUTOR] in the draft

Never invent links. If you want to link a book title, use only:

• Links the contributor uses on their own site
• OpenEd internal links you've verified exist
• Leave the title unlinked if no verified URL exists

Phase 1: Contributor Brief

Create README.md in the contributor's folder.

Guest Contributors/[contributor-name]/
├── README.md              # This brief
├── sources/               # Their actual content
│   ├── articles/          # Blog posts, written pieces
│   ├── podcasts/          # Transcripts
│   └── youtube-transcripts/
├── seo-research/          # Content briefs from /seo-research
├── drafts/                # Article versions
└── images/                # Thumbnails, infographics

README.md must include:

Phase 2: Source Gathering

Collect 3-5 pieces of their actual content. Read them. This is not optional.

Priority order:

1. OpenEd podcast appearance (if they were a guest)
2. Their blog / newsletter (primary voice source)
3. Other podcast appearances or talks
4. Social media posts (LinkedIn, X)
5. Books or courses (note key chapters/sections)

What to extract from each source:

• Direct quotes worth preserving
• Personal stories and anecdotes (with source citation)
• Frameworks or terminology they invented (these are their fingerprints)
• Data points or statistics they cite
• Specific recommendations (books, tools, programs) - note the EXACT source where they recommended each one
• Tone markers: sentence length, humor style, how they use "I", capitalization habits, rhetorical patterns

Save source material to sources/ folder with clear attribution.

Phase 3: SEO Topic Selection

Run /seo-research with their expertise area.

Criteria:

• Volume: 500+/month (flexible for niche topics with high CPC)
• Competition: < 0.5
• Their expertise genuinely maps to the keyword
• OpenEd doesn't already own this keyword
• SERP gap: no practitioner/personal voice content ranking

Output: Content brief saved to seo-research/ folder.

Phase 4: Voice Analysis

Study their writing and document patterns in the README under "Voice Notes for Drafting."

Document these specifically:

Phase 5: Source-Mapped Outline

Create the article outline with every section mapped to its source. This is the anti-hallucination gate.

Format:

## [H2 Title] (~word count)

**What goes here:** [Description]
**Sources:**
- Personal story about X → from [blog post URL] / [podcast timestamp]
- Statistic about Y → from [their article title, date]
- Book recommendations → from [specific blog post where they listed these]

**Voice note:** [How this section should sound based on voice analysis]

Before drafting, verify:

• Every personal story traces to something they've told publicly
• Every recommendation traces to their content (not your knowledge)
• Every statistic traces to something they've cited
• Sections where you're inferring are marked [INFERRED]
• The OpenEd plug feels natural, not grafted on

Phase 6: Draft

Structure Template

---
title: "[Title]"
author: [Contributor Name]
byline: "[One-sentence bio with company and credentials]"
status: draft-v1
primary_keyword: [keyword]
secondary_keywords: [list]
slug: [url-slug]
date: [YYYY-MM-DD]
sources: "[list of source material used]"
---

# [Title]

*[Contributor Name] is [credentials]. They [what they're known for].
[Link to their platform]. [Link to their OpenEd podcast appearance if applicable].*

[Article body]

Drafting Rules

1. Write in their voice, not OpenEd's. Use their sentence patterns, their frameworks, their humor. The ghostwriter skill's "Charlie's Signature Moves" do NOT apply here - those are for Charlie's voice.
2. Italicized intro paragraph. Before the article body, one paragraph introducing who they are with links to their platform and OpenEd podcast appearance. This goes below the byline in the frontmatter.
3. OpenEd internal links. Weave in 3+ internal links to existing OpenEd content. These should feel like helpful references, not promotions.
4. Contributor platform plug. Include naturally - usually through their personal story leading into what they built. Don't make it an ad. The Janssen piece does this well: her daughter's reading struggle story naturally leads to why she started Savvy Learning.
5. [NOTE FOR CONTRIBUTOR] placeholders. When you want a personal anecdote but aren't sure they have one, or when you're inferring rather than sourcing, mark it clearly. Example: [NOTE FOR JANSSEN: Do you have a specific student/family story that illustrates this?]
6. No invented links. Do not create URLs. If you want to link book titles, either use the contributor's own links from their site or leave titles unlinked.
7. Word count. Target the SERP-recommended range from the content brief, typically 1,500-2,500 words.

Phase 7: Source Verification Report

Before sending to the contributor or publishing, create a verification table. Append to the draft file or save separately.

## Source Verification

| Claim / Recommendation | Source | Status |
|------------------------|--------|--------|
| "tested at 12th-grade reading level in kindergarten" | OpenEd podcast Dec 2025, 14:32 | VERIFIED |
| Dog Man recommendation | everyday-reading.com/books-like-dog-man | VERIFIED |
| The Wild Robot recommendation | everyday-reading.com/books-for-reluctant-readers | VERIFIED |
| "between 2,000 and 5,000 books" | 3 in 30 podcast, episode X | VERIFIED |
| All Thirteen feedback claim | [could not find specific post] | INFERRED |

Rules:

• Every book/tool/program recommendation must trace to the contributor's content
• Every personal story must trace to a public telling
• Every statistic must trace to a cited source
• INFERRED items get flagged for contributor review

Phase 8: Quality Gate

Run through quality-loop with one modification:

Modified Judge 2 (Accuracy Checker): In addition to standard accuracy checks, verify:

• All claims trace to the contributor's published content (not general knowledge)
• No hallucinated URLs
• No book/program recommendations the contributor hasn't made
• Contributor's bio details are accurate
• OpenEd internal links are valid (not 404s)

Modified Judge 3 (OpenEd Voice): The article should NOT sound like OpenEd's usual voice. It should sound like the contributor. Judge for:

• Voice matches contributor's documented patterns
• OpenEd strategic narrative woven in subtly (not imposed)
• The plug for their platform is natural

All other judges run as standard.

Phase 9: Delivery & Collaboration

If pitching (they haven't agreed yet):

• Send draft with pitch email (use Outreach Templates/Guest_Article_Pitch_Template.md)
• Frame as "we did the heavy lifting, you polish and approve"

If agreed (they said yes):

• Send draft for review
• Note what's sourced vs. what needs their input
• Invite them to add personal anecdotes at placeholder spots
• Make their edits, run quality loop again

Publication:

• Publish on OpenEd blog via Webflow API with full byline (see Webflow HTML Rules below)
• Create social assets via newsletter-to-social
• Send contributor share-ready posts with @handles

Webflow Rich Text HTML Rules

CRITICAL: Webflow's CMS rich text field silently drops or fails to render certain HTML. These rules are non-negotiable when pushing content via the API.

Never use <ul> or <li> tags

Webflow's rich text renderer strips list items pushed via API even when the API accepts and stores them. The content will appear in the CMS editor but will not render on the published page.

Instead: Convert all list items to <p> tags with <strong> for the lead-in.

# WRONG - will be silently stripped on render
<ul><li><strong>Dog Man</strong> (Dav Pilkey) - Description...</li></ul>

# RIGHT - always renders
<p><strong>Dog Man</strong> (Dav Pilkey) - Description...</p>

Image figures must use Webflow's class structure

<figure class="w-richtext-figure-type-image w-richtext-align-center"
  style="max-width:65%;margin:2em auto"
  data-rt-type="image" data-rt-align="center">
  <div><img src="[CDN_URL]" alt="[descriptive alt text]" loading="lazy"></div>
</figure>

• Use w-richtext-align-center for inline images (not floatleft/floatright which cause awkward text wrapping)
• Set max-width to control size (65% is a good default for infographics)
• Always include alt text and loading="lazy"

Safe HTML tags (confirmed working)

Tags to avoid

Markdown-to-Webflow conversion function

When converting markdown to Webflow HTML, use this pattern:

def markdown_to_webflow_html(md_text):
    """Convert markdown to Webflow-safe rich text HTML.

    Key rule: NO <ul>/<li> tags. All items become <p> tags.
    """
    # Strip YAML frontmatter
    md_text = re.sub(r'^---\n.*?\n---\n', '', md_text, flags=re.DOTALL)
    # Strip H1 (becomes CMS 'name' field)
    md_text = re.sub(r'^# .+\n', '', md_text, flags=re.MULTILINE)

    lines = md_text.strip().split('\n')
    html_parts = []

    for line in lines:
        stripped = line.strip()
        if not stripped:
            continue
        if stripped.startswith('### '):
            html_parts.append('<h3>%s</h3>' % inline_format(stripped[4:]))
        elif stripped.startswith('## '):
            html_parts.append('<h2>%s</h2>' % inline_format(stripped[3:]))
        elif stripped.startswith('- ') or stripped.startswith('* '):
            # List items become paragraphs
            html_parts.append('<p>%s</p>' % inline_format(stripped[2:]))
        else:
            html_parts.append('<p>%s</p>' % inline_format(stripped))

    return '\n'.join(html_parts)

Verification checklist (run after every API push)

• All book/product titles render on the page (not just in CMS editor)
• Images display centered at intended size
• Internal and external links are clickable
• No orphaned sections (headings without body text below them)
• Content on rendered page matches the source markdown

Skill Chain

Common Mistakes

*Created: 2026-02-05. Based on the Janssen Bradshaw and Mason Pashia contributor packages.*