维护者回复助手（agent-service-toolkit）
以 JoshuaC215 本人口吻起草 agent-service-toolkit 仓库的 Issue/PR 回复草稿，始终交由人工审核后才会发布，绝不擅自改动 GitHub 状态。
明确要求「只生成草稿供人审阅，绝不自动发布到 GitHub」，且要求断言前先核实代码（引用 path:line），无法核实要明说而非编造——这是对「代表维护者发言」这种高风险场景很到位的安全约束。
这个 Skill 能做什么，适合哪些场景？
这是 agent-service-toolkit 仓库中的一项 Claude Skill，用于以维护者 Joshua 的真实口吻起草 Issue 和 PR 的回复。它会先完整阅读 issue/PR 正文、全部评论、相关代码与交叉引用，把相关条目按功能簇归组后再动笔，确保立场一致、不与维护者此前的表态相矛盾。产出永远是待人工审核的草稿加简要理由，默认不发布、不合并、不关闭、不打标签。它还内置了该维护者实际使用的语气、常用措辞、接受/拒绝贡献的判断标准，以及通过 gh CLI 以维护者身份发布的操作规范。
读取指定 issue/PR 的完整上下文（正文、评论、代码 diff、CI 状态、是否 fork、维护者是否已回复）；双向拉取交叉引用，构建『issue + 关联 PR + 同类 PR』的簇地图，并通读维护者在整个簇内的历史表态；按类别分类并给出接受/拒绝/搁置的处置建议；以 Joshua 的口吻撰写回复草稿（含验证过的 file:line 引证或代码片段）；输出结构化批次报告（带超链接的条目、请求摘要、研究评估、需决策事项、可粘贴草稿）；等人工明确批准后，再用 gh CLI 以 body-file 方式发布评论或评论后关闭 issue，并核对 gh 登录身份必须是 JoshuaC215。
- 维护者本人（solo maintainer）借助 AI 助手做双周一次的 issue/PR 批量分诊，需要一批口吻一致的回复草稿
- 维护者需要回复堆积数月的旧 issue，想得到带道歉、姿态得体的草稿
- 处理由 AI 批量生成的 PR 时，需要严格核查 bug 是否真实可复现、是否引入破坏性默认值
- 同一功能有多个贡献者同时提交 PR，需要先聚类再统一表态，避免前后矛盾
- 需要礼貌关闭长期无动静的 issue 或婉拒新功能，同时邀请 👍 来衡量真实需求
这个 Skill 有哪些优点和局限？
- 明确的『只起草、不发布』安全边界，绝不擅自改动 GitHub 状态
- 聚类式分诊：先通读整个功能簇及维护者历史表态，避免自相矛盾的回复
- 内置具体的语气规范、常用措辞和真实的接受/拒绝判断标准，草稿高度拟人
- 详细规定了 gh CLI 本地发布流程，保证评论归属干净（无 AI 角标和页脚）
- 针对 fork PR、无法复现的 bug、AI 生成 PR 等常见场景有明确处理规则
- 强绑定特定仓库（JoshuaC215/agent-service-toolkit）和维护者个人口吻，直接迁移到其他仓库需大幅改写
- 技能引用了 DRAFT_RESPONSES_REPORT.md、docs/maintenance/ 等工作流文件，脱离该仓库环境可能缺失
- 依赖 gh CLI 且以维护者本人凭证登录，使用门槛和权限要求较高
- 当前 2026 立场偏保守（倾向拒绝/搁置贡献）， adopting 方需知悉这一倾向
如何安装这个 Skill？
该技能位于仓库的 .claude/skills/maintainer-response/ 目录（随整个仓库克隆获得）。先 git clone https://github.com/JoshuaC215/agent-service-toolkit.git，然后将 .claude/skills/maintainer-response/ 文件夹放入你的 Claude Code 技能目录。仓库其他技能与安装集合的具体说明见 README；单独安装本技能的更细步骤源材料未记载。
如何使用这个 Skill？
在 Claude Code 中以维护者身份运行，例如：『为 issue 290 起草回复』『审阅当前开放的 PR』『对这份 bug 报告起草回复』或批量分诊。技能会先做研究并聚类，再产出报告：每个条目含摘要、评估、需决策事项和可直接粘贴的草稿。人工明确批准指定条目后，才通过 gh CLI（用 --body-file 且始终带 -R JoshuaC215/agent-service-toolkit）发布；发布前用 gh api user 确认登录身份为 JoshuaC215。