writing-prose

撰写散文

规则存放在 rules/ 中，每条规则占一句，并带有 ID 和等级：

• F（完全）：由 check.sh 判定，发现的问题即为最终结论。
• H（启发式）：check.sh 会列出候选项，由你确认或驳回。
• M（模型）：你需要通过阅读来判断是否违反规则。

文本类型

先指定文本类型：chat、ticket、tracker（拉取请求正文和评论）、markdown、skill、primed（每次会话都会加载的文件）、comment（代码注释和帮助文本）或 commit。 check.sh --rules <surface> 会列出该文本类型所读取的规则文件。

流程

1. 阅读该文本类型的规则文件。
2. 起草。 若要重写，先阅读旧文本块，再依据规则重新起草，然后替换旧文本。 切勿修补旧句子。
3. 运行 check.sh <surface> <file>。 重写时添加 --before <old-file>；文件参数为 - 时从标准输入读取。 修复所有 F 类问题。 确认或驳回所有 H 类候选项，并修复确认的问题。
4. 判断运行结果末尾列出的每条 M 类规则。
5. 重复第 3 和第 4 步。 从第二轮起，在原处修复问题。
6. 对读取排版规则的文本类型，最后处理排版。 内容通过检查后，设置语义换行，再运行一次第 3 步。 若仅重新排版内容编辑未改动的行，则属于重新流式排版，应单独提交为风格提交，并使用 --style 检查。 如果请求要求在内容审查前处理排版，请告知负责人这一顺序违反了本步骤，并在开始前征求同意。

当 check.sh 以 0 退出、所有 H 类候选项均已处理且没有违反任何 M 类规则时，文本即为通过。

第二轮结束后仍未解决的 M 类问题，应作为报告提交给负责人，而不是进入第三轮。

审查人员

• 所有文本类型中，每次写作时都由 check.sh 检查 F 和 H 类规则。
• 对于工单、tracker 文本和拉取请求正文中的 M 类规则，由子 Agent 在发布前审查。 子 Agent 只能看到文本、文本类型和规则。 你自己的上下文会忽略受众偏差，并轻信合规声明。 如果没有子 Agent，请自行审查并说明这一点。
• 对于拉取请求中的仓库文件，M 类规则由项目的文案审查流程处理。 如果没有该流程，则由子 Agent 审查。

Chat 不使用子 Agent。 写作时遵循其规则。