mcpField
C
copywriting

copywriting

github.com/ssheleg营销与增长6261 次安装3 天前更新
代码仓库

关于 copywriting

copywriting 是 super-ux 中按产品品牌规范撰写和修改文案的技能,适用于产品文本与营销内容。它要求先读取品牌资料,并通过文案登记与默认的人性化检查,保持各渠道表达一致。

主要功能

  1. 01按品牌声音与渠道规范写作
  2. 02编辑和跨渠道改写文案
  3. 03维护界面文案登记表
  4. 04默认执行人性化检查
  5. 05依据来源核验产品声明

适用场景

  1. 01撰写界面按钮、提示和错误文案
  2. 02编辑营销页面或应用商店介绍
  3. 03将一段文案改写用于多个渠道
  4. 04审查既有文案的自然度

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/ssheleg/super-ux --skill copywriting

安装后在 Claude Code 中输入/copywriting确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

references/
ai-tells.md
brand-contract.md
channel-playbooks.md
hooks.md
landing-pages.md
localization.md
marketing-copy.md
research-outliers.md
seo-aeo-safety.md
store-copy.md
surface-registers.md
system-map.md
ui-copy.md
video-script.md
voice-packs.md
templates/brand/
copy-brief.md

详细介绍

copywriting — 以产品自己的语气撰写

属于 super-ux — 参见 system-map.md。 修改后,按下文说明解析并运行品牌检查器。

每次都要先做的一件事:阅读品牌资料包。 阅读 docs/brand/voice.md、 terminology.md,以及所写内容对应界面的 channels.md 记录。

没有资料包?停止并移交给 brand-voice。 不要自行揣摩语气。 猜错的代价大于暂停;而逐个界面臆造文案的产品,正是本层要消除的偏差。

退出必须明确说出,不能默认: "no brand" / «без бренда» — 或 "draft it" / «черновиком» — 表示操作者选择不走这条流程: 直接撰写,并说明资料包是按要求跳过的,绝不要默默跳过。

所有权按文件划分,而非按目录划分。 brand-voice 负责资料包中的 权威来源——voice.md、术语词典、facts.md、各渠道指南和本地化政策—— 本技能绝不编写这些内容:词典中缺少的术语,或 facts.md 中没有对应条目的数字, 都要报告,绝不为了写完句子而编造——是否添加由 brand-voice 决定。本技能确实负责 strings.md(界面字符串登记表,写入时标记为 Status: proposed)和产品文案。 两者都放在 docs/brand/ 下,但目录不代表所有权——所有权归文件本身。 填写 strings.md 条目是本技能的工作,无需为其存放位置另行审批;协同运行时须先认领文件再编辑, 同一轮中不得改动语气和事实资料。

触发条件

以下英文和俄文短语会触发本技能。为使技能列表不超出预算,描述中仅保留最强的触发短语(2026-10-20);家族路由钩子与此列表一致。

"write copy" / "напиши текст", "App Store description" / "описание для App Store", "store listing" / "описание в сторе", "rewrite this" / "перепиши", "headline" / "заголовок", "CTA" / "кнопка", "microcopy" / "микрокопия", "error text" / "текст ошибки", "this sounds like AI" / "звучит как нейросеть", "post for X" / "пост в твиттер", "reel script" / "сценарий рилса", "video hook" / "хук ролика", "build a landing page" / "сделай лендинг"(指页面文案;视觉层由 sheleg-design 负责)。

参考资料

阅读使用场景
ui-copy.md产品内的任何字符串
marketing-copy.md页面、长文、七轮检查、事实依据
landing-pages.md组装落地页:报价、认知、证明、行动
channel-playbooks.md社交媒体、博客、更新日志、广告或邮件界面,或创作者、品牌大使计划
video-script.md短视频、短片、TikTok 或视频广告:切入角度、结构、时长、镜头清单、关卡
hooks.md开头三秒:三段式、26 种公式、40 个模板、B044 筛选器
research-outliers.md视频制作前:哪些视频的表现超过了其账号自身水平
store-copy.mdApp Store 或 Google Play
seo-aeo-safety.md爬虫或答案引擎会读取的任何内容
ai-tells.md所有会生成文本的模式:默认执行此检查
localization.md任何非主要语言地区
surface-registers.md界面的语体

模式

凡是会生成文本的模式,默认都会执行人性化处理。 这不是一种需要进入的模式,而是撰写、编辑和改编的最后一步,且必须遵循 ai-tells.md 中不可省略的约束。之所以将其设为默认而非可选项,是因为未经处理的草稿会带有该文件所评估的特征,而读者往往在说清原因之前,就已经察觉到了这些特征。

voice.md 通过两个字段记录状态,分别回答不同的问题。Humanization: on | off 表示是否执行这一步;如果未设置该字段,默认值为 on。Humanization pass: 指定运行哪种实现;如果未设置,默认值为 own,这是唯一会读取此套件的语域和规范事实的实现。关闭此功能是一个正当的决定,即使做出决定的人离开后也仍然有效,因此 off 时必须附带一行 Humanization declined:,写明原因和日期。B064 会检查这三种状态。

每次交付文案时,都要用一行说明执行情况,放在文案之前或紧接其后:

Humanization: on (own pass): 7 markers at 2 densities, 4 addressed, 11% changed
Humanization: off (declined 2026-08-30): wording fixed by counsel

这行文字不是装饰。不可见地执行处理,与完全没有执行无法区分;而文案的读者通常也不是设置选项的人。

撰写
  1. 明确使用场景。该场景必须存在于 channels.md 中;如果不存在,应由 brand-voice 决定,而不是在这里临时发挥。 仅限营销工作,阅读 marketing-copy.md → 撰写前,并根据 templates/brand/copy-brief.md 创建或更新当前简报。尚未解决的输入保留为 unknown;仅涉及界面的工作无需额外加载简报。
  2. 应用语域:采用 voice.md 中的各个维度,以及该使用场景对应的差异。差异可以调整各个维度,但绝不能越过不变原则。
  3. 撰写。每项主张都必须能追溯到 facts.md。每个产品术语都必须来自 terminology.md。
  4. 先交付文案,再说明理由。对于标题和 CTA,提供两到三个选项,并说明各自舍弃了什么。
  5. 对于界面文案,添加或更新 strings.md 中的行,包含键、file:line、场景和 Status: proposed。
  6. 按照下方「人性化处理」中的约束执行人性化处理,然后输出状态行。对于新文本,变更率以刚刚写出的草稿为基准衡量,因此 50% 的上限不像编辑时那样适用;无论如何都要报告变更率。
编辑

按照 marketing-copy.md 中的顺序进行七轮检查,每轮后回到开头:清晰度、语气与风格、价值说明、证据支持、具体性、情感、零风险。按影响优先级逐轮交付,而非按阅读顺序。

人性化处理最后执行,七轮检查完成后,再输出状态行。之所以放在最后,是因为各轮检查会改写整句;若提前执行人性化处理,其衡量基准就会变成已经不存在的文本。此外,语义保留清单最适合用于检查不会再被改写的版本。

改编

将一篇内容适配到多个使用场景。针对每个场景重写,绝不要把一个语域直接粘贴到另一个场景中。改编后保留的是主张和证据;改变的是篇幅、结构、CTA 策略和语域。

明确说明每个版本删去了什么。帖子串不是只带有换行符的页面。

人性化处理按使用场景分别执行,而不是只针对源文本执行一次。 每个版本都是采用不同语域的不同文本;在博客文章中可以接受的特征密度,放到落地页首屏就不合适。每个使用场景都要有一行状态说明。

人性化

独立模式,用于审核已有文本,不写入任何内容: 继承而来的页面、竞争对手的文案、别人写的草稿。无论在哪运行, 审核都遵循同样的规则,且这些规则不可忽略:

  • 每 500 个词的标记超过约 10 个时,应说明情况,并从论点出发重写—— 修补只会用更好的措辞制造同样的模式。
  • 更改率超过 50% 时,不要交付。 报告更改率并征求意见。 这已经不再是编辑。
  • 输出前运行语义保留检查清单:数字、日期和专有名词保持不变;因果 方向不变;否定不反转;引文保持原样;核心主张不变。
  • 已经读起来自然的文本应保持原样。为了证明运行过审核而修改原本没问题 的内容,就是此模式的失败。
  • 标记数量不是判定依据,也绝不会成为任何操作的门槛。 说明存在哪些 标记及其密度;绝不要说文本是 AI 写的。标记数量无法证明作者身份—— 误报对使用第二语言写作的人影响最大,而写作者不是需要被编辑到流畅、 却从未提出这种要求的缺陷。人性化审核始终仅供参考: B060 只会警告,不会报错。ai-tells.md 记录了衡量方式及其约束。 唯一例外是 em dash(AT-06):它是对你所写文本的硬性禁用项,不是 计数项,并列在“不可妥协项”下。
  • 引文、注册术语和明确设置为 off 都绝不会强制重写。 引文中的标记 是源文本用词;terminology.md 中的术语本来就应该重复出现;而 Humanization: off(附带原因)会原样保留文本。品牌禁用词是独立的 用户政策——禁用词是品牌在 terminology.md 中自行选择的内容,不是 机器生成文案的标记,应由相应检查处理,而不是本次审核。
  • 先读取 voice.md 中的两个字段。 Humanization: 决定是否运行审核, 默认值为 on;Humanization pass: 指定使用哪种实现,未设置时为 own。即使两项都未设置,也不要停止工作:运行默认设置,打印状态行, 说明使用了默认值,并询问是否记录一次。若指定的工具未安装,则回退到 own 并说明原因——缺少可选工具不得阻止文案撰写。
  • 还有其他实现,值得了解其中两种—— npx sshlg-skills humanizers 可列出这台机器上已有的工具。对于不重写 文本的审核、长篇文案,或写作者提供了自己的写作样本以供匹配时,可以 使用其中一种。产品文案则留在这里处理:品牌资料包中的语体和规范事实 才是约束,而通用的人性化工具不会读取这些内容。

不可妥协的要求

  • 你撰写的任何语言文本中都不得出现 em dash(U+2014)(负责人决定, 2026-10-18)。这不是频率目标:出现一个就是错误,交付前必须修正, 也不能用其他符号代替(--、en dash 或起到破折号作用的空格加连字符 都不行)。请使用句号、逗号、冒号或括号,或者改写句子。唯一罕见的例外是 俄语语法需要破折号,且没有自然的改写方式。引文、代码、命令、路径和历史记录 保留其中原有的破折号。B062 和 B067 检查机器能够验证的内容;其余部分参见 ai-tells.md AT-06。

  • 标题或标签中不得添加装饰性句号,包括嵌套 HTML、格式化 Markdown 以及“Your agents. Your tools.”这类断句。请根据渲染后的实际效果判断, 而不是只看纯文本导出。保留真正的问句、省略号、缩写、版本号、URL 和常规段落标点。 项目可以将此规则扩展到主视觉摘要和说明文字;请在品牌政策中记录适用范围, 并测试生成的页面。 恢复历史文案时,请重新套用当前项目的标点政策;旧版精确文本快照不构成有意例外。

  • 不得捏造事实、统计数据、引文或专家。 不要为了赶截止日期、充实基准测试, 或让占位内容显得更好而这样做。应拒绝,说明原因,并提出寻找真实内容。

  • 任何内容包中的 error、destructive confirm、billing and receipts 或 paywall and upgrade 场景都不得使用幽默。用户在这些场景中会失去某些东西。

  • 一个操作,一个名称。 为操作命名之前,先在 strings.md 中搜索。 为已有操作另起名称是缺陷,不是同义词。

  • 绝不引用 facts.md 中没有的数字。

完成定义

  • 每个字符串或章节都能追溯到一个表层记录和一种语气。
  • 无论报告哪种状态,都要打印人性化状态行。
  • 新的界面字符串必须放在 strings.md 中,并注明位置和场景。
  • 运行检查器前先解决其依赖:如果存在 docs/brand/lint.py,就使用它;否则,在其脚本目录中找到已安装的 super-ux 检查器 brand_lint.py,并传入项目的 docs/brand 路径。不要臆造项目本地脚本,也不要假定 shell 导出了插件根目录变量。如果两者都不存在,要明确指出缺少的工具和手动检查范围;绝不能称其为检查通过。
  • 确认 Sources: 能解析到已修改的表层。HTML 标题角色必须在复制投影后保留;扁平段落不能证明标题覆盖完整。标题标点是必要门槛时,运行解析出的脚本并加上 --fail-on B063(或用 --strict 检查所有警告)。如果旧版脚本不接受该标志,就应更新脚本,而不是重试并悄悄去掉这一门槛。
  • 除了检查器,还必须进行语气检查;绝不能用它替代检查器。 根据会话中是否有该工具来决定是否执行,不要看配置:如果存在语气检查 MCP 工具(提供 *.check 和 *.voices.list 的工具),就用文本的 locale、项目已保存的语气(若语气列表中有,则作为 voiceRef),以及其 schema 提供的 register 和 format,检查你编写的每一段公开文本。目标是页面使用 register: web 和 format: web-page;在 schema 列出这些选项之前,使用 register: marketing(在广告或商店表层分别使用 ad 或 store),省略 format,并说明尚无 web-page pack。报告报告 ID,并逐条处理或驳回每项发现:这些只是建议,与 B060 类似。如果没有该工具,则打印 voice checker: not connected, brand_lint only 并继续。
  • 报告已扫描的表层、剩余警告以及准确的命令和退出代码。存在建议性警告时,即使退出代码为零,也不代表审查干净。检查渲染后的文案和生成器;只检查源文件无法发现外部 CSS 或运行时文本。
  • 对于任何报告为缺失的内容——术语、事实或表层——都要明确指出,不能绕过。

references/ 中还有什么。 本技能直接提及 13 个契约;references/ 中有 15 个,因为本技能提及的契约还会链接到其他契约,而整个依赖闭包都随技能一起发布——skills CLI 会安装一个目录,否则兄弟目录中的文件就会成为悬空文件。打开此处提及的契约;其余契约会由它们按名称引出。

评论

支持 Markdown