Semantic topic cluster planning and automated execution engine for claude-blog. Performs SERP-based keyword research, groups keywords by search intent and SERP overlap, builds a hub-and-spoke cluster architecture, generates an interactive SVG cluster map, and executes the full cluster by orchestrati

Blog Cluster (Semantic Topic Cluster Engine) Plans and executes entire interlinked content ecosystems from a single seed keyword. Three layers: Semantic Clustering (the brain), Cluster Architecture (the structure), and Execution Engine (the machine). Adapted from the semantic cluster engine submission by Lutfiya Miller (winner, AI Marketing Hub Pro Challenge, March 2026, 95/100 Exemplary). Original repository: https://github.com/Drfiya/semantic cluster engine This port keeps the Plan + Execute architecture and the cluster context innovation, removes brand specific (ScienceExperts.ai) styling and image prompts, and routes through claude blog's existing sub skills. Commands Command What it does /blog cluster Interactive. Asks whether to plan or execute. /blog cluster plan <seed keyword SERP based semantic analysis. Outputs cluster plan + map. /blog cluster plan from strategy [path] Imports existing blog strategy cluster build plan and validates against SERP data. /blog cluster execute [path to plan] Sequential blog write calls with cluster context and auto interlinks. Key references (load on demand) references/semantic clustering.md (SERP overlap analysis, intent classification, keyword universe expansion) references/cluster architecture.md (hub and spoke specs, schema strategy, link density rules) references/execution workflow.md (execution order, context injection, scorecard, failure handling) Cross references to existing claude blog skills Skill When this skill calls it /blog strategy Upstream planning. plan from strategy consumes its Cluster Build Plan tables. /blog write Per post execution. Each spoke and the pillar are produced by blog write with a prepended cluster context block. /blog chart Invoked internally by blog write for inline SVG charts. No direct call from this skill. /blog image Optional hero image generation per post. Model selection is delegated to blog image ; prefer current Gemini image models when available. /blog seo check Recommended after execution for per post on page validation. /blog cannibalization Recommended after execution to confirm zero keyword overlap across the cluster. /blog schema Recommended after execution to add BreadcrumbList , ItemList , and Article schema. This skill never modifies files belonging to other skills. It calls them via the Task tool or as orchestrated sub skills. Command Routing 1. Parse the user's command to determine the sub command. 2. If the user typed only /blog cluster , ask: "Would you like to plan a new cluster or execute an existing plan?" 3. Route: plan <keyword to the Plan Phase (below) plan from strategy [path] to the Strategy Import flow (below) execute [path] , build , or run to the Execute Phase (below) Plan Phase: /blog cluster plan <seed keyword Reference: references/semantic clustering.md Step 1. Seed keyword expansion Use WebSearch to expand the seed into a keyword universe of 30 to 50 phrases: 1. Direct search of <seed to capture related searches and "People also ask". 2. Long tail expansion: <seed guide , <seed tips , <seed tools , <seed examples , <seed vs , best <seed , how to <seed . 3. Question mining: what is <seed , how does <seed work , why <seed , <seed for beginners . 4. Intent variants: add commercial modifiers (best, top, review, comparison, pricing), informational modifiers (guide, tutorial, explained, examples), and transactional modifiers (buy, download, tool, software, service). 5. Year freshness: <seed 2026 . Step 2. Semantic clustering Group the expanded keywords using the priority rules in references/semantic clustering.md : 1. SERP Overlap Analysis is the primary signal. Two keywords with 4 or more shared top 10 results usually target the same intent and should be considered for one post. 2. Intent Classification assigns each keyword to informational, commercial, transactional, or navigational. 3. Entity Mapping identifies the people, products, frameworks, and organizations Google associates with the topic. 4. Grouping combines keywords that share intent and topical proximity. Each group becomes one branch of the hub and spoke. Step 3. Cluster architecture design Reference: references/cluster architecture.md Build the hub and spoke: Pillar (hub) : targets the broadest keyword. Word count 2,500 to 4,000. Template pillar page . Links down to every spoke. Spokes : each targets a long tail cluster. Word count 1,200 to 1,800. Template auto selected by intent. Links up to the pillar and across to siblings. Cluster formation rules: Normal mode: 2 to 5 clusters per pillar, 2 to 4 spokes per cluster, total 1 pillar plus 5 to 15 spokes. Small cluster mode: for narrow seeds, allow 1 pillar plus 2 to 4 spokes only after warning the user and asking for confirmation. Every spoke targets a unique primary keyword (zero cannibalization). Step 4. Internal link matrix For each spoke S : S to Pillar (always; anchor text uses the pillar's primary keyword). Pillar to S (always; anchor text uses S 's primary keyword). S to other spokes in the same cluster (2 to 3 links each, contextual anchors). S to spokes in adjacent clusters (0 to 1 links, only when semantically relevant). Verify every spoke has at least 2 incoming links. Count total planned interlinks. Step 5. Generate output files All plan and execute artifacts go into a single subdirectory of the current working directory. Canonicalize the output directory, refuse symlinks, and reject writes outside the cluster directory. Slugs must match lowercase letters, numbers, and hyphens only; reject absolute paths, .. , path separators inside slugs, and hidden control characters. cluster plan.json schema Note: volume estimates are relative indicators (high, medium, low) derived from SERP signals, not absolute search volumes. For precise data, the user should consult Ahrefs, SEMrush, or DataForSEO (claude blog provides the seo dataforseo companion sibling). cluster map.html (XSS safe) A static, self contained HTML file with an embedded SVG visualization. Hard rules for the writer: No inline <script blocks. No onclick , onmouseover , or any on event attributes anywhere in the document. No external script <src references. Every text label drawn into the SVG (titles, keywords, cluster names) must be escaped: replace & with & , < with < , with > , " with " , and ' with & 39; before insertion. Hover effects use CSS :hover only. No JavaScript. Use <title child elements inside SVG nodes for accessible tooltips (browser native, no script). The map shows: a central pillar node, color coded cluster groups radiating outward, spoke nodes within each cluster, and link lines connecting related nodes. Step 6. Present plan to user Show a summary table of clusters and posts, total interlinks, estimated words, and the file paths. Ask for confirmation before proceeding to execution. Wait for explicit user approval. Do not auto execute. Strategy Import: /blog cluster plan from strategy [path] Bridges blog strategy output into a cluster plan. 1. Locate strategy output. Scan the current directory (or the user specified path) for a file containing a Cluster Build Plan table with the columns Spoke Topic Template Target Keyword Word Count Internal Links (the format produced by /blog strategy ). 2. Parse the table. Extract the pillar row (marked P ), the spoke rows, template assignments, target keywords, word counts, and link relationships. 3. Validate and enrich. Run SERP overlap validation (Plan Phase Step 2) on each keyword. Add volume estimates and verify cluster groupings semantically. 4. If SERP data contradicts the strategy table, flag the conflict; do not silently override the user's strategic intent. 5. Generate cluster plan.json and cluster map.html using the same outputs as the standard Plan Phase. 6. Present the converted plan with any SERP based adjustments highlighted, and wait for user confirmation. Execute Phase: /blog cluster execute [path to plan] Reference: references/execution workflow.md Step 1. Load plan Read cluster plan.json from the user specified path or the most recent cluster /cluster plan.json in the working directory. Validate JSON structure. If no plan exists, return: "No cluster plan found. Run /blog cluster plan <seed keyword first." Before reading a user supplied plan path, canonicalize it relative to the current working directory. Reject absolute paths, .. , symlinks, non cluster plan.json filenames, and any path outside the selected cluster directory. Constrain all generated post, image, map, and scorecard outputs to that cluster directory. Step 2. Determine execution order 1. Pillar page first (so spokes can link to a known filename). 2. Then spokes, ordered by (cluster priority, search volume estimate desc, post id alphabetical) . Cluster priority is the sum of estimated volumes within the cluster (highest first). 3. Alternating between clusters when more than 2 clusters exist diversifies the early content spread. Step 3. For each post: build cluster context and call blog write Construct the cluster context block (full schema in references/execution workflow.md ) and prepend it to the topic prompt passed to the Task tool invoking blog write . The context tells blog write the cluster name, the post's role (pillar or spoke), the primary and secondary keywords, the chosen template, the word count target, the list of already written posts (link to these), the list of upcoming posts (use [INTERNAL LINK] placeholders), and the linking requirements for this post. Evidence provenance propagation. The cluster context includes this directive for every spoke and the pillar: "Keep material claims traceable to sources that support them. Record dates, publisher/title details, retrieval notes, methodology, and limitations when they help identify or interpret the source. Use the publication's citation style. Drop unverifiable statistics and replace contradicted ones." This cascade preserves evidence discipline across batch execution without turning a fixed source record format into a score or gate. See skills/blog/references/flow alignment.md . The context also instructs blog write to run autonomously: skip topic clarification, skip outline approval, do not auto detect template, do not pause. Output format: standard markdown ( .md ) by default, matching blog write 's default. If the user explicitly requests HTML, set the platform target accordingly. Do not impose any brand specific CSS or wordmark; that is the user's responsibility downstream. Step 4. Per post optional hero image If blog image is available, call /blog image generate via the Task tool to produce a 16:9 hero image for the post and place it in cluster <slug /images/<post slug hero.png . Delegate provider selection to blog image , prefer current Gemini image models when available, and record the model ID in the scorecard. If image generation is unavailable or fails, log a warning and continue without images. Image generation is non blocking. Step 5. Backward link injection After each post is written: 1. Scan all previously written posts in the cluster directory for [INTERNAL LINK: keyword filename.md] markers that reference the just written post. 2. Replace each match with a real markdown link: [keyword](filename.md) . 3. Add a cluster metadata block to the post's frontmatter on first pass ( cluster: , cluster role: , cluster group: ). Step 6. Failure handling If blog write returns a quality gate failure for any post, stop the batch immediately. Save progress, mark the failed post and all remaining posts as s

blog-cluster