ln-64-community-announcer

社区公告工具

目标： 创建有来源依据的公告，并且只在用户批准完整草稿后发布。

执行约定： 将每项清单条目标记为 PENDING、PROVEN（附观察到的结果证据）、CLEARED（附证明相关条件不存在的证据）或 UNPROVEN（附未解决的缺口）。阅读、委派、工具故障、退出状态为零以及自述成功都不能作为证明。每完成一个部分后进行核对；返回前解决所有 PENDING，仅统计 PROVEN 和 CLEARED，并对每个缺口应用判定和审批规则。 保留意图、范围、模式和现有授权。在需要外部审批之前，先完成已授权的工作；只针对尚未解决且会产生重大影响的选择提问。如果无人能够回答，报告确切问题，并应用该技能的缺口判定，不要等待或猜测。引用任何阻碍性指令和未解决的边界；切勿臆造审批关卡。根据材料风险调整深度；保留强制检查、依赖关系和安全顺序，同时选择合适的验证方法。 接受等效的用户或仓库证据，无需强制使用另一个技能、指定产物或完整生命周期。保留来源要求和决策 ID。将复用的证据与相关版本、未提交的更改、配置、环境和观察窗口绑定；仅使受影响的声明失效。 根据结果和明确选择确定主要工作流。使用相邻工作流约定和有效证据，但不重复归属或重启审计。按范围拆分不同交付物，不要强制调用特定技能。宽泛的独立评估使用审计工作流；聚焦领域的审查保持只读。 继续执行时，核对任务、授权、状态和缺口。对于耗时较长的工作，返回简洁的续接记录，或更新已获授权的产物；只读技能不保存该记录。区分产物就绪状态、已验证行为和外部操作授权。 在现有产物或回复中，将适用要求追溯至其权威归属方、计划或已实施的更改、验收证据和状态；无需新建登记表。明确约束在获授权偏离之前持续有效；风险决定优先级，而非忽略约束的许可。 调查因果流程，不要局限于最初提及的文件。在实施授权范围内，纳入实现目标所需的结构性修复；应尽量降低总体复杂性和风险，而非只减少改动行数。这不代表授权无关清理，也不允许在审查期间进行修改。 检索前，先明确证据问题；有选择地阅读，但不要跳过适用指令。使用工具进行机械处理；总结范围明确的结果、错误、覆盖范围和来源路径，并将完整输出保留在上下文之外。 在作出技术决策前，确认适用性和实际版本；对照官方文档或规范验证依赖版本的假设。查找并阅读一手页面，了解当前外部建议；搜索结果摘要不构成证据。版本匹配的内置文档或有效的既有证据足以满足要求。记录决策、版本、来源和限制。将无法获取的证据标记为 UNVERIFIED；仅阻止依赖该证据且不可或缺的工作。优先使用原生机制，并以证据说明增加工具或抽象的理由；复用现有规则的归属方。

工具路由

需求	首选能力	备选方案
仓库身份和权限	已认证的 GitHub CLI 或连接器	只读发现可使用公开 GitHub API
讨论分类和发布	GitHub GraphQL API	在目标受限的情况下继续撰写草稿；没有此能力时，发布状态为 BLOCKED
已发布变更的证据	远程 Git 历史记录、版本发布和权威文件	干净的远程克隆
命令、路径、名称和计数	针对性的仓库搜索和直接读取	通过托管平台 API 读取内容
当前外部声明	带日期的一手来源	无法核实时省略该声明
发布草稿	传递给 API 的临时 Markdown 文件	安全转义 API 输入并回读验证

优先使用托管平台 API，而不是抓取渲染后的页面。仅在检查页面呈现效果或 API 无法提供的页面时使用浏览器。

不要在公告中暴露仓库令牌、分类节点 ID 或其他凭据。ID 可用于执行变更，但不应作为面向受众的内容。

检查清单

确定范围并核实证据

• 根据请求或托管平台客户端确定目标仓库，并判断任务仅需草拟，还是还包括发布。
• 阅读默认分支并查阅源证据。在可访问的情况下，确认是否启用了 Discussions，并选择合适的分类；无法访问发布功能，不妨碍撰写经过事实核查的草稿。
• 对于仅需草拟的任务，说明目标限制并继续撰写。发布前必须确认写入权限、仓库和分类 ID，以及已启用且合适的 Discussions 分类；不要擅自发布到其他位置。
• 根据用户请求、版本发布或范围明确的提交区间，确定公告主题。
• 阅读现有的仓库沟通指南，但不要求必须存在社区策略文件。
• 阅读当前权威文档、安装说明、受影响的清单、版本说明及相关源代码差异（如有）。
• 检查近期提交和最多三篇可供参考的同类公告，了解发布节奏、反复提及的内容和项目风格；对于新建或低活跃度仓库，不要求必须有过往公告。
• 将已发布声明对应到目标远程提交或版本发布，包括落后于默认分支的发布分支；绝不要把尚未推送的本地差异描述为已可用。
• 区分已发布内容、对用户的影响、迁移需求和未来计划。

分类和风格

• 将公告归类为版本发布、重大变更、功能更新、架构变更或社区新闻。
• 选择能够说明用户收益及其意义的最简洁风格。
• 与项目的语气保持一致，同时确保读者无需了解仓库内部情况也能理解各项声明。

草拟

• 撰写具体的标题，说明带来的成果，而不只是写“更新”或“公告”。
• 开篇说明用户面临的问题，或最重要的已发布成果。
• 根据提交、文档或版本说明中的证据解释变更原因。
• 用用户收益的表述概述亮点，并在有帮助时明确指出产品、软件包、插件、技能或组件的名称。
• 如果读者需要采取行动，提供经过核实的安装或更新命令。
• 突出说明重大变更，并提供清晰的迁移前后步骤；遵循仓库格式，而不强制要求使用特定的提示框标签。
• 根据情况链接到默认分支上的权威文档或不可变的版本标签。
• 仅当工作已确定或明确标注为暂定时，才添加简短的“后续计划”部分。
• 通过用户名感谢已核实的外部贡献者；独立开发时省略此部分。
• 以一个真实且可回答的反馈问题收尾，前提是社区意见确实有帮助。

事实核查

• 对照实际发布、部署或结果证据核实有关可用性和实测效果的说法；区分已宣布的计划和已提供的功能。
• 根据当前权威文档，核实每条命令及其使用的稳定软件包、插件或市场标识符。
• 根据远程仓库，核实每个提及的产品、软件包、插件、技能、组件、文件路径、类别、版本、标签和链接。
• 根据目标提交重新计算所有数量；如果数量对用户没有价值，就不要提及。
• 根据实际修改的源代码、文档或清单核实功能描述，而不是依赖提交标题的简略说法。
• 明确说明已移除的功能和兼容性限制。
• 不要编造有关采用情况、下载量、搜索量、性能、兼容性或路线图的说法。
• 对估算、解读和未来意图明确标注，不要将其描述为已发布的事实。
• 删除笼统的炒作、重复结论、过多标题、套话式过渡和成组的填充列表。
• 以新用户的视角重新阅读草稿，确保其说明价值以及用户需要采取的操作。

审批与发布

• 创建外部状态之前，先向用户提供准确标题和完整 Markdown 正文。
• 在草稿中附上证据范围和所选类别，或说明尚未解决的发布目标限制。
• 对于仅起草的工作，完成自检后立即报告 PREPARED，无需等待；对于不适用的发布专属事项，说明其超出范围。对于发布，必须获得用户对确切文案和目标位置的明确批准；如果本会话中已批准且内容未变，则可沿用该批准。用户提出公告请求，不代表其已批准尚未查看的最终文案。
• 如果用户更改了任何实质性说法或指示，需重新核查修改后的草稿。
• 将已批准的正文写入临时文件，以保留格式并避免 shell 插值错误。
• 仅在获准发布时，核实写入权限和目标位置，然后通过 GitHub Discussions GraphQL mutation 使用已查明的仓库和类别 ID 发布。若请求仅止于草稿，则将发布专属标准标记为不适用。
• 读取讨论内容并核实标题、正文、类别和 URL。收到不确定的响应后，重试前先检查返回的 ID 或目标位置中匹配的内容；如果身份仍不明确，则停止操作，以免产生重复内容。
• 核实后安全删除临时草稿。
• 报告讨论 URL，以及 API 无法执行的任何手动操作，例如置顶。
• 除非用户明确要求，否则不要创建标签、发布版本、议题、评论或交叉发布内容。

结论

• PREPARED — 已完成事实核查的文案；发布要么超出范围，要么正在等待用户批准确切文案。
• PUBLISHED — 已成功发布获批的讨论并回读核实。
• BLOCKED — 源证据不足以支持可信草稿，或因权限、类别或验证条件不可用，无法完成用户要求的发布。需区分已完成的草稿和受阻的发布。

自检

• 返回前逐项核对。 检查各项证据、需求覆盖情况、矛盾、范围、结论和适用的清理工作。修正报告或已获授权的产物。沿用有效证据；不要自动重新扫描仓库或重跑已成功的命令。仅在相关内容变更、检查失败或证据仍未解决时重复检查。披露仍存在的缺口。

输出约定

按以下顺序使用用户的语言报告；标注全部五个字段，并且每项事实只陈述一次。使用规范、直白的语言：每句话通常少于 20 个词，只陈述一项事实，使用主动语态；每个概念只使用一个术语，不要为判定、ID 或状态使用同义词。内容较少时，每个字段可占一行；省略空表格，不要复制链接指向的工件：

1. **结果：**先写准确的技能专用判定标记，然后写有依据的结果。
2. **范围：**审查或更改的范围、排除项、基线和重大假设。
3. **证据：**填写下方技能专用字段；区分事实、推断和未经验证的说法。链接工件；适用时使用表格。
4. **验证：**检查及结果、无法获取的证据，以及适用的清理工作或外部状态。
5. 完成情况：Checklist: X/Y complete；Incomplete: None，或列出每项 UNPROVEN 的原因、对结果的影响和准确的后续操作；说明剩余风险和所需决策。

**技能专用证据：**公告分类、证据范围、目标位置／类别或限制、准确标题、审批前经过事实核查的完整 Markdown 草稿，以及事实核查摘要。发布后，提供讨论 URL 和回读验证，同时在回复历史中保留已批准的文案。报告置顶等手动操作；如果内容与已批准的文案不一致，则标记为 BLOCKED，并须先获得批准才能编辑或删除外部内容。