← ClaudeAtlas

blog-postlisted

Create an SEO blog post from a primary keyword on a CMS-backed site. Runs end-to-end autonomously by default (no in-process gates): keyword intake → SERP data pull → competitor page scrape → gap analysis → outline → draft → image generation → publish → comprehensive end-of-run self-audit. Auto-fixes known failure modes (zero counts, em-dashes in structured fields, source URL rot, keyword density drift) without prompting the user. Escalates only what genuinely needs human judgement (cannibalization >30% with adjacent post, factual claim that can't be sourced). Opt-in gates via --review-outline / --review-images / --review flags. Loads a per-site pipeline config for shortcodes, author, paths, taxonomy, geography, currency, editorial rules. Enforces forbidden-words ban + zero em-dashes across EVERY authored field (body, title, excerpt, structured-field rows, meta) + keyword-density rules (primary 1-2% for entity articles, never 2x per paragraph; each secondary 1-3x distributed across H2s, never >5x). Supports ba
donatassimkus/claude-ai-skills · ★ 1 · AI & Automation · score 77
Install: claude install-skill donatassimkus/claude-ai-skills
# /blog-post skill Create an SEO blog post from a primary keyword on a project's CMS-backed site. Generic pipeline — all project-specific detail (site URL, deploy/access method, author, shortcode library, currency, geography, category IDs, banned entity-mention rules) lives in a per-project `blog-pipeline-config.md` file. Invoke as `/blog-post <site> <topic-or-keyword>` (singular). The first argument is the SITE (slug, domain, or natural-language name); the rest is the topic or primary keyword. The same engine is also called per-keyword by a BATCH RUNNER (an unattended multi-post run over a keyword queue) in batch posture. **Platform scope (read this before Phases 7-9).** Phases 1-6 (keyword intel, competitor scrape, gap analysis, planner, draft, pre-publish audit) are platform-agnostic and correct on ANY stack. Phases 7-9 are written in the concrete idiom of a **self-hosted WordPress site driven over a command-line interface**, because that is where the publish mechanics (media import, structured fields, meta keys, taxonomy assignment, cache flush) are specific enough to be worth stating exactly. A static-site branch is given further down. On any OTHER CMS (a headless CMS, a hosted blog platform, a different self-hosted CMS, a git-backed site), the RULES in Phases 7-9 all still hold — substitute your platform's equivalent for each mechanism and keep the rule: its media upload API for the media import, its structured/custom fields for the repeater fields, its SEO plugin or