Back to Details

writing-prose

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Writing Prose

编写散文

Rules live in 
rules/
, one sentence each, with an id and a tier:
  • F: 
    check.sh
    decides, and a finding is final.
  • H: 
    check.sh
    prints a candidate, and you confirm or dismiss it.
  • M: you judge the rule by reading.
规则存放在 
rules/
中，每条一句话，带有 id 和层级：
  • F：由 
    check.sh
    决定，发现即为最终结论。
  • H：
    check.sh
    打印候选内容，由你确认或排除。
  • M：通过阅读来判断规则。

Surfaces

场景

Name the surface first: 
chat
, 
ticket
, 
tracker
(pull request bodies and comments), 
markdown
, 
skill
, 
primed
(files loaded into every session), 
comment
(code comments and help text) or 
commit
. 
check.sh --rules <surface>
names the rules files the surface reads.
首先指定场景：
chat
、
ticket
、
tracker
（拉取请求正文和评论）、
markdown
、
skill
、
primed
（加载到每次会话中的文件）、
comment
（代码注释和帮助文本）或 
commit
。 
check.sh --rules <surface>
会列出该场景读取的规则文件。

Loop

循环

  1. Read the surface's rules files.
  2. Draft. To rewrite, read the old block, draft it fresh from the rules, then cut. Never patch the old sentences.
  3. Run 
    check.sh <surface> <file>
    . A rewrite adds 
    --before <old-file>
    ; 
    -
    as file reads stdin. Fix every F finding. Confirm or dismiss every H candidate, and fix the confirmed ones.
  4. Judge every M rule the run lists at its end.
  5. Repeat steps 3 and 4. From the second round on, fix findings in place.
  6. Layout comes last on the surfaces that read the layout rules. Once the content passes, place the semantic line breaks and run step 3 once more. A rewrap of lines the content work left alone is a reflow and goes in a style commit of its own, checked with 
    --style
    . When a request puts layout before a content review, tell the principal that the order breaks this step and ask before you start.
A text passes when 
check.sh
exits 0, every H candidate is settled and no M rule is broken. M findings still open after round two go to the principal as a report, not into a third round.
  1. 读取场景对应的规则文件。
  2. 起草。 如需重写，先阅读旧文本块，根据规则重新起草，然后删除旧内容。 绝不修补旧句子。
  3. 运行 
    check.sh <surface> <file>
    。 重写时添加 
    --before <old-file>
    ；使用 
    -
    作为文件参数表示从 stdin 读取。 修复所有 F 发现。 确认或排除每个 H 候选，并修复确认的问题。
  4. 对运行结束时列出的每条 M 规则进行判断。
  5. 重复步骤 3 和 4。 从第二轮开始，直接就地修复发现的问题。
  6. 布局在读取布局规则的场景中最后处理。 内容通过后，放置语义换行，并再次运行步骤 3。 对内容处理未涉及的换行进行重新换行属于重排，应放入单独的样式提交中，并使用 
    --style
    检查。 当请求将布局置于内容审查之前时，告知负责人该顺序破坏了此步骤，并在开始前询问。
当 
check.sh
退出码为 0、每个 H 候选均已处理且没有违反任何 M 规则时，文本即通过。 第二轮后仍开放的 M 发现作为报告提交给负责人，不进入第三轮。

Who reviews

谁负责审查

  • F and H rules: 
    check.sh
    , on every surface, whenever you write.
  • M rules on tickets, tracker text and pull request bodies: a subagent reviews them before you post. It sees only the text, the surface and the rules. Your own context misses audience drift and takes compliance claims at face value. Without subagents, review it yourself and say so.
  • M rules on repository files in a pull request: the project's prose review pass. Without one, the subagent reviews them.
Chat takes no subagent. Apply its rules as you write.
  • F 和 H 规则：在每次写作时，由 
    check.sh
    对所有场景执行。
  • 工单、tracker 文本和拉取请求正文中的 M 规则：在提交前由子代理审查。 它只看到文本、场景和规则。 你自己的上下文会忽略受众变化，并轻信合规性声明。 如果没有子代理，自行审查并说明。
  • 拉取请求中仓库文件的 M 规则：由项目的散文审查流程执行。 如果没有，则由子代理审查。
聊天不需要子代理。 在写作时应用其规则即可。