mcpField
P
prose-editing

prose-editing

github.com/redhat-developer文档处理1942 次安装1 天前更新
代码仓库

关于 prose-editing

prose-editing 用于修改现有文本,同时保留原有主张、条件和范围。它根据文档用途或明确指示选择编辑语体,并区分改写请求与不做修改的审查。

主要功能

  1. 01修改文本但不改变原有主张
  2. 02按用途或指示选择编辑语体
  3. 03支持改写与审查模式
  4. 04检查含义和范围是否保留
  5. 05保护代码等指定内容

适用场景

  1. 01精简技术文档
  2. 02在保留原意的同时改写公告
  3. 03不修改文本而审查问题

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/redhat-developer/rhdh-skills --skill prose-editing

安装后在 Claude Code 中输入/prose-editing确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

agents/
openai.yaml
references/
compression.md
mechanical.md
voice.md
scripts/
lint.py
NOTICE

详细介绍

文案编辑

在不改变原文主张的前提下编辑现有草稿。调用方提供文案,并在知道时提供语体。由其他技能调用此技能时,只返回文案。

选择操作

明确的编辑意图优先。即使请求同时要求指出问题或打分,改写、精简或润色的请求仍属于编辑。

只有在调用方明确要求不做修改、进行审查,或只指出问题而不改写时,才使用 audit。他人撰写的文本并不会自动成为只读内容。保护引用的第三方内容,但可根据要求改写草稿的其他部分。

选择主要语体

调用方提供的语体优先。否则,根据文档的主要用途选择:

语体主要用途加载的参考资料
strict流程、运行手册、安全文本、面向操作人员的错误信息mechanical 和完整的 compression
flavoredREADME、技术文档、PR 或 MR 正文、Jira 文案、代码注释mechanical 和 compression 的共享部分
voiced公告、社区消息、博客文章、个人文案mechanical 和 voice
audit明确要求不做修改的检查三份参考资料;建议遵循文档的主要用途

用途优先于署名。带有作者姓名的技术 README 仍属于 flavored。如果用途确实模糊,且选错会实质性改变改写结果,则提出一个有针对性的问题。否则使用 voiced,以尽量减少结构性改动。

只使用一个数值主评分。不要臆造语体映射。在混合文档中保留其主要语体,并对流程和安全章节手动应用 strict 规则。这种局部覆盖不会产生第二个评分。

如果用户提供了自己的写作样例,应先阅读样例,再阅读草稿。其稳定的句子节奏、词汇、标点、过渡方式和惯用表达应主导 voiced 编辑。样例可以作为使用破折号、弯引号、重复句首或其他单独来看证据不足的有意写作习惯的依据。

准备安全的工作副本

切勿在此已安装技能所在目录旁写入文件。使用系统临时目录 API 创建唯一目录。将以下路径保存在该目录中:

  • source.md:未经更改的快照,用于检查含义。
  • rewrite.md:评分前后唯一使用的文件;编辑此文件。
  • before.json:针对该规范化 rewrite.md 路径生成的基线报告。
  • voice.md:存在用户提供的写作样例时,保存其未经更改的快照。

对于粘贴的文本,将用户提供的字节写入 source.md,然后复制到 rewrite.md。对于用户文件,将文件复制到这两个路径,在改写通过所有保护检查之前,不要触碰原文件。宿主环境支持时使用进程参数数组。如果必须使用 shell,则为每个路径加引号,包括可信的技能目录和所有临时路径。切勿将用户控制的路径粘贴到未加引号的命令中。

用户提供写作样例时,将其原始字节精确复制到 voice.md,并在两次运行 lint 时都传入 --voice-sample "<unique-temp-dir>/voice.md"。没有样例时,两次运行都省略该选项。样例不同或已更改时,基线即不兼容。

根据此 SKILL.md 的位置解析 scripts/lint.py。不含写作样例时,对应的 shell 命令结构如下:

python "<skill-dir>/scripts/lint.py" --json --register <register> \
  "<unique-temp-dir>/rewrite.md" > "<unique-temp-dir>/before.json"

存在样例时,在语体参数后插入 --voice-sample "<unique-temp-dir>/voice.md"。

使用宿主环境的 UTF-8 文件 API,或在临时目录中使用重定向。不要使用固定的 before.json。交付后删除该唯一目录。

编辑流程

audit 可跳转到 审计。如需编辑:

  1. 加载注册表指定的参考资料。阅读所有适用规则。

  2. 对 rewrite.md 评分,并将完整 JSON 保存为 before.json。

  3. 阅读所有 violations、samples、markers 和人工检查项。评分为零并不意味着可以忽略标记或需要判断的规则。

  4. 建立内部源文清单。记录每项主张、条件、例外、范围限定、情态强度、名称、数字、版本、日期、引文、引用、标识符和安全后果。

  5. 重写 rewrite.md。尽量只修改必要的最小片段,但若多个模式集中在同一段落,则围绕该段落的具体要点重写。

  6. 根据 before.json 对同一标准化的 rewrite.md 路径评分:

    python "<skill-dir>/scripts/lint.py" --json --register <register> \
      --baseline "<unique-temp-dir>/before.json" \
      "<unique-temp-dir>/rewrite.md"
    

    如果基线使用了写作样例,请在注册表参数后插入相同的 --voice-sample "<unique-temp-dir>/voice.md" 参数。

    基线元数据或路径不匹配属于验证失败,而非评分结果。修正调用方式并重新运行。切勿重复使用来自其他注册表、引文策略、文件或检查器评分版本的报告。

  7. 最多再进行一轮重写和评分。

  8. 双向比较 source.md 与 rewrite.md。源文中的每项主张和限定条件都必须保留,输出中的每项主张也都必须源自源文或明确的用户指令。除非源文本身允许更改,否则应保留 must、should、may、can、不确定性、否定和例外。

  9. 运行人工检查清单,并进行对抗性最终审阅。自问:“还有哪些地方听起来像机器生成的?”,“有哪些事实或限制消失了?”,“这次重写增加了什么?”修复这些问题暴露出的缺陷。

  10. 只有此时,才将最终文本复制到指定位置。对于用户文件,替换其中的正文,同时保留受保护片段。对于粘贴的文本,返回重写后的内容。

如果无法运行 Python,则通过人工完成相同的参考资料、清单和对抗性检查。注明 未进行 lint 检查,且不要报告估算数量。

审计

不要重写或创建输出文档。

  1. 加载全部三份参考资料,并使用 --register audit 对提供的工作副本评分一次。
  2. 根据文档用途推断主要文风规范。将每个命中项分类为适用、超出范围或误报。
  3. 检查每个标记和每条人工规则,包括主张保留情况、写作样例冲突、重复名称/开头、冠词使用、段落焦点、重复自身内容的标题,以及空洞段落。
  4. 返回单一评分、源文主张/条件/范围清单,以及一张简明的发现表:规则、源文片段、分类和建议修改。不要做任何更改。

受保护片段与 Markdown

绝不更改围栏代码或行内代码、命令、标识符、零件编号、单位、用于搜索的错误字符串、YAML 前置内容、数据或链接目标。链接文本属于正文。若上下文表明被引用的第三方语言是引文、标题、讨论中的示例或外部所有内容,则应予保留。

引用块、标注块和表格单元格并非天然属于引文。应对其中的第一方正文进行检查和编辑。只有在调用者明确指出正文内容是必须排除的示例或第三方引文时,才使用 --quote-safe。该选项只会抑制这些受保护区域中的检查结果,不得隐藏文档其他位置的普通第一方正文。

阅读报告

使用完整的 JSON 对象。切勿仅凭退出代码作出判断。

键含义
violations 和 samples高置信度计数,会计入评分,并附有示例
markers可能存在的问题,需要结合上下文判断,不计入评分
by_layer负责各个评分类别的参考层
manual_checks检查器无法验证的规则
file_identity、voice_sample_identity可确保基线比较安全的规范输入
delta兼容基线的 before、after 和 improved 值
total_per100w一项主要密度评分,不代表质量结论
fail_over、over_fail_over调用方可选提供的有限、非负 CI 阈值及其结果;未使用 --fail-over N 时不存在

单例转换、弯引号、长破折号、简短有力的句子和刻意重复都只是标记,不能证明文本由机器撰写。只有当它们形成参考文档所述的重复模式或聚集模式时,才计入评分。在 voiced 模式下,提供的语气样本优先于这些风格默认值。

交付

调用方返回内容
负责编辑最终外发文本的另一项技能仅返回最终文本;在对话记录中保留语体和评分元数据
粘贴了文本的人返回最终改写、语体、评分变化和未解决的问题
提供了文件的人编辑文件,然后报告语体、评分变化和未解决的问题
明确要求 audit返回问题和一项评分;不改写

另一项技能在完成所有自由文本的编写后、展示、设置门槛或发布这些文本前,恰好调用此流程一次。传输层不得调用此流程。不得自动将其应用于结构化负载、命令、校验和、生成的报告、ADR、AGENTS 文件、技能、PRD 或其他由专门编写技能负责的本地文档。用户明确提出请求时,仍可编辑任何文本文档。

完成

只有满足以下条件,工作才算完成:

  • 操作和主要语体符合调用方的意图;
  • 前后报告来自相同的规范 rewrite.md、语气样本、评分版本、语体和引号策略,否则应注明 未运行检查;
  • 每项评分违规、标记和适用的人工规则均已修复、以具体的误报理由驳回、在审计中归类为不属于该语体,或报告为未解决;
  • 双向清单证明没有遗漏源文本中的任何主张、范围限制、条件或情态力度,也没有添加无依据的主张;
  • 受保护的字节保持不变;
  • 对抗性最终复核未发现其他未报告的问题;
  • 交付方式符合上表;并且
  • 唯一临时目录已删除。

评论

支持 Markdown