ln-914-community-responder

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

ln-914-community-responder

类型： L3 Worker（独立运行） 类别： 9XX 社区互动 通过分析问题、在代码库中搜索答案并撰写有帮助的回复，响应尚未回复的 GitHub Discussions 和 Issues。支持单条和批量模式。

---

概述

方面	详情
输入	$ARGUMENTS：讨论 / Issue 编号（#42）、batch（所有未回复的 P1 项目）或留空（交互模式）
输出	发布到 GitHub 的回复评论
模式	阅读问题 → 搜索代码库 → 撰写回复 → 核实事实 → 发布

---

阶段 0：发现 GitHub 信息

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

执行发现协议。提取：

• 用于 URL 和 API 调用的 {owner}/{repo}
• 用于 GraphQL mutations 的 repo.id
• maintainer 登录名（已认证用户）
• 讨论类别 ID

加载策略：检查目标项目中的 docs/community_engagement_strategy.md，若不存在则使用 references/community_strategy_template.md。提取第 5 节（互动指标）和第 6 节（语气指南）。

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

---

阶段 1：加载条目

单条目模式

如果 $ARGUMENTS 包含数字（例如，42、#42）：

# For discussions
gh api graphql -f query='query($owner: String!, $name: String!) {
  repository(owner: $owner, name: $name) {
    discussion(number: {N}) {
      id number title body
      category { name }
      author { login }
      createdAt
      answerChosenAt
      comments(first: 20) {
        totalCount
        nodes { author { login } body createdAt }
      }
    }
  }
}' -f owner="{owner}" -f name="{repo}"

# For issues (if discussion not found)
gh issue view {N} --repo {owner}/{repo} --json number,title,body,author,createdAt,comments,labels

批量模式

如果 $ARGUMENTS 为 batch：

1. 通过 GraphQL 获取最近的讨论和 Issue（最近 30 天、开放状态，按创建时间降序排列）
2. 筛选 P1 条目：作者 != maintainer 且 maintainer 评论数为 0
3. 获取每个条目的完整上下文（每批最多 10 条）

交互模式

如果 $ARGUMENTS 为空，列出最近尚未回复的条目，并询问用户要回复哪一条。

---

阶段 2：分析上下文

针对每个条目：

2a. 理解问题

1. 阅读讨论 / Issue 正文——识别核心问题或疑问
2. 阅读现有评论——检查是否已有部分解答，或后续评论是否改变了问题范围
3. 检测条目类型：问答问题、Bug 报告、功能请求、配置帮助、一般反馈

2b. 在代码库中搜索答案

根据问题类型搜索相关信息：

问题类型	搜索策略
“如何……”	在 SKILL.md 文件、README.md、docs/ 中搜索关键词
Bug 报告	搜索提及的函数 / 文件，并检查 git log 中是否有近期修复
配置	阅读 .hex-skills/environment_state.json、CLAUDE.md 和相关 SKILL.md
功能请求	检查该功能是否已存在，并搜索相关模式
安装	阅读 README.md 的安装部分和 plugin.json

FOR each item:
  1. Extract keywords from question (function names, skill names, error messages)
  2. Grep codebase for keywords (max 5 searches)
  3. Read relevant files (max 3 files, prioritize SKILL.md and docs/)
  4. Check git log for recent changes related to the topic
  5. If answer found → proceed to Phase 3
  6. If not found → mark as "needs-manual" and suggest the user respond directly

2c. 检测首次发帖者

gh api graphql -f query='query($owner: String!, $name: String!) {
  repository(owner: $owner, name: $name) {
    discussions(first: 100) {
      nodes { author { login } }
    }
  }
}' -f owner="{owner}" -f name="{repo}"

统计作者创建过多少个讨论。如果之前创建的讨论数为 0（这是他们第一次发帖）→ 标记为欢迎风格。

---

阶段 3：分类回复类型

必须读取： 加载 response_styles.md——使用分类矩阵。

条目类型	回复风格
已找到答案的问答问题	技术解答
Bug 报告	Bug 确认
功能请求 / 想法	功能确认
已在其他位置解答的问题	引导
首次发帖者（任何类型）	欢迎 + 相应的内容风格
有进展更新的过时条目	状态更新
无法在代码库中找到答案	标记为 needs-manual——跳过撰写

---

阶段 4：撰写回复

使用 response_styles.md 中选定风格的模板。

所有风格均需包含的要素

• 感谢作者——尽可能称呼作者姓名，并肯定其贡献
• 回答问题——直接、清晰，并链接到源代码或文档
• 邀请对方继续交流——例如：“如果这对你有帮助，请告诉我们。”
• 避免使用未作说明的术语——解释内部术语
• 链接到代码——至少提供一个指向仓库中相关文件的链接

批处理模式的撰写方式

在批处理模式下，先撰写所有回复，然后将全部回复交由用户审核，再发布任何回复。

---

阶段 5：事实核查

在向用户展示之前，核实每项说法：

1. 文件路径和链接——确认每个链接指向的文件都存在：ls {path}

2. 代码引用——确认提及的函数／类确实存在：grep -r "{name}"

3. 功能描述——重新阅读源文件，确认描述准确

4. 安装／使用命令——对照 README.md 核实

5. 语言自然度审查——运行 humanizer_checklist.md 中的审查流程。如果发现 3 个或更多 AI 写作特征，则改写标记出的部分。

**关卡：**如果任何检查未通过，请先修正回复，再继续。

---

阶段 6：审核与发布

单项模式

向用户展示撰写好的回复。等待用户明确批准后再发布。

批处理模式

在摘要表格中展示所有回复：

### Batch Responses — {N} items

| # | Type | Title | Style | Status |
|---|------|-------|-------|--------|
| {number} | {Discussion/Issue} | {title} | {Technical/Bug/Welcome/...} | Ready |
| {number} | ... | ... | ... | needs-manual |

然后展示每条回复的正文。用户可以全部批准、选择性批准，或单独编辑某条回复。

发布讨论评论

gh api graphql -f query='
  mutation($discussionId: ID!, $body: String!) {
    addDiscussionComment(input: {
      discussionId: $discussionId,
      body: $body
    }) {
      comment { url }
    }
  }
' -f discussionId="{discussion.id}" -f body="{response body}"

发布议题评论

gh issue comment {number} --repo {owner}/{repo} --body "{response body}"

向用户报告评论 URL。

---

规则

• 发布任何回复前，必须始终征得用户批准
• 绝不关闭讨论或议题——只需回复
• 绝不标记为已回答——留给作者处理（适用于问答讨论）
• **批处理上限：**每批最多 10 项（避免上下文过载）
• **需要人工处理的项目：**向用户报告 GitHub URL 和原因，不要尝试回复
• **语气：**遵循策略第 6 节——尊重、乐于助人，并链接到代码

---

完成标准

• 已加载项目（单项、批处理或交互式选择）
• 已分析问题背景，并搜索代码库以查找答案
• 已根据 response_styles.md 对回复类型进行分类
• 已识别并欢迎首次发帖者
• 已撰写回复，并附上相关代码／文档链接
• 已完成事实核查（已核实文件路径、代码引用和命令）
• 用户已批准回复
• 已通过 GraphQL／CLI 发布，并报告评论 URL
• 已向用户报告需要人工处理的项目及其 URL

---

**版本：**1.0.0 **最后更新：**2026-03-14