需要从种子关键词规划并自动执行语义主题集群时，用…

从单个种子关键词规划并执行一组互相内链的博客文章（1 个 pillar + 多个 spokes）时使用。

适用场景

解决思路

1. 根据用户输入路由命令：解析子命令；若只有 `/blog cluster`，先询问是 plan 还是 execute。
2. 将 `plan <keyword>` 路由到 Plan Phase；将 `plan --from strategy [path]` 路由到 Strategy Import；将 `execute [path]`、`build` 或 `run` 路由到 Execute Phase。
3. Plan Phase 第1步：用 WebSearch 把种子关键词扩展成 30 到 50 个短语的关键词宇宙。
4. 直接搜索 `<seed>`，收集 related searches 和 People also ask。
5. 做长尾扩展：`<seed> guide`、`<seed> tips`、`<seed> tools`、`<seed> examples`、`<seed> vs`、`best <seed>`、`how to <seed>`。
6. 做问题挖掘：`what is <seed>`、`how does <seed> work`、`why <seed>`、`<seed> for beginners`。
7. 做意图变体：加入 commercial 修饰词（best、top、review、comparison、pricing）、informational 修饰词（guide、tutorial、explained、examples）、transactional 修饰词（buy、download、tool、software、service）。
8. 加入年份新鲜度：`<seed> 2026`。
9. Plan Phase 第2步：按优先级规则对扩展关键词做语义聚类。
10. 以 SERP Overlap Analysis 为主信号：两个关键词若共享 4 个及以上 top-10 结果，通常同一意图，考虑放进同一篇文章。
11. 做 Intent Classification：把每个关键词标为 informational、commercial、transactional 或 navigational。
12. 做 Entity Mapping：识别 Google 与该主题关联的人物、产品、框架和组织。
13. 做 Grouping：把共享意图和主题接近的关键词合并，每组成为一个 hub-and-spoke 分支。
14. Plan Phase 第3步：设计枢纽-辐条架构。
15. Pillar（hub）：定位最宽泛关键词，字数 2500 到 4000，模板 `pillar-page`，向下链接到每个 spoke。
16. Spokes：每个定位一个长尾集群，字数 1200 到 1800，模板按意图自动选择，向上链接 pillar 并横向链接同组兄弟。
17. 正常模式：每个 pillar 2 到 5 个 cluster，每个 cluster 2 到 4 个 spoke，总计 1 个 pillar 加 5 到 15 个 spoke。
18. 小集群模式：窄种子可允许 1 个 pillar 加 2 到 4 个 spoke，但必须先警告用户并请求确认。
19. 确保每个 spoke 定位唯一 primary keyword，零 cannibalization。
20. Plan Phase 第4步：建立内链矩阵。
21. 对每个 spoke S：S 到 Pillar 始终链接，锚文本用 pillar 的 primary keyword。
22. 对每个 spoke S：Pillar 到 S 始终链接，锚文本用 S 的 primary keyword。
23. 对每个 spoke S：S 链接到同 cluster 其他 spoke，每个 2 到 3 条，使用上下文锚文本。
24. 对每个 spoke S：S 链接到相邻 cluster 的 spoke，0 到 1 条，仅语义相关时添加。
25. 验证每个 spoke 至少有 2 条入站内链，并统计计划内链总数。
26. Plan Phase 第5步：生成输出文件到当前工作目录下的单个子目录 `cluster-<seed-keyword-slug>/`。
27. 规范化输出目录，拒绝 symlink，拒绝写入 cluster 目录之外。
28. Slug 只允许小写字母、数字和连字符；拒绝绝对路径、`..`、slug 中的路径分隔符和隐藏控制字符。
29. 生成 `cluster-plan.json`，包含 `seed_keyword`、`generated_at`、`pillar`、`clusters`、`total_posts`、`total_interlinks`、`estimated_total_words`。
30. 在 `cluster-plan.json` 中为 pillar 和每个 post 写入 title、primary_keyword、secondary_keywords、search_volume_estimate（high/medium/low 相对指标）、template、word_count_target、cluster/links_to/links_from 等字段。
31. 搜索量只作为 SERP 信号推导的相对指标；若需精确数据，提示用户使用 Ahrefs、SEMrush 或 DataForSEO（claude-blog 的 `seo-dataforseo` 伴随技能）。
32. 生成 `cluster-map.html`：静态自包含 HTML，内嵌 SVG 可视化。
33. 写 `cluster-map.html` 时禁止内联 `<script>`、任何 `on*` 事件属性、外部 script `<src>` 引用。
34. 写 `cluster-map.html` 时对进入 SVG 的每个文本标签做转义：`&` 转 `&amp;`，`<` 转 `&lt;`，`>` 转 `&gt;`，双引号转 `&quot;`，单引号转 `&#39;`。
35. `cluster-map.html` 的 hover 效果只用 CSS `:hover`，不用 JavaScript；用 SVG `<title>` 子元素提供可访问提示。
36. 地图展示中央 pillar 节点、按颜色区分的 cluster 组、每个 cluster 内的 spoke 节点，以及连接相关节点的连线。
37. Plan Phase 第6步：向用户展示 cluster 和 post 摘要表、总内链数、预估字数和文件路径。
38. 请求用户确认后再进入执行；等待明确批准；不要自动执行。
39. Strategy Import：定位 strategy 输出，扫描当前目录或用户指定路径，寻找包含 `Cluster Build Plan` 表格的文件，表头为 `# | Spoke Topic | Template | Target Keyword | Word Count | Internal Links`。
40. 解析该表：提取标记为 P 的 pillar 行、spoke 行、模板分配、目标关键词、字数和链接关系。
41. 验证并丰富：对每个关键词运行 SERP overlap validation（Plan Phase 第2步），添加搜索量估计并语义验证 cluster 分组。
42. 如果 SERP 数据与 strategy 表冲突，标出冲突；不要静默覆盖用户的战略意图。
43. 用与标准 Plan Phase 相同的方式生成 `cluster-plan.json` 和 `cluster-map.html`。
44. 展示转换后的计划，高亮任何基于 SERP 的调整，并等待用户确认。
45. Execute Phase 第1步：读取用户指定路径的 `cluster-plan.json`，或工作目录中最近的 `cluster-*/cluster-plan.json`；验证 JSON 结构。
46. 如果没有计划，返回：「No cluster plan found. Run `/blog cluster plan <seed-keyword>` first.」
47. 读取用户提供的计划路径前，先相对当前工作目录规范化；拒绝绝对路径、`..`、symlink、非 `cluster-plan.json` 文件名和所选 cluster 目录之外的路径。
48. 把所有生成的 post、image、map、scorecard 输出限制在该 cluster 目录内。
49. Execute Phase 第2步：确定执行顺序：先写 pillar，以便 spokes 链接到已知文件名。
50. 再写 spokes，顺序为 `(cluster priority, search_volume_estimate desc, post id alphabetical)`；cluster priority 是该 cluster 内估计搜索量之和，最高者优先。
51. 当 cluster 多于 2 个时，交替 cluster 执行，以分散早期内容分布。
52. Execute Phase 第3步：对每篇文章构造 cluster context block，并前置到传给 Task 工具调用 `blog-write` 的主题 prompt 中。
53. cluster context 要告诉 `blog-write`：cluster 名称、文章角色（pillar 或 spoke）、主要和次要关键词、所选模板、字数目标、已写文章列表（链接到这些）、待写文章列表（使用 `[INTERNAL-LINK]` 占位符）以及本文的链接要求。
54. 在 cluster context 中必须传播 FLOW evidence triple 指令：对每个公开统计量应用 FLOW evidence triple；正文中年份锚点（如「In 2026,」）、带 publisher 和 title 的行内引用、source block 中带 retrieval date 的 URL；删除不可验证统计量；替换被反驳的统计量。
55. 在 cluster context 中指示 `blog-write` 自主运行：跳过 topic clarification，跳过 outline approval，不自动检测模板，不暂停。
56. 默认输出标准 markdown（`.md`）；如果用户明确要求 HTML，则设置相应 platform target；不要强加任何品牌特定 CSS 或 wordmark。
57. Execute Phase 第4步：如果 `blog-image` 可用，通过 Task 工具调用 `/blog image generate` 为文章生成 16:9 hero image，放到 `cluster-<slug>/images/<post-slug>-hero.png`。
58. Hero image 的 provider 选择委托给 `blog-image`，优先当前 Gemini image models（如可用），并把模型 ID 记录到 scorecard。
59. 如果图像生成不可用或失败，记录 warning 并继续；图像生成非阻塞。
60. Execute Phase 第5步：每篇文章写完后做 backward link injection。
61. 扫描 cluster 目录中所有已写文章，查找引用刚写完文章的 `[INTERNAL-LINK: keyword -> filename.md]` 标记。
62. 把每个匹配替换为真实 markdown 链接：`[keyword](filename.md)`。
63. 首次通过时，在该文章 frontmatter 添加 cluster metadata block：`cluster:`、`cluster_role:`、`cluster_group:`。
64. Execute Phase 第6步：如果 `blog-write` 对任何文章返回 quality-gate failure，立即停止批量执行，保存进度，把失败文章和所有剩余文章标为 skipped，并告诉用户先手动检查或重试失败文章后再继续。
65. 不要在 quality failure 后继续生成 5 到 15 篇文章，以免造成 scaled-content-abuse 风险。
66. 如果 `blog-write` 因 timeout 或 runtime error 在内容生成前失败，在 scorecard 记录失败并停止，除非用户检查原因后明确恢复。
67. 如果用户在执行中取消，保存进度并记录已完成文章；下次 `/blog cluster execute` 时检测已写文件并从下一个未写文章恢复。
68. Execute Phase 第7步：所有尝试的文章完成后生成 `cluster-scorecard.md`。
69. Scorecard 记录每篇文章状态（written、failed、skipped）、文件路径和字数。
70. Scorecard 记录每篇文章质量分：通过 Task 并行调用 `/blog analyze`，并计算 cluster 平均分。
71. Scorecard 记录 cluster cohesion score：0 到 100 的复合分，由 link reciprocity、intent diversity、template diversity、keyword coverage 组成（公式见 reference）。
72. Scorecard 做内链审计：每篇文章的出站/入站数量、orphan flags、未解析的 `[INTERNAL-LINK]` 标记。
73. Scorecard 做 cannibalization 检查：任意两篇文章共享 primary keyword，或任意一对关键词重叠超过 70%；建议运行 `/blog cannibalization` 深查。
74. Scorecard 记录图像生成摘要：生成 vs 跳过的 hero images。
75. Scorecard 给出推荐后续动作：schema generation（`/blog schema`）、per-post SEO validation（`/blog seo-check`）、repurposing（`/blog repurpose`）。
76. Execute Phase 第8步：向用户返回简洁总结，包括 totals、scorecard 路径和 next-action commands。
77. 输出工件：Plan 阶段产出 `cluster-plan.json`（JSON）和 `cluster-map.html`（静态 HTML + inline SVG，无 JavaScript）。
78. Execute 阶段产出 `pillar-<slug>.md`、`<spoke-slug>.md`（Markdown 或平台检测格式）、可选 `images/<post-slug>-hero.png`（PNG via `blog-image`）和 `cluster-scorecard.md`（Markdown）。
79. Quality Gate：至少 2 个 cluster 且每个至少 2 篇文章；失败则规划时 warn 并建议扩展。
80. Quality Gate：没有两篇文章共享 primary keyword；失败则阻止执行并要求调整计划。
81. Quality Gate：每篇文章至少 2 条入站内链；失败则在 scorecard warn。
82. Quality Gate：pillar 至少 2500 字，spokes 至少 1200 字；作为硬约束传给 `blog-write`。
83. Quality Gate：cluster 间至少 2 种不同 intent；失败则在 scorecard warn。
84. Quality Gate：整个 cluster 至少 3 种不同 template；失败则在 scorecard warn。
85. Error Handling：种子关键词过宽（超过 50 个变体）时，建议先收窄焦点再聚类。
86. Error Handling：种子关键词过窄（少于 5 个变体）时，提供更小 cluster（pillar + 2 到 3 个 spoke）或建议放宽。
87. Error Handling：WebSearch 不可用时，只生成 draft plan，并要求用户确认、导入关键词数据或提供 SERP 数据后才能执行。
88. Error Handling：`blog-write` 质量门或内容生成失败时，停止批量、保存进度、把剩余文章标为 skipped，并要求手动检查或明确恢复。
89. Error Handling：`blog-write` 未安装时，返回：「blog-cluster requires claude-blog. Install it before running this skill.」
90. Error Handling：`cluster-plan.json` 格式错误时，验证 JSON 并报告带行号的解析错误。
91. Error Handling：用户取消执行时，保存进度；下次调用时自动检测已写文章并恢复。
92. Error Handling：可选图像生成不可用或失败时，跳过 hero image；在 execute 开始时 warn 一次，而不是每篇都 warn。
93. 不修改其他技能的文件；通过 Task 工具或作为编排子技能调用它们。
94. 按需加载 references：`references/semantic-clustering.md`、`references/cluster-architecture.md`、`references/execution-workflow.md`。
95. 跨技能调用：`/blog strategy` 用于上游规划，`/blog write` 用于每篇文章，`/blog chart` 由 `blog-write` 内部调用，`/blog image` 可选 hero image，`/blog seo-check`、`/blog cannibalization`、`/blog schema` 推荐在执行后运行。

适用边界 · 注意事项

• 不适用于只需写单篇文章、不需要主题集群规划与批量执行的场景（用 `/blog write`）。
• 不适用于仅做内容排期或仅诊断已有内容关键词重叠的场景（分别用 `/blog calendar`、`/blog cannibalization`）。
• 没有 Claude Code 和 claude-blog（含 `blog-write` 等子技能）时不要使用；本技能依赖这些工具。