这个 Skill 能做什么，适合哪些场景？
这是为 JoshuaC215/agent-service-toolkit 仓库量身定制的维护者回复技能。它会在起草前完整研究 issue/PR 的正文、评论、代码 diff 以及整个关联簇（相互引用的 issue、PR 和兄弟 PR），并保持与维护者已有表态一致。所有输出都是供人工审阅的草稿加简短理由说明，绝不在未获明确指示的情况下发帖、合并、关闭或打标签。它还内置了维护者的语气风格、接受/拒绝启发式规则（2026 年起更保守），以及通过 gh CLI 本地发帖且保持真实署名的操作流程。
- 读取 issue/PR 全文、全部评论、相关代码与 diff（fork PR 无法本地打开时按描述措辞，不作断言）
- 构建关联簇映射：Fixes/Closes 链接、引用、触及相同功能的兄弟 PR，并阅读维护者在整个簇中的历史评论
- 按类别分类（使用问题、bug 报告、功能请求、好 PR、需设计讨论、垃圾内容、安全报告）并给出接受/拒绝/搁置倾向
- 以 Joshua 的口吻起草回复草稿（含理由说明），报告中的 issue/PR 编号均带超链接
- 默认只写草稿；仅当人工明确指定项目后才通过 gh CLI 以 body-file 方式发帖，且不加任何 AI 署名
- 仓库维护者本人批量分诊积压的 issue 和 PR，需要风格一致、不违背既有表态的回复草稿
- AI 维护代理在每两周的分诊周期中代为起草回复，再由人工逐条确认后才发帖
- 需要回复一个功能请求，但希望先按启发式规则（是否可配置、是否低维护、是否已有集成）决定接受还是婉拒
- 面对相互关联的 issue 与多个 PR（同一功能多人同时实现），需要统一立场而非互相矛盾的逐条回复
- 处理疑似 AI 批量生成的 PR，需要核实 bug 真实性、测试覆盖与 CI 状态后再回复
- 需要以维护者本人身份发帖，且评论不带 Claude 应用徽章或生成脚注
- 想让它自动批量回复、关闭或合并 GitHub 项目的用户——它默认绝不改写 GitHub 状态，发帖需要逐条人工放行
- 其他仓库的维护者——语气库、决策启发式、短语和 CI 命令（ruff/pyrefly/pytest）都针对 agent-service-toolkit 定制，移植需要大幅改写
- 不熟悉 gh CLI 或无法以 JoshuaC215 身份认证的环境——本地发帖规则明确要求先确认 gh api user 为 JoshuaC215，否则应停止
如何安装这个 Skill？
- Shell / 命令行
- 网络访问
- 本地文件系统
GitHub CLI (gh) authenticated as JoshuaC215
该技能位于仓库的 .claude/skills/maintainer-response/SKILL.md，随整个 agent-service-toolkit 仓库分发（README 未记载独立的技能安装命令）。把它放到项目的 .claude/skills/ 目录即可：
git clone https://github.com/JoshuaC215/agent-service-toolkit.git
cp -r agent-service-toolkit/.claude/skills/maintainer-response <你的项目>/.claude/skills/注意：这是同一仓库打包的 4 个技能之一，本条目只描述 maintainer-response 这一个。
如何使用这个 Skill？
安装后，把下面任意一句发给 Agent 即可触发：
- 帮我回复 agent-service-toolkit 的 issue 290，起草一段 Joshua 口吻的回复，先不要发
- 审阅这个仓库当前开放的 PR，按关联簇整理成一份带草稿的分诊报告
- 给这个没有复现步骤的 bug 报告起草一条索要复现信息的简短回复
- 有人提了个新功能请求，先按接受/拒绝启发式给我一个建议和草稿
触发方式是对仓库中具体 issue/PR 的分诊请求（如“回复 issue 290”“审阅开放的 PR”）。技能会按固定流程执行：识别项目并拉取全部上下文 → 建立关联簇映射并通读维护者的既有评论 → 逐簇分类并确定接受/拒绝/搁置倾向 → 用 Joshua 的口吻起草 → 输出报告（每项含摘要、研究评估、需人工决策的事项与建议、可粘贴的草稿，编号带超链接，草稿用围栏块包裹）→ 等待人工决定。只有人工明确放行具体项目后才发帖：用 gh issue comment / gh pr comment 加 --body-file，始终带上 -R JoshuaC215/agent-service-toolkit，发帖前用 gh api user --jq .login 确认身份；issue 编号与 PR 编号的命令不可混用。
这个 Skill 有哪些优点和局限？
- 起草前强制研究整个关联簇并遵循维护者既有立场，避免互相矛盾或重复提问的回复
- 明确的防幻觉规则：技术断言须在仓库中核实并给出 path:line 引证，无法复现就索要复现步骤
- 内置可用的语气库、常用短语、CI/lint 命令块和按类别的回复模式，草稿即拿即用
- 署名处理交代得很细：通过本人 gh CLI token 发帖即无应用徽章和生成脚注，并给出具体命令
- 高度绑定单一仓库和维护者个人，换仓库或换人基本要重写
- 默认保守的 2026 年立场（倾向拒绝/搁置）是写死在文件里的，不适合想积极吸纳贡献的维护者
- 多步工作流（研究、聚类、报告、等待放行）对只需快速回一条评论的场景偏重
- README 与技能文档之外没有针对此技能本身的独立测试或验证证据
这个 Skill 与同类方案有什么区别？
与相关 Skills 并排比较；分数均按同一 FSRS 标准得出。
| Skill | FS 评分 | Star 数 | 最近更新 | License |
|---|---|---|---|---|
| 维护者回复助手（agent-service-toolkit 专属） 本页 | 69 · 推荐 | ★ 4.5k | 21 天前 | MIT |
| CODEOWNERS 分组拆分 PR ✓ NVIDIA · 官方 | 57 · 谨慎使用 | ★ 3.6k | 11 天前 | Apache-2.0 |
| RenderCV Issue 解决器 | 51 · 谨慎使用 | ★ 18k | 7 个月前 | MIT |
| Poll GitHub Work — GitHub 维护工作轮询与排期 | 52 · 谨慎使用 | ★ 30k | 11 天前 | MIT |
| babysit — PR 自动值守技能 | 54 · 谨慎使用 | ★ 10k | 11 天前 | Apache-2.0 |
FollowSkills 如何评估这个 Skill？
明确要求「只生成草稿供人审阅，绝不自动发布到 GitHub」，且要求断言前先核实代码（引用 path:line），无法核实要明说而非编造——这是对「代表维护者发言」这种高风险场景很到位的安全约束。
点击维度查看打分理由
证据充分度：低 — 主要依赖静态检查、作者材料或有限演示；适合发现线索，不适合做高风险决策。
本条评估按 FSRS 1.0 标准完成，维度分不做换算，已进入按 FSRS 2.0 重新评估的复核队列。
查看完整评分方法 →