核心能力
apollo-issue-review 是一套针对 Apollo 配置中心生态的 GitHub Issue 审查工作流，采用「分类优先」策略：先判定 Issue 类型为「行为/回归问题」还是「咨询/支持问题」，再执行差异化验证路径——前者要求本地最小复现，后者依赖代码库证据扫描。该 Skill 强调直接回应用户诉求、明确支持边界、提供可立即执行的下一步路径，而非陷入冗长辩论。
显著优点
1. 结构化工作流：从输入收集、类型判定、验证执行到回复起草，六步流程清晰可执行，降低审查遗漏风险。
2. 语言自适应：根据 Issue 标题/正文/评论自动识别主语言（中英），输出匹配语言的本地化章节标签（如「复现结论」「当前能力与边界」）。
3. 防重复机制：若已有评论正确回应，仅追加增量修正，避免信息噪音。
4. 贡献者友好：检测到「认领」意图时，先鼓励后评估，给出具体可行性边界与实现建议。
5. 发布安全闸：默认仅生成草稿，需显式确认（「发布」/「post」）后才调用 GitHub API，防止误操作。
潜在局限
- 外部依赖敏感：重度依赖
ghCLI 或 GitHub REST API 稳定性，网络波动时需降级到curl回退。 - 复现成本：行为类问题要求维护者本地构建最小复现，对大型 Apollo 多模块项目可能耗时。
- 权限隐式要求：实际生效需具备 Issue 评论写入权限，Skill 本身不校验 Token 作用域。
- OpenAPI 路径易混淆：虽强制区分 Portal Web API 与
/openapi/v1/*端点，但用户原始 Issue 可能表述不清，需人工二次确认。
适合人群
- Apollo 官方维护者及核心贡献者
- 负责 Issue triage 的社区管理员
- 需批量处理社区反馈、标准化回复格式的一线开发者
常规风险
| 风险项 | 说明 |
|--------|------|
| 信息泄露 | 起草回复时可能引用内部路径或配置片段，需人工脱敏后再发布 |
| 误判类型 | 将行为问题误归为咨询问题会导致未复现即结论，反之则增加无效复现成本 |
| API 限流 | 高频调用 GitHub API 可能触发速率限制，建议搭配 Token 池或缓存策略 |
| 结论过时 | 基于特定代码快照的「当前不支持」结论，可能随版本迭代失效，需定期复核 |