README 发布同步
当任务涉及 README 副本、发布说明、更新日志、产品截图/GIF 或双语产品文档时，请使用此技能。
目标是减少维护者的审查负担：在审查者发现过时的名称、截图、功能描述或中英不匹配之前，文档应与实际产品状态保持一致。
核心规则
不要仅基于现有文档编辑面向用户的文档。首先识别当前的真实来源：应用程序代码、UI 字符串、截图/GIF、发布分支、版本文件、包元数据或用户提供的最新截图/视频。
工作流
-
锚定目标状态
- 从仓库文件或用户明确指令中确认产品/应用程序名称、分支、版本、二进制文件名和平台范围。
- 检查相关实现或 UI 字符串中正在描述的功能。
- 将用户提供的最新截图/视频视为权威视觉证据，除非代码或分支上下文明显矛盾。
-
同步文档和媒体
- 当 UI 发生变化时，替换过时的截图/GIF。
- 验证每个图片引用都存在且指向预期文件。
- 检查截图是否与当前产品名称、菜单标签、版本或 UI 状态明显矛盾。
- 移除描述已删除行为的旧媒体引用。
- 对于由私有仓库提供内容的公开发布，在清洗后的快照复制到公开仓库后，在公开仓库的
release/vX.Y.Z分支上更新公开 README 文件。不要将私有 README 作为最终公开的真实来源。 - 将公开的
CHANGELOG、发布草稿说明、安装文档和公开开发日志视为同一发布文档集的一部分。它们应使用与 README 相同的产品名称、版本、资源名称、隐私声明和面向用户的措辞。
-
保持双语文档等价
- 逐条比较英文和日文部分。
- 在两种语言中保留相同的产品事实、功能顺序、注意事项和设置要求。
- 不要将重要的行为只用一种语言解释。
-
编写可读的公开 README 副本
- 使首次阅读部分易于浏览：短段落、每段一个主题、空白行以提高可读性。
- 以产品做什么以及用户可以看到或做什么开头。将实现细节放在后面，仅当它们对设置、安全或故障排除重要时才提及。
- 优先使用清晰的行为描述，而不是冗长的功能句子。一个好的结构是一句概述后跟 2-4 行简洁的能力描述。
- 对于 UI 行为，描述可见结果：拖拽移动、从边缘或角落调整大小、双击重置。避免内部框架细节，如命中带、光标矩形、缩放内部逻辑或精确默认百分比，除非用户需要它们。
- 将详细信息保留在真正有用的地方，但不要让公共 README 承载仅供维护者使用的实现说明。
- 对发布说明和更新日志条目应用相同的可读性规则：避免内部精度，如精确默认百分比、命中带措辞、光标矩形机制或构建系统琐事，除非它影响用户可见的修复、安装步骤或故障排除路径。
-
使日语对读者友好
- 在自然的情况下优先使用普通的日语 UI 术语：例如
タブ、詳細パネル、マウスオーバー、最小表示、フローティングタブ。 - 将技术性文字（如命令、路径、包名、应用名、URL 和代码标识符）保留为英文。
- 删除冗余的功能列表和重复的段落；使主要功能集对一般日语读者快速可扫描。
- 在自然的情况下优先使用普通的日语 UI 术语：例如
-
扫描陈旧的产品差异
- 旧产品名称、旧应用名、旧二进制文件名和旧仓库名。
- 历史更新日志条目之外的旧版本号。
- 过时的 UI 标签、已删除的平台说明和旧行为的截图。
- 暗示某个依赖项必须正在运行而实际仅需要安装 CLI 或包的声明。
-
关闭前验证
- 在可用时运行相关的文档 lint/check 命令。
- 运行有限的
rg扫描以查找过时的名称/版本/标签。 - 对 README 文件、更新日志、发布说明以及发布中附带的任何公开文档进行过时/私有/过于内部措辞的扫描，而不仅仅是顶层 README。
- 检查 README 图片链接是否存在。
- 对于发布 PR，向维护者提供分支/PR 的 GitHub 渲染 README URL，并等待明确的视觉审批。这必须与用户实际看到的 GitHub 显示一致；本地预览、原始 Markdown、静态截图或自动化检查仅作为辅助证据。
- 检查公共仓库的
git diff，确保 README 声明、版本元数据、发布资源名称和复制的实现变更一致。 - 对于公开发布，优先使用
release/vX.Y.Z分支 -> PR -> CI -> 合并，然后再打标签或创建 GitHub Release。只有在维护者明确要求跳过 PR 门控时才应直接推送到main。 - 如果代码发生了变化，运行相关的测试或构建。
- 总结真实来源检查的结果，而不仅仅是编辑过的文件。
输出检查清单
在完成之前，报告：
- 产品名称/版本/分支已检查；
- 媒体引用已检查；
- 日文/英文对等性已检查；
- GitHub 渲染 README 视觉审批已收到，或明确仍待处理；
- 过时措辞扫描结果；
- 测试/构建/文档检查已执行，或未执行的原因。