mcpField
O
oil-tone

oil-tone

github.com/oil-oilMarketing & growth24881 installsUpdated 5w ago
Repository

About oil-tone

oil-tone is a style guide for writing and revising Chinese text, focused on natural, readable prose, clear information flow, and factual grounding. It includes a review checklist and a lint script that flags selected wording for inspection.

Key features

  1. 01Natural, readable expression
  2. 02Organization based on reader context
  3. 03Complete factual and causal links
  4. 04Avoidance of unsupported claims
  5. 05Final-draft review checklist
  6. 06Included tone_lint.py script

Use cases

  1. 01Revising Chinese documentation and explanations
  2. 02Reordering paragraphs for clearer flow
  3. 03Checking whether wording reads naturally
  4. 04Reviewing factual support and causal links

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/oil-oil/oil-tone --skill oil-tone

After installing, type/oil-tonein Claude Code to confirm it loaded.

Bundled filesagents/openai.yamlscripts/tone_lint.py

Details

From the project README

oil-tone

最重要的四件事

oil-tone 的首要目标是让文案自然、易读、通顺、清楚:读者能按自然语序读下去,轻松理解句子和段落的意思。事实有依据是不能突破的底线;结构、用词和删改都要服务于理解,不能为了短、正式或整齐而把话写得生硬。

  1. 自然、易读、通顺。 用符合语境的常用词和自然语序,保留完整、自然的表达节奏,不为压缩而写成生硬短句。中文里的“的”“了”等虚词只要承担语法、语气或关系作用,就应保留,不能默认当作赘词;是否留删,要结合意思和朗读效果判断,不机械增删。
  2. 让读者跟得上。 按读者此时已经知道的信息安排顺序。新对象让人跟不上时,只补理解它所缺的那一步;已经清楚的内容不重复解释。标题不能代替正文完成必要的交代。
  3. 把关系讲完整。 事实、操作、原因、结果和限制之间缺了一步时,先补这一步。一个句子通顺,不代表它能接上前一段;段落之间跳跃时,先调整信息顺序,不靠“接下来”“因此”等词掩盖。
  4. 事实有依据。 不编造经历、感受、用户反馈、数字和结果。把亲身体验、官方资料、推测和计划分开写;事实变化时核对当前材料。

写作与改写

  • 先确认这篇内容要回答什么问题、材料支持哪些判断、读者需要先知道什么,再组织段落。每段承担一种主要作用,相邻段落应有读者能看出的关系。
  • 读者需要先认识某个产品、功能、术语或指标,才能理解后文时,在第一次用到它的地方说明;读者已有上下文时直接往下讲。解释不要依赖另一个未经说明的词。
  • 正文先讲到读者不打开链接也能理解。需要核对事实或进入产品、文档、仓库时,把链接放在对应说法旁边;链接不代替解释,也不集中堆在文末。
  • 只要求润色时,保留原有事实、观点、数字、引用和必要格式。用户指出全文难懂或顺序不自然时,可以调整段落与章节,但不得借重排改变结论或补入无依据的细节。
  • 标题说明真实对象、动作或判断;小标题直接标明该部分内容。标题中的所有权、时间、数量和结果都要有材料支持。
  • 连续的解释和因果关系用自然段;并列项、步骤和查找信息可以用列表或表格。选择格式之前,先确认正文的理解顺序。

语气与句子

  • 写自己的做法和判断时用“我”;带读者看一般流程时可用“我们”;直接称呼读者群体时可用“大家”。不虚构共同经历,同一段内不频繁切换称呼。
  • 写工具和产品时,优先呈现自己实际做过的操作、看到的结果、据此形成的判断和使用限制。不把有依据的个人判断改成中性的功能介绍。
  • 句子要让人看清谁做了什么、作用于什么、发生了什么变化。上下文清楚时可以省略主语;读者需要回读猜测时应补清。
  • “看、说、删、写、查、改、做、用”等常用动词,意思准确就直接使用。“的”“了”以及“在”“就”等虚词,只要能让语法、语气或关系表达得更自然、准确,就保留下来;不要为了压短句子或增加书面感而删掉,也不要为了显得口语而机械添加。判断时要连着上下文朗读,比较删改前后的自然程度和意思。
  • 说明影响时写具体后果,不停在“有影响”“得到提升”一类泛指上;具体后果必须有材料依据,不能为了生动虚构场景。
  • 不用没有信息量的行业背景、模糊归因、宣传口号、模板化转场和拔高结尾。删掉后不影响事实与关系的句子,可以直接删;确有转折或限定作用的表达不机械禁用。
  • 中文按自然语法和标点书写;英文使用常见、直接的词。口播与社交内容保留自然的口语节奏;文档可以正式,但不要为了书面感删掉必要的虚词或连接表达。成稿要清理重复起句和无意义的语气词。

表达形式

  • 文档、说明和正式通知以准确、易查找为先;口播与社交内容可以更接近日常说话,但同样要讲清对象和关系。
  • 已有成稿中的代码、专有名词、链接和引用来源按需保留;中文与英文、数字之间留一个半角空格。

完稿检查

  1. 只读标题和各段首句:能否顺着它们讲出全文?新对象是否突然出现?发现跳跃时先调整顺序或补足关系。
  2. 连续读正文:每个判断是否有依据,原因和结果是否连得上;不打开链接能否理解主要内容?
  3. 按自然语速朗读:有没有不符合日常表达习惯的拗口句子?删掉“的”“了”等虚词后,语气、语法关系或意思有没有变生硬、变模糊?指代、动作对象、条件和状态是否清楚?修改后句子是否仍然完整?
  4. 文件成稿可运行本 Skill 的 scripts/tone_lint.py 查找值得复核的表达。脚本只提示少数套话和空泛说法,无法判断文字是否自然、易读、通顺;逐条结合语境决定是否修改,最终以全文连读为准。

Comments

Markdown supported