需要为某个网站或 SEO 项目建立可跨会话复用的…

在 OpenSEO 中为单个网站/SEO 项目做轻量上下文初始化，让后续技能和用户都能读取同一份项目背景。

适用场景

解决思路

1. 将本技能定位为上下文设置工作流，不是完整审计；围绕一个网站或 SEO 项目向用户访谈一次，把答案用 `update_project_context` 存入 OpenSEO 中该项目的共享上下文。
2. 记住该上下文会被所有其他技能、应用中的 SAM、以及用户在项目 Context 页面（侧边栏 AI 下）读取，因此能跨新会话、新机器和新 agent 保留。
3. 保持语气友好、务实、结构化；分批提问；只在有帮助时解释每个问题为何重要；不要用术语压垮初学者。
4. 明确只有两个项目上下文 MCP 工具负责写入，且都免费、不消耗 credits。
5. 用 `get_project_context(projectId)` 读取项目已知全部信息，以及 `missingSections` 缺失区块列表。
6. 用 `update_project_context(projectId, updates)` 提交一组 patch ops。
7. 本技能使用的 patch ops 包括：`section` 为 `business_overview`、`current_goal`、`positioning` 或 `writing_preferences`，并带 `content`。
8. 本技能使用的 patch ops 包括：`addCompetitors`，数组项含 `domain`，可选 `name`，可选 `notes`。
9. 本技能使用的 patch ops 包括：`addKeyPages`，数组项含 `url`，`role` 为 `hub`、`spoke`、`money` 或 `other`，可选 `topic`，可选 `notes`。
10. 本技能使用的 patch ops 包括：`customSection`，含 `<slug>`，可选 `title`，以及 `content`，用于不适合已有类型区块的内容。
11. 本技能使用的 patch ops 包括：当本次会话消耗 credits 时，用 `appendResearchLog` 并带 `summary`。
12. 在访谈推进过程中分批写入，不要等到最后才保存所有答案。
13. 各 section 用 prose 写，每个约 4,000 字符；写几段紧凑文字，不要写成对话记录。
14. 步骤 1：验证 OpenSEO MCP 并解析项目。写入需要 `projectId`，所以先做这一步。
15. 如果可用，使用 `whoami`。
16. 使用 `list_projects` 确认用户能访问项目。
17. 将项目匹配到用户想排名的网站/域名。
18. 如果项目列表不明确，询问用户应使用哪个项目。
19. 如果没有匹配项目，提出用 `create_project` 创建。
20. 如果 MCP 不可用，告诉用户连接 OpenSEO MCP；没有它什么都无法保存。
21. 不要为了测试连通性而运行研究工具；`whoami` 和 `list_projects` 已足够。
22. 步骤 2：读取已有内容。调用 `get_project_context`。
23. 向用户展示 OpenSEO 已知内容与缺失内容的简短摘要。
24. 对已有条目进行确认或纠正，不要重复询问已回答的问题；本技能常在另一个技能已填充部分上下文后被重跑。
25. 步骤 3：收集网站范围。询问主要网站/域名。
26. 询问其他域名或子域名。
27. 询问重要产品、服务、分类或页面。
28. 询问目标国家/语言。
29. 询问网站是新站、成熟站、迁移中，还是流量下滑后恢复中。
30. 如果相关，询问 CMS 或发布工作流。
31. 将持久信息写入 `business_overview`：业务做什么、面向谁、目标市场/locale、网站当前阶段。
32. 步骤 4：捕获目标。询问用户想从 SEO 得到什么：更多合格线索。
33. 更多注册/试用。
34. 更多电商收入。
35. 更多 newsletter/受众增长。
36. 更多品牌/品类认知。
37. 从流量损失中恢复。
38. 特定页面的更好排名。
39. 询问成功指标和时间范围。
40. 如果目标模糊，帮助转成可衡量目标，例如 `increase non-branded organic signups` 或 `rank top 10 for 20 buying-intent terms`。
41. 将结果写入 `current_goal`，包含指标和时间范围。
42. 步骤 5：捕获定位与策略上下文。询问他们已对公司、产品、受众和竞品做过哪些研究。
43. 请求他们能分享的笔记、文档、客户访谈、定位文档、pitch decks、落地页或策略备忘录。
44. 探查：产品或网站面向谁。
45. 探查：解决什么痛点。
46. 探查：用户为什么选择它而不是替代方案。
47. 探查：竞品和替代品。
48. 探查：强烈观点或定位主张。
49. 探查：最佳客户和不合适客户。
50. 探查：已经能转化的现有内容。
51. 探查：不想覆盖的主题。
52. 如果用户还没做，提出用公司网站、竞品页面、评论、论坛和 web search 帮助研究定位。
53. 写入 `positioning`：受众、问题、差异化点、用户想捍卫的主张。
54. 询问语气、禁用词或短语、要避开的主题，并写入 `writing_preferences`；内容起草工作流会读取该 section。
55. 步骤 6：保存竞品。把步骤 5 中的竞品和替代品转成 `addCompetitors` 条目：每个域一行，并用简短 `notes` 说明为什么重要，如 `direct competitor, owns the comparison pages`。
56. 如果用户不确定搜索中谁在竞争，对少量种子关键词运行 `find_serp_competitors` 来命名竞品；保存前与用户确认列表，并记录花费。
57. 这里保存的竞品会被 `competitive-landscape`、`competitor-analysis` 和 `link-prospecting` 复用。
58. 步骤 7：盘点关键资产。询问或发现 sitemap 或重要 URL 列表。
59. 询问或发现当前 blog/resources/content library。
60. 询问或发现产品/分类/功能页面。
61. 询问或发现已有关键词列表。
62. 询问或发现当前排名追踪器。
63. 询问或发现外链或 PR 资产。
64. 询问或发现可链接资产，例如研究、模板、工具、数据集、计算器或原创观点。
65. 用 `addKeyPages` 保存真正重要的页面：money pages、主题 hub、可链接资产。
66. 这是精选短名单，不是站点清单；通常 10 到 30 个 URL 正常。
67. 给每个 URL 一个 `role`，并在已知时给出它针对的 `topic`。
68. 步骤 8：连接 Google Search Console。GSC 是最丰富的一手信号：已有曝光、接近排名的词、关键词蚕食、已有搜索需求的页面。
69. 首选托管方式：在项目的 Integrations 页面原生连接 Google Search Console，并用 `get_search_console_performance` 拉取实时数据。
70. 连接后，agent 在 `keyword-research` 和 `keyword-clustering` 中直接读取，无需维护手工文件。
71. 备选自托管，或用户偏好文件时：让用户从 Search Console 导出 CSV 到本地工作文件夹（见步骤 9）。
72. 推荐导出：Queries 最近 3 个月，若可用也导出最近 16 个月。
73. 推荐导出：Pages 最近 3 个月，若可用也导出最近 16 个月。
74. 推荐导出：尽可能导出 Query + page 组合。
75. 推荐导出：如相关，导出 Countries/devices。
76. 让用户把文件放入 `gsc/`，并使用类似以下名称：`gsc/queries-last-3-months.csv`、`gsc/pages-last-3-months.csv`、`gsc/queries-last-16-months.csv`、`gsc/pages-last-16-months.csv`。
77. 步骤 9：仅为文件工作设置本地文件夹。项目知识存在 OpenSEO，不在磁盘上。
78. 本地文件夹仍适合实际作为文件的内容：GSC CSV 导出、爬取、草稿、brief、报告。
79. 如果用户想要，建议 `~/SEO/<company-or-site>/` 或网站/内容仓库旁边的文件夹，结构如 `seo-workspace/` 下含 `gsc/`、`drafts/`、`reports/`。
80. 除非用户要求，不要创建文件夹；不要把目标、定位或竞品复制到本地文件，那是项目上下文的用途。
81. 步骤 10：推荐第一个工作流。intake 后推荐一个下一项 OpenSEO 工作流。
82. 当网站已存在且用户想知道先修什么或做什么，尤其是 SEO 新手时，推荐 `seo-audit`。
83. 当用户需要从种子主题获得创意时，推荐 `keyword-research`。
84. 当用户有关键词或 GSC 数据要映射到页面时，推荐 `keyword-clustering`。
85. 当市场不清晰时，推荐 `competitive-landscape`。
86. 当用户知道要研究的某个竞品时，推荐 `competitor-analysis`。
87. 当用户有可链接资产或目标页面时，推荐 `link-prospecting`。
88. 输出格式：使用带状态的 checklist，表格列为 `Step`、`Status`、`Notes`、`Next action`。
89. 然后总结 OpenSEO MCP/project 状态。
90. 总结范围内的站点。
91. 总结目标。
92. 总结已知定位。
93. 总结已保存竞品。
94. 总结已保存关键页面。
95. 总结 Search Console 状态和任何本地文件。
96. 总结项目上下文中仍缺失的 sections。
97. 总结推荐的下一个工作流。
98. 告诉用户可以在项目 Context 页面（侧边栏 AI 下）读取和编辑这里保存的所有内容。
99. 保持设置轻量；用户应感到有方向，而不是被布置作业。
100. 写入前与用户确认事实；从网站推断可以提出，但保存的是双方同意的答案，不是猜测。
101. 除非能看到文件，不要假装 GSC CSV 已上传；除非 `get_search_console_performance` 确认，不要声称 Search Console 已连接，否则它会返回 not connected 消息。
102. 除非用户要求实时研究，保持项目设置聚焦于设置和上下文。
103. 如果某步骤消耗 credits，追加 research log entry，避免其他技能重复购买。
104. 如果使用 web search 或 scraping 做定位研究，区分来源证据和推断。
105. 覆盖 section 会替换它；当上下文已存在时，把新答案合并进已有 prose，而不是丢弃。

适用边界 · 注意事项

• 当任务目标是完整 SEO 审计、关键词研究、竞品分析或实时研究，而不是项目上下文初始化时，不适用；应在 setup 后改用对应工作流。
• 当无法连接 OpenSEO MCP、无法获得或创建可访问的 `projectId` 时，不适用，因为答案无处保存。
• 当不能与用户确认事实、或用户拒绝提供/确认站点范围、目标、定位等上下文时，不适用；不要把未确认推断当答案写入。