这篇文章怎么用
你可以把下面每个模板当成一个独立 Skill（单步或小工作流）。建议做法：
- 先复制模板到你的
skills/<name>/SKILL.md - 再补齐输入输出契约（至少 5 个字段）
- 最后加 10 条回归样本（happy + edge + failure）
模板 1：PR Summary（只读，最适合入门）
- 目标：生成结构化 PR 摘要与风险点
- 工具：GitHub 只读
- 输出：JSON（summary/changes/risks/followups）
关键护栏：
- 不决定是否发布
- 必须引用 diff/commit 证据（或至少列出文件路径）
模板 2：Code Review Lint（可选写，默认草稿）
- 目标：按团队规范做 code review 评论草稿
- 工具：repo 搜索、静态分析结果读取（只读）
- 输出：评论草稿（分严重等级）
关键护栏：
- 写操作需要确认点（发布评论前人工审核）
- 对“风格争论”降级为建议，不做阻塞
模板 3：Release Notes Generator（工作流）
- 目标：从 PR/commit 自动生成 release note
- 工具：GitHub 只读 + 发布系统写（可选）
- 输出：分组的变更清单（feature/fix/breaking）
关键护栏：
- 写发布页前必须确认点
- 对 breaking changes 需要显式证据（commit message/label）
模板 4：Incident Triage（排障助手）
- 目标：从告警与日志中产出“排障假设 + 证据需求 + 下一步”
- 工具：日志系统只读、指标系统只读
- 输出：结构化 triage（hypotheses/evidence/next_actions）
关键护栏：
- 不直接执行修复操作（只建议）
- “证据不足”必须显式标记
模板 5：Log Explainer（日志解释器）
- 目标：把一段日志解释成“发生了什么 + 可能原因 + 建议排查”
- 工具：可选（知识库检索）
- 输出：固定小节（避免散文）
关键护栏：
- 不输出敏感信息（脱敏）
- 不把猜测当结论（必须区分）
模板 6：SQL Draft + Safety Gate（SQL 草拟 + 安全门）
- 目标：根据自然语言生成 SQL + 风险提示（全表扫描/删除）
- 工具：schema 只读、执行前确认点
- 输出：SQL + 执行成本预估（粗粒度）
关键护栏：
- 默认只读（SELECT）
- 非只读必须人类确认点 + 幂等/回滚策略
模板 7：Docs Updater（文档更新草稿）
- 目标：基于代码变更生成文档更新草稿
- 工具：repo 只读 + docs repo 写（草稿）
- 输出：变更点 -> 对应文档段落建议
关键护栏：
- 不直接 merge（只开 PR）
- 需要引用代码位置（file path + symbol）
模板 8：API Migration Helper（迁移助手）
- 目标：从旧 API 迁移到新 API 的清单与 patch 建议
- 工具：repo 搜索、类型信息（可选）
- 输出：迁移步骤 + 受影响文件列表 + 风险点
关键护栏：
- patch 自动化只做建议，不直接写入主分支
模板 9：Requirement Splitter（需求拆解）
- 目标：把需求拆成可交付的任务列表与验收标准
- 工具：无（或工单系统写草稿）
- 输出：任务树 + 测试点 + 风险与依赖
关键护栏：
- 明确“不确定项”与需澄清的问题
模板 10：Changelog Enforcer（变更记录守门人）
- 目标：强制每次变更都补 changelog（或 release note）
- 工具：CI 环境读取变更文件、写评论（可选）
- 输出：是否通过 + 缺失项
关键护栏：
- 规则可配置（哪些目录必须写 changelog）
- 输出结构化便于 CI 展示
下一步建议
- 从 1 个只读模板开始（PR Summary 或 Log Explainer）
- 做 10 条回归样本
- 再扩展到 3 个模板，形成你的“技能包仓库”