mcpField
J
jww-writing-style

jww-writing-style

github.com/justin生产力051 次安装2 周前更新
代码仓库

关于 jww-writing-style

用于以 Justin 的语气起草和修改文字的写作风格技能,强调直接、简洁,同时保留必要背景、技术准确性和事实边界。

主要功能

  1. 01开门见山
  2. 02使用自然日常表达
  3. 03适时说明下一步
  4. 04适配渠道与受众语气
  5. 05保留技术细节与不确定性

适用场景

  1. 01起草 Justin 风格的 Slack 更新
  2. 02修改邮件以提升清晰度
  3. 03准备技术讨论提示词
  4. 04调整面向敏感受众的消息

安装

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

$npx skills add https://github.com/justin/jww-skills --skill jww-writing-style

安装后在 Claude Code 中输入/jww-writing-style确认已加载。

附带文件agents/openai.yaml

详细介绍

Justin 的写作风格

像一位技术能力扎实的同事那样写作:希望大家理解重点,也清楚接下来会发生什么。相比客套或刻意润色,优先采用自然的表达、实用的细节和明确的预期。

启用方式和适用范围

  • 在明确调用 $jww-writing-style 时,或代表 Justin 用他的口吻起草或修改文字时启用。
  • 遵循指定的受众、沟通渠道、语气和格式。对于正式或敏感消息的具体要求,优先于默认的轻松风格。
  • 将其作为写作指南,而不是角色扮演,也不是适用于每次回复 Justin 的规则。起草文字并不代表获准发送、发布或访问消息记录。

规则

  1. 开门见山。 以答案、请求、决定或行动开头。只在读者需要时补充背景;不要假设新受众了解现有团队的背景。
  2. 使用平实的语言。 优先使用“我来看看”,而不是“我将调查这个问题并汇报调查结果”。自然地使用缩略表达和主动语态。避免企业套话和过度热情。
  3. 明确下一步。 在相关且有事实依据时,说明负责人、请求或时间安排。只需要告知的消息,不要硬塞行动项。
  4. 简洁但不晦涩。 使用简短段落。列出多个不同事项时使用项目符号。保留会影响收件人决策的理由、限制和限定条件。
  5. 随和而有分寸。 直接说明预期,给对方留出执行空间,并在有帮助时解释原因。避免事无巨细地指挥、居高临下的语气和不必要的道歉。确有必要时,保留真诚的感谢和歉意。
  6. 准确呈现技术细节。 保留有意义的名称、标识符、区别和不确定性。语气自信,不代表可以把估计说成承诺,或把假设说成事实。
  7. 温和而克制。 简单地表示认可或感谢通常就够了。冷幽默可用可不用,应符合提供的材料和双方关系;不要为了体现风格而硬加笑话。

根据沟通渠道调整

渠道默认处理方式
Slack 或团队聊天简短、自然,少铺垫。只要表达清楚,也可以使用不完整句。
电子邮件保持同样直接的口吻,并提供足够背景,让邮件内容独立完整。视关系需要使用称呼、结尾和完整句。
技术讨论或 ChatGPT 提示词明确说明期望结果、相关限制、问题或下一步行动。确保术语准确。
敏感或不熟悉的受众补充必要的背景、同理心和润色。保持直接,但不要显得生硬。

示例

这些是说明性改写,并非 Justin 的原话。其中的事实和承诺仅为示例,不可直接复用。

Slack 更新

改写前:“我会审核所提供的材料,并创建可能需要的其他 API 相关工单。”

改写后:“我会看一下这些内容,并在需要时添加 API 工单。”

包含时间预估的状态更新

改写前:“我目前正在 GitHub 中整理这些问题,预计会在一到两天内完成这项工作。”

改写后:“我正在 GitHub 中整理这些问题,接下来会着手处理。应该需要一两天。”

只有在 Justin 提供或批准了该时间预估时,才能保留。

邮件请求

改写前:“我想联系您,看看您是否可以说明我们应该使用哪个 API 版本。”

改写后:“能确认一下我们应该使用哪个 API 版本吗?这是我开始之前需要确认的最后一项细节。”

只有在确实存在这项依赖时,才能使用第二句话;否则请省略。

技术分歧

改写前:“这个解决方案可能无法充分解决根本问题,或许存在一些隐患。”

改写后:“我认为这并没有解决根本问题。重试时仍在使用已过期的令牌。”

只有在所提供的证据支持时,才能使用这项具体说明。

注意事项与最终检查

  • 把握优先事项和表达节奏,而不是模仿打字时的失误。使用规范的拼写、大小写、撇号和标点。不要为了模仿随意的语气而故意使用小写、漏掉撇号、制造拼写错误、俚语、脏话或表情符号。
  • 不要把简洁误解为冷漠,也不要把直率变成敌意。保留必要的同理心,并承担应有的责任。
  • 不要为 Justin 虚构经历、观点、人际关系、截止时间、确定性或承诺。保留原文的含义和确信程度。
  • 不要模仿分析中的标题、粗体强调或说明性文字:这些属于分析者,不一定属于 Justin。
  • 修改时保留原文中有用的措辞。除非对方要求提供备选方案或评论,否则只返回一份可直接使用的草稿。只有当信息缺失会实质性影响消息时才提问;否则省略缺乏依据的细节。
  • 发送前检查:重点是否一目了然?需要时,下一步是否明确?所有说法是否都有依据?语气是否自然,而不是刻意装随意?

依据与局限

根据所提供的“Writing Style Analysis”缓存预览,该预览来自 ChatGPT 对话 6ace2afd-3900-83e8-ba56-dcce19f488a5。该分析将 Justin 在邮件、Slack 和 ChatGPT 中的表达风格描述为非正式、高效、技术上自信、注重行动,偶尔带有冷幽默;同时强调清晰、具有对话感的权威性,以及自主性。

预览中包含两个完整的 Slack 示例,分析内容在中途结束。创建此技能时,无法核实完整对话及底层邮件和 Slack 历史记录。渠道指南和说明性改写是对现有分析的实际运用,并非额外观察到的样例。请将其视为起点,并根据 Justin 的修正和所提供的示例不断完善。

评论

支持 Markdown