ln-913-community-debater

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

ln-913-community-debater

类型： L3 Worker（独立） 类别： 9XX 社区参与 在 GitHub Discussions 中发起结构化辩论，供需要社区意见的决策参考。

---

阶段 0：发现 GitHub 信息

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

执行发现流程。提取：

• 用于 URL 和代码库上下文的 {owner}/{repo}
• 用于 GraphQL mutation 的 repo.id
• 用于 RFC/提案讨论的 categories["Ideas"]
• 用于优先级投票的 categories["Polls"]
• 确认所需类别均存在

加载策略：检查目标项目中的 docs/community_engagement_strategy.md，若不存在则使用 references/community_strategy_template.md。提取第 3 节（辩论触发条件）和第 1 节（决策矩阵）。

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

---

阶段 1：确定主题

如果提供了 $ARGUMENTS，则将其用作主题种子。否则，询问用户想讨论什么主题。

收集上下文：

1. 阅读策略第 3 节——确认该主题符合辩论条件
2. 在代码库中搜索与主题相关的文件
3. 阅读相关的 SKILL.md 文件、文档或共享参考资料
4. 找出提案可能会改变的现有模式

---

阶段 2：确定辩论类型

类型	前缀	类别	适用场景
维护者 RFC —— 设计基本完成，征求验证意见	[RFC]	Ideas	设计流程结束时，进行非正式公告
社区 RFC —— 处于早期阶段，欢迎提出其他方案	[RFC]	Ideas	设计流程开始时，启动讨论
提案 —— 新功能或结构调整	[Proposal]	Ideas	有具体想法和使用场景
工作流变更 —— 流水线、任务流程或约定	[RFC]	Ideas	影响多个领域或用户工作流
优先级排序 —— 接下来开发什么、功能排名	[Poll]	Polls	有多个选项，需要社区投票

如果类型是 优先级排序，则切换到投票流程（阶段 4）。

---

阶段 3：撰写 RFC 讨论

使用 discussion_formatting.md（已在阶段 0 加载）中的 RFC 结构模式。

此技能在共享模式之外的特定补充：

• 在开放问题之后添加 ## 尚未解决的细节 部分——列出尚未确定的实现细节，并在开发期间解决
• 添加 ## 决策标准 部分——说明如何做出决策（指标、反馈门槛）
• 备选方案表格中至少包含 2 个备选方案

---

阶段 4：撰写投票（适用于优先级排序类型）

GitHub Discussions 投票只能通过 UI 创建。因此，请撰写基于回应的投票讨论：

## {Topic}

{1-2 sentence context}

**Vote by reacting to the options below** (each option is posted as a separate comment -- use :+1: to vote).

### Context
{Why this decision matters now}

创建讨论后，将每个选项分别发布为评论，以便通过回应进行投票。

---

阶段 5：事实核查

向用户展示草稿前，核实其中每项可验证的陈述：

1. 文件路径和链接——确认每个链接的文件都存在：ls {path}。移除或修复失效链接。
2. 代码引用——确认提及的函数或模式确实存在：grep -r "{name}"。
3. 备选方案准确性——重新阅读源文件，确认备选方案表格准确描述了权衡取舍。不得虚构优缺点。
4. 名称——确认技能名称、目录名称、配置键与代码库的实际状态一致。
5. 去 AI 化检查——按照 humanizer_checklist.md 中的审核流程执行检查。如果发现 3 个或更多 AI 写作模式，重写标记的部分。

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

---

阶段 6：审核并发布

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

获得批准后，使用发现阶段收集的上下文，通过 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 id }
    }
  }
' -f title="TITLE_HERE" -f body="BODY_HERE" -f repoId="{repo.id}" -f catId="{categories.Ideas or categories.Polls}"

对于 投票，创建讨论后，将每个选项作为评论发布：

gh api graphql -f query='
  mutation($discussionId: ID!, $body: String!) {
    addDiscussionComment(input: {
      discussionId: $discussionId,
      body: $body
    }) {
      comment { url }
    }
  }
' -f discussionId="DISCUSSION_NODE_ID" -f body="**Option N:** {description}"

向用户提供讨论 URL。

---

规则

• 发布前，始终先向用户完整展示拟定文本以供审批
• 未经用户明确确认，绝不发布
• 标题：描述性标题，不超过 80 个字符，并以 [RFC]、[Proposal] 或 [Poll] 为前缀
• 正文：客观陈述，不带说服意味——中立地列出各种选项
• 添加指向仓库中相关代码/文档的链接
• 适用时，设定决策时间线
• Alternatives 表格中至少包含 2 个备选方案
• 语气：“我们正在考虑 X。以下是各种权衡。你怎么看？”

---

完成定义

• 已明确主题，并收集了代码库背景信息
• 已对讨论类型进行分类（RFC/Proposal/Workflow/Prioritization）
• 已撰写包含至少 2 个备选方案的 RFC 或投票帖
• 已完成事实核查（链接、代码引用、备选方案准确性、名称）
• 已通过 Humanizer 审查（AI 特征少于 3 项）
• 用户已批准最终草稿
• 已通过 GraphQL mutation 发布，并报告 URL

---

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