STC 简明技术性中文
本 skill 按规范生成、改写和审阅中文。默认表达自然、简短、准确，同一个意思使用同一个词。规则在 rules/，词表在 dictionary/，路径都相对于本 skill 所在的目录。
默认表达方式
每次使用 STC，都必须同时执行以下要求：
- 用完整句子和自然语序，直接回答问题或交付结果。
- 删除客套、重复和无关解释，信息足够时停止。
- 保留事实、数字、名称、否定词、权限和真实不确定性。
- 根据任务展开。完整文稿和详细说明必须满足用户要求。
- 交付成品时，从采用的结果写起；制作与复核记录放在内部。
- 任务回执按 for chat 的 C10 分成“做完了”“需要你”“知会”，把用户动作单独列出。
这些要求内置于 STC，具体规则为 G14、G15、G20、G21、G22，以及当前场景的规则。
安装后的首次使用
用户选择通过链接使用时，读取 WEB.md，按网页引导确认规则读取情况和生效范围。
安装后的引导必须按 ONBOARDING.md 执行：提供默认使用选项和文档审阅体验，等待用户选择。
用户可以提供材料，也可以授权 agent 从当前项目挑选一份文档。审阅范围和修改动作以用户授权为准。
第一步：判断场景
动笔前先判断这次写的是哪类文字。按读者和用途判断：
| 读者和用途 | 场景 | 规则文件 |
|---|---|---|
| 正在对话的人，读 agent 的回复 | for chat | rules/for-chat.md |
| 人，读来理解内容或照着操作：报告、方案、手册、周报、会议纪要、代码注释、提交说明 | for document | rules/for-document.md |
| 产品的用户，在网页或应用界面上看到：按钮、标签、提示、报错、通知、空状态 | for web dev | rules/for-web-dev.md |
| agent，读来照着执行：系统提示词、AGENTS.md、CLAUDE.md、skill、给 agent 的工作流程 | for instruction writing | rules/for-instruction-writing.md |
- 一次任务包含几类文字时，必须对每一类文字分别判断。例如一份需求文档按 for document 写，文档里给出的按钮文字按 for web dev 写。
- 读者和用途都判断不清时，按读者判断：读者是模型，用 for instruction writing；读者是产品用户，用 for web dev；其余用 for document。
- 场景选择用于内部执行。用户询问方法或判断存在分歧时，再说明所用规则。
第二步：读规则和词表
- 读
rules/for-all.md。通用规则对所有场景都适用。 - 读第一步选定的场景文件。场景规则和通用规则不一致时，以场景规则为准。
- 读
dictionary/avoid.yaml。只用profiles字段为空或包含当前场景的条目。 - 写界面文字，或写警告、注意、说明这类提醒时，读
dictionary/recommended.yaml，动作词和提醒级别照表里的意思用。 - 项目里有术语表时（文件名通常含
terms或“术语”），必须照术语表写名称。
第三步：按用法处理
按用户请求生成、改写或审阅文字。
写
按规则写出文字，再完成语义复核。
改写
改写用户给的文字，保留原意：
- 必须保留原文的事实、数字、专有名称和引语。
- 必须保留表示把握程度的词：可能、也许、大概、通常。
- 程度词必须换成数字。原文和上下文里没有这个数字时，不得编造数字。这时删掉程度词，或写成“【待补：提升了多少】”，并在改写结果后列出所有待补项。原因：编出来的数字比含糊的形容词危害更大。
- 交付用户请求的内容。用户要求解释，或改动会影响使用判断时，再说明主要改动与依据。
审查
审查用户指定的材料。先给报告和具体改法；用户要求改写时再给修改稿，写回文件按用户已有授权执行。
报告必须按以下顺序写：
- 用一句话说明主要问题，区分需修改项与待确认项。
- 按原句分组，给出位置、原句、问题原因和具体改法。规则编号放在说明后面。
- 单独列出需要用户补充的事实。缺少的数据和主体名称必须用“【待补：…】”标记。
- 用户可以选择采用哪些改法。已选定的修改可以直接执行，不必再次询问。
汇报审阅任务的执行结果时，按 C10 写回执。审阅报告本身使用本节的结构。
不得直接把命令输出的逐行诊断当作交付报告。机器输出是审阅依据；agent 必须结合上下文判断指代、术语、事实和句意。警告只有经上下文确认后才能判定为问题。
检查命令默认提供可读报告。--format markdown 可生成 Markdown 报告；--json 为程序和 agent 提供结构化依据。
第四步：自查
普通对话按 C8 在发出回复前自查。对本次任务内写出的文件或用户指定的材料，能运行 Node.js 18 以上版本时，使用检查命令：
bashnode <本 skill 目录>/tools/cli.mjs check <文件> --profile <场景> --anti-echo
用 npx @daimonia/stc init 安装时，本 skill 目录是 .claude/skills/stc/。文字不在文件里时，可以通过标准输入传给检查命令。检查命令报的错误必须全部改掉。Anti-Echo 疑点必须结合读者和页面复核：删除多余内容，或为必要内容记录具体保留理由。复核文件的格式见 tools/README.md。文本变动后必须重新核对。其他警告宜逐条判断。
语义复核
交付前必须逐项检查：
- 每句话都帮助当前读者理解、判断或操作；多余排除、制作说明和自证已删除（G20）。
- 页面实际显示的标题、正文、按钮、提示、图注和角标均已逐项审阅（W9）。
- 同一个东西只用了一个叫法（G1）。
- 没有“进行、加以、予以、作出、开展”加名词（G4）。
- 程度词和模糊量词已换成数字或具体事实；数据均有原文或上下文依据（G5）。
- 没有营销词、行话、套话和口号句式（G6、G7）。
- 一句只讲一件事，一句不超过 40 个字（G9、G12）。
- 表示把握程度的词没有被删掉（G15）。
- 句子自然、语法完整，长短随内容变化（G21）。
- 篇幅满足任务，必要步骤和风险信息没有被压掉（G22）。
- 对话没有重复结论、工具旁白或不必要的模板（C7、C8、C9）。
- 任务回执分清完成结果、用户动作和知会；用户动作有真实依据，交付物有入口（C10）。
- 人称符合场景：for document 和 for web dev 里没有“我们”“你们”；for web dev 里也没有“他”“她”“它”“大家”（D1、W1）。
- for instruction writing 里，强度词只有“必须、不得、宜、不宜、可、不必、能、不能”（I1）。
- 数字用阿拉伯数字并带单位；中文与英文、数字之间有空格（G18、G19）。
不改动的内容
- 引语和用户的原话，包括其中的人称。
- 代码、命令、文件路径、接口名。
- 品牌口号、法律文本。
- 英文文字。STC 只管中文；英文可以参照 ASD-STE100。
参考
- 规则总览与编号一览：
rules/README.md - 词表格式与类别：
dictionary/README.md
