ln-912-community-announcer

**路径：**文件路径（references/、../ln-*）均相对于此技能目录。

ln-912-community-announcer

**类型：**L3 Worker（独立） **类别：**9XX 社区互动 撰写结构化公告并发布到 GitHub Discussions（Announcements 分类）。

---

阶段 0：GitHub 信息发现

**必须阅读：**加载 references/community_github_discovery.md

执行信息发现流程。提取：

• 用于 URL 和 git 命令的 {owner}/{repo}
• 用于 GraphQL mutation 的 repo.id
• 用于发布的 categories["Announcements"] 分类 ID
• 确认 Announcements 分类存在

加载策略：检查目标项目中的 docs/community_engagement_strategy.md，若无则使用 references/community_strategy_template.md。提取第 2 节（公告触发条件）和第 6 节（语气指南）。

**必须阅读：**加载 references/community_discussion_formatting.md **必须阅读：**加载 announcement_styles.md **必须阅读：**加载 references/humanizer_checklist.md

---

阶段 1：收集上下文

1. 阅读策略第 2 节——确认此事项符合公告条件
2. 阅读 CHANGELOG.md——提取最新条目（若提供了 $ARGUMENTS 日期，则提取对应日期的条目）
3. 阅读 README.md——检查当前版本徽章以及任何 WARNING/IMPORTANT 提示
4. 运行：git log --oneline -20——了解近期提交
5. 若 $ARGUMENTS 包含主题关键词（而非日期），则将其用作公告主题
6. 运行：git diff --name-only（未提交更改）或 git diff --name-only HEAD~1..HEAD（最近一次提交）——整理更改文件列表
7. 阅读 diff 中的关键源文件（最多 5 个文件，根据与 $ARGUMENTS 主题的相关性排序）：
   • diff 中的协议/指南文件 -> 阅读全文（了解实质内容）
   • diff 中的 SKILL.md 文件 -> 仅通过 git diff -- {file} 阅读更改部分
   • 参考文件 -> 若有重大更改则阅读
   • 目标：了解 CHANGELOG 未明确说明的更改缘由

---

阶段 2：分类并选择风格

2a. 确定公告类型

类型	触发条件	表情符号
发布	CHANGELOG 中有新版本	:rocket:
破坏性变更	README 中有 WARNING 提示，或 CHANGELOG 中出现 “breaking”	:warning:
新功能	CHANGELOG 中有新功能条目	:sparkles:
架构	结构性更改（新增分类、拆分插件）	:building_construction:
社区	非技术更新（活动、里程碑）	:people_holding_hands:

2b. 选择风格

根据公告类型，使用 announcement_styles.md 中的 风格选择矩阵挑选主要风格。检查 Discussions 中最近 3 条公告——若它们都使用相同风格，则选择其他风格以增加变化。

也可混合风格：采用一种风格的开场钩子和另一种风格的正文（见 announcement_styles.md 中的风格混合表）。

---

阶段 3：撰写公告

以 announcement_styles.md 中选定风格的模板为结构基础，并使用 discussion_formatting.md 了解 GitHub Markdown 语法。

必需元素（所有风格均适用）：

• 在 ### What's Next 后添加 ### Contributors 小节——如适用，通过 @mention 感谢贡献者（独自完成的工作可跳过）
• 添加页脚：*完整变更日志：[CHANGELOG.md](https://github.com/{owner}/{repo}/blob/{default_branch}/CHANGELOG.md)*
• 若有破坏性变更：在 > [!IMPORTANT] 提示中加入迁移步骤，并清楚展示更改前后的差异
• 以互动问题结尾（参见 announcement_styles.md 中的 Writing Quality 检查清单）

---

第 4 阶段：事实核查

向用户展示之前，核实草稿中的每项可验证声明：

1. 命令和代码块——在 README.md 中搜索草稿里的每条命令或代码片段。如果找不到命令 → 替换为实际命令。切勿编造安装或更新命令。

2. 文件路径和链接——验证每个链接指向的文件是否存在：ls {path}。移除或修正无效链接。

3. 数字——根据实际数据核实提及的数量：git diff --name-only | grep -c SKILL.md 或 ls -d ln-*/SKILL.md | wc -l。

4. 功能描述——重新阅读关键源文件（来自第 1 阶段第 7 步），确认草稿准确描述了变更内容。不得臆造功能。

5. 名称——核实名称与仓库中的实际目录名和文件名一致。

6. Humanizer 审查——按照 humanizer_checklist.md 中的审查流程执行检查。如果发现 3 个或更多 AI 特征，重写标记出的部分。

**关卡：**如果有任何检查未通过，先修正草稿再继续。

---

第 5 阶段：审核和发布

向用户展示撰写好的公告标题和正文。等待用户明确批准后再发布。

获得批准后，使用发现上下文通过 GraphQL 发布：

gh api graphql -f query='
  mutation($title: String!, $body: String!, $repoId: ID!, $catId: ID!) {
    createDiscussion(input: {
      repositoryId: $repoId,
      categoryId: $catId,
      title: $title,
      body: $body
    }) {
      discussion { url }
    }
  }
' -f title="TITLE_HERE" -f body="BODY_HERE" -f repoId="{repo.id}" -f catId="{categories.Announcements}"

将讨论链接报告给用户。

**注意：**API 不支持置顶——如果公告很重要，提醒用户在 GitHub 界面中手动置顶。

---

第 6 阶段：交叉发布（可选）

如果公告属于版本发布或重大变更，建议：

1. 如果存在版本标签，创建匹配的 GitHub Release：gh release create vX.Y.Z --notes "See discussion: URL"
2. 如果公告改变了项目范围，更新仓库描述

---

完成标准

• 已收集上下文（CHANGELOG、README、git log、关键源文件）
• 已确定公告类型并选择风格（与最近 3 次不同）
• 已使用所选风格模板和格式规则撰写草稿
• 已通过写作质量检查清单（announcement_styles.md）
• 已完成事实核查（已核实命令、路径、数字、描述和名称）
• 用户已批准最终草稿
• 已通过 GraphQL mutation 发布，并报告链接

---

版本： 1.0.0
最后更新： 2026-03-13