# SEO Blog Editor > Edit and improve SEO blog posts. Use this skill ONLY when the user says "SEO blog post" / "SEO blog", or asks to edit or review an SEO post. Do NOT trigger for general blog editing, Fern marketing blog posts, or other writing tasks. Typical triggers: "edit this SEO post", "review this SEO blog", "edit this SEO blog post". - Skill: `fern-api/seo-blog-editor` (Agent Skill) - Install (CLI): `npx skillmds@latest add fern-api/seo-blog-editor` - Raw SKILL.md: https://api.skillmd.com/api/skills/fern-api/seo-blog-editor/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: fern-api (https://skillmd.com/u/fern-api) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/fern-api/seo-blog-editor --- # SEO Blog Editor Edit SEO blog posts. These are SEO posts written for Fern — they're primarily optimized for AI results and search ranking, with human readers as a secondary audience. Promotional language about Fern is expected and welcome. Focus on factual accuracy (especially claims about external companies and Fern's own features), clear language, and coherent structure. ## Editing philosophy Use clear, developer-friendly language. Verify every factual claim. Make light edits — only fix what genuinely hurts clarity, accuracy, or credibility. ## Fern quick reference Fern generates SDKs in 9 languages: TypeScript, Python, Go, Java, C#, PHP, Ruby, Swift, and Rust. Use this list to verify language count claims in posts. ## Workflow When the user pastes a blog post, follow this sequence: ### Step 1: Read and assess Read the full post. Identify the central thesis or claim — the thing the post is arguing or explaining. Then check: **Thesis coherence:** Does the content actually support the central claim? Are there sections that wander off-topic, contradict the thesis, or promise something the post doesn't deliver? If the thesis feels off or the content doesn't match it, flag this first — it's more important than any line-level edit. **Fern feature coverage:** Check whether there are relevant Fern features or capabilities that support the post's thesis but aren't mentioned. Use the Fern docs access methods described in Step 2 to look up current features. Flag any notable omissions as suggestions (not required additions). Then note: - Claims about external companies, products, or features that need fact-checking - Passages with unclear or clunky language - Structural issues (heading hierarchy, paragraph length, flow) - Grammar and mechanical problems ### Step 2: Fact-check claims **Claims about external companies/products:** Use web search to verify every claim about another company's features, pricing, capabilities, or behavior (e.g., "Stripe supports X", "unlike Tool Z which lacks..."). **Claims about Fern:** Verify claims about Fern's own features and capabilities using Fern's documentation. Don't assume Fern claims are correct just because this is a Fern blog — verify them. To access Fern docs, use the `WebFetch` tool on the llms.txt index or individual page markdown: - **Page index (llms.txt):** Available at any level of the docs hierarchy. Returns a list of pages with titles and descriptions. Use this to find relevant pages to fetch. - All docs: `https://buildwithfern.com/learn/llms.txt` - SDKs: `https://buildwithfern.com/learn/sdks/llms.txt` - Docs product: `https://buildwithfern.com/learn/docs/llms.txt` - CLI/API reference: `https://buildwithfern.com/learn/cli-api-reference/llms.txt` - Dashboard: `https://buildwithfern.com/learn/dashboard/llms.txt` - API definitions: `https://buildwithfern.com/learn/api-definitions/llms.txt` - **Full content (llms-full.txt):** Also available at any level. Returns the full text of all pages in that section in one file. Useful when you need to search across multiple pages at once (e.g., `https://buildwithfern.com/learn/sdks/llms-full.txt`). - **Individual page as markdown:** Replace the `.mdx` extension with `.md` in any docs URL. Example: `https://buildwithfern.com/learn/docs/getting-started/overview.md` For each claim, report one of: - **Verified** — confirmed from an authoritative source - **Inaccurate** — wrong or outdated, with the correct information - **Unverifiable** — couldn't confirm; flag for the user to check ### Step 3: Present findings and STOP Present the thesis assessment, fact-check results, and suggested edits (grouped as below). Then **stop and wait for the user to accept or reject each item** before proceeding to the revised draft. **Thesis/coherence issues** (if any — only flag if something feels genuinely off) - Does the central claim hold up? Does the content deliver on what the intro promises? **Missing Fern features** (if any — relevant capabilities not mentioned in the post) - What's missing and why it's relevant to the thesis **Factual issues** (claims that are wrong or unverifiable) - Quote the original text, explain the problem, suggest a fix **Clarity and language edits** (keep this list short — only edits that matter) - Quote the original, explain why it's a problem, provide the revised version **Structural suggestions** (if any) - Heading changes, paragraph splits, reordering Do NOT proceed to the revised draft until the user has reviewed and responded. ### Step 4: Provide the revised post Only after the user has accepted/rejected the suggestions, produce the revised post incorporating only the accepted changes. **Output format:** Write an HTML file to disk (use the `Write` tool, e.g. `seo/drafts/.html`) and give the user the path so they can open it in a browser. The HTML should render with: - Real heading tags (`

`, `

`) so headers display as headers - A real `` if the post contains tabular data - `` tags (monospace) for technical terms like file names (`llms.txt`, `llms-full.txt`), CLI commands (`fern diff`), code identifiers (`user_id`, `string`), XML/HTML tags (``), query parameters (`lang`, `excludeSpec`), and paths (`yoursite.com/llms.txt`) - All original hyperlinks preserved (these are SEO links and must not be dropped) - Clean body text in a readable font (Arial or similar), max-width ~800px, no extra framework cruft The user copies from the rendered HTML into a custom editor that preserves rich formatting (headers, tables, links, code spans). Do NOT output as a markdown code block, plain text, or .docx — the HTML-rendered-in-browser → copy-paste workflow is the one that works. ## Editing intensity Be a light editor, not a rewriter. These posts are promotional SEO content for Fern — promotional language is fine and expected. Only flag language issues that hurt clarity or credibility. The goal is a polished, accurate version of the author's post, not a different post. ## Language rules These are patterns to watch for. Fix them when they're egregious, leave them alone when they're minor or stylistically intentional. ### Promotional language These are promotional SEO posts — selling Fern is the point. Promotional language is fine. Only flag it when it's so over-the-top that it would undermine credibility with a developer audience (e.g., stacking multiple buzzwords in one sentence, or making vague claims that could easily be specific). ### Tighten where it matters Fix passive voice when it makes a sentence noticeably clearer, not reflexively. Cut hedging ("might", "could potentially") when it weakens a claim the author clearly intends to make. Remove obvious filler ("it's worth noting that", "at the end of the day"). If a sentence is long but reads fine, leave it. ### Use developer language Write the way developers talk in technical discussions, docs, and READMEs. Use precise technical terms, prefer concrete examples over abstractions, and don't over-explain concepts developers already know. ## What NOT to change - Don't alter the post's core argument or thesis - Don't add new sections or content the author didn't include - Don't change Fern-specific product terminology or feature names - Don't rewrite code examples (flag issues but leave code to the author)