---
name: stc
description: >
  STC（Simplified Technical Chinese，简明技术性中文）：写、改写或审阅自然、简短、准确的中文。用户要求中文审阅、精简表达、删除多余说明、去掉套话或统一术语时使用。项目启用 STC 默认输出规则时，中文输出均适用。
---

# STC 简明技术性中文

本 skill 按规范生成、改写和审阅中文。默认表达自然、简短、准确，同一个意思使用同一个词。规则在 `rules/`，词表在 `dictionary/`，路径都相对于本 skill 所在的目录。

## 默认表达方式

每次使用本 skill，都必须同时执行以下要求：

- 用完整句子和自然语序，直接回答问题或交付结果。
- 删除客套、重复和无关解释，信息足够时停止。
- 保留事实、数字、名称、否定词、权限和真实不确定性。
- 根据任务展开。完整文稿和详细说明必须满足用户要求。
- 交付成品时，从采用的结果写起；制作与复核记录放在内部。

这些要求内置于 STC，具体规则为 G14、G15、G20、G21、G22，以及当前场景的规则。

## 安装后的首次使用

安装后的引导必须按 [`ONBOARDING.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。
- 场景选择用于内部执行。用户询问方法或判断存在分歧时，再说明所用规则。

## 第二步：读规则和词表

1. 读 `rules/for-all.md`。通用规则对所有场景都适用。
2. 读第一步选定的场景文件。场景规则和通用规则不一致时，以场景规则为准。
3. 读 `dictionary/avoid.yaml`。只用 `profiles` 字段为空或包含当前场景的条目。
4. 写界面文字，或写警告、注意、说明这类提醒时，读 `dictionary/recommended.yaml`，动作词和提醒级别照表里的意思用。
5. 项目里有术语表时（文件名通常含 `terms` 或“术语”），必须照术语表写名称。

## 第三步：按用法处理

用户的请求属于下面三种用法之一。

### 写

按规则写出文字，再按第四步自查。

### 改写

改写用户给的文字，保留原意：

- 必须保留原文的事实、数字、专有名称和引语。
- 必须保留表示把握程度的词：可能、也许、大概、通常。
- 程度词必须换成数字。原文和上下文里没有这个数字时，不得编造数字。这时删掉程度词，或写成“【待补：提升了多少】”，并在改写结果后列出所有待补项。原因：编出来的数字比含糊的形容词危害更大。
- 交付用户请求的内容。用户要求解释，或改动会影响使用判断时，再说明主要改动与依据。

### 审查

审查用户指定的材料。先给报告和具体改法；用户要求改写时再给修改稿，写回文件按用户已有授权执行。

报告必须按以下顺序写：

1. 用一句话说明主要问题，区分需修改项与待确认项。
2. 按原句分组，给出位置、原句、问题原因和具体改法。规则编号放在说明后面。
3. 单独列出需要用户补充的事实。缺少的数据和主体名称必须用“【待补：…】”标记。
4. 用户可以选择采用哪些改法。已选定的修改可以直接执行，不必再次询问。

不得直接把命令输出的逐行诊断当作交付报告。机器输出是审阅依据；agent 必须结合上下文判断指代、术语、事实和句意。警告只有经上下文确认后才能判定为问题。

检查命令默认提供可读报告。`--format markdown` 可生成 Markdown 报告；`--json` 为程序和 agent 提供结构化依据。

## 第四步：自查

对本次任务内写出的文件或用户指定的材料，能运行 Node.js 18 以上版本时，使用检查命令。普通对话按规则自查，不为每条回复启动命令：

```bash
node <本 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）。
- 人称符合场景：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`