competitors 面向已经进入选型阶段的读者，适合写替代方案页、两款产品比较或多个备选清单。它与竞品采集不同：这里的主要工作是把核实后的资料变成决策说明，帮助读者判断何时值得切换、何时应该保留原方案。
安装与调用
在项目目录的终端运行下面的命令，只安装这个 Skill 到 Claude Code：
npx skills add coreyhaines31/marketingskills --skill competitors -a claude-code
需要 Node.js 和可用的 npx。若使用 Codex，把 -a claude-code 换成 -a codex；在对话里明确要求使用 competitors 并附上材料，不把终端安装命令当成任务提示。其他客户端应使用自身的技能选择入口。
先决定读者在比较什么
提供自家产品资料、竞争产品的当前文档和定价页，以及读者最在意的任务。如果目标是从某款产品迁移，重点应放在现有痛点、数据能否转移和需要重新配置什么；如果读者刚开始找选项，就需要明确筛选标准与多个真实备选。可以这样输入：
使用 competitors 写一篇我们与工具 B 的比较初稿。
证据在 profiles/，受众是五人设计团队，重点比较外部客户反馈与费用。
先核对功能和计费口径，再给“适合我们”和“更适合 B”的条件。
每个价格标资料日期，未知项保留；没有切换客户原话就不要生成评价。
不要只要求每一行都证明自己赢。让 Agent 用两三句话说明核心差异，再按读者任务展开。比较表适合快速定位，正文负责解释限制为什么影响工作，例如访客是否计费、某项集成是否只在高阶套餐提供。
让比较经得起读者核实
用同样的团队人数、付款周期与使用量计算价格，注明税费或附加成本是否包含；缺少报价时不要用猜测填表。为每个重要主张保留原始页面地址与检查日期，竞争产品的强项也应准确呈现。现有评价只能支持评价者描述的场景，不能扩大成所有用户的共同结论。
迁移部分要分别写可转移的数据、不能保留的配置、需要重新培训的步骤，以及你们实际提供的支持。没有迁移能力时不要把“立即切换”写成无成本动作。多个比较页共享同一竞品资料文件，后续价格更新才不会只改了一篇。
发布前让一名不了解项目的人按页面做一次选择：是否知道每个方案适合谁，能否找到主张依据，是否理解下一步要付出什么。搜索量与排名都需要额外验证；比较页有了清楚结构，并不自动证明这个关键词值得大量扩展。
按搜索意图选择页面，而不是换标题批量复制
“X 的替代品”通常是在寻找离开 X 的路径；“X 与 Y 对比”是在两个确定候选之间选择；“X 的最佳替代品列表”还需要解释选择标准和其他真实选项。先让 Skill 说清页面类型和读者目前知道什么，再决定结构。不要把同一张功能表复制进三种 URL，只改竞争对手名称。
可从一个决策情境下手，例如一个十人团队要从现有产品迁移：目前用到哪些功能、迁移数据量、预算和必须保留的集成是什么？据此写两三条真正影响选择的维度，并分别说明何时你更适合、何时对方更适合。价格比较要写清计费单位、必选附加项和查看日期；没有试用过的体验差异，应标明仅依据公开说明。
审稿时删除“我们完胜”式总结，检查功能表与段落结论是否一致，再让一个不知道你产品的同事按页面做决定：他能找到不适合你的条件、迁移下一步和来源链接吗？如果答案是否定的，这页还不是有用的比较页。
示例：为迁移者写替代品选择页
假设读者正从一款项目管理工具迁出，最怕丢失附件与权限设置。你有三款候选工具的公开文档，以及一份获许可的迁移测试记录。让 Skill 写：“使用 competitors 做一页‘X 的替代品’。先列读者迁移前要核对的三项条件，再比较三款工具的导入范围、权限映射和费用；每项标资料日期。给出适合不同团队的选择和下一步测试，不把我们排成每个条件下的第一名。”
完成时让一个同事只看页面回答：现有数据能不能导入？哪项可能需要人工重建？报价按席位还是项目？若答不出来，就补文档或删除未证实的勾选。最常见的失败是做出一张全是绿色对号的表，却让读者无法判断迁移风险；这时改为逐项解释边界，并把试用验证列成清单。
别漏掉软件之外的替代选择
读者可能正在比较另一款产品、电子表格、内部自建，或维持现状。为每种真实选项列出适合的人、主要成本、迁移难点和可核实的功能差别。第三方实施方案曾把 AssetShark 与资产管理软件及表格并列，而不是只写“我们优于竞品”；这是页面规划示例，不是已完成的比较页或切换成果。发布前仍要逐项核对现行功能与价格。