仓库健康度 Skill 故障排查:不触发、格式乱、结果不准
开发团队经常要做「仓库健康度」这类事:检查仓库的文档、许可、CI、依赖更新状态。每次都从头写提示词,结果时好时坏;把它做成智能体 Skill,就能让智能体每次按同一套步骤执行,输出结构也更稳定。
「仓库健康度」技能出问题时,先别急着重写。按下面的表格对号入座,大部分问题都能在几分钟内定位。
症状对照表
| 症状 | 常见原因 | 处理办法 |
|---|---|---|
| 技能完全不触发 | 描述没写触发条件;文件位置或文件名不对;平台未重新加载 | 补写“当用户……时使用”;核对目录;新开会话 |
| 不该触发时触发 | 描述过于宽泛 | 缩小描述范围,写明不适用的情况 |
| 跳过步骤 | 步骤写成段落,或步骤之间缺少依赖说明 | 改成编号列表,写明每步产出 |
| 输出格式每次不同 | 没有给出固定结构 | 给出标题或表头模板,附一份范例 |
| 内容有编造 | 没要求缺信息时提问;没要求标注依据 | 加上“不确定标注需人工确认” |
| 脚本或工具调用失败 | 运行环境缺依赖、路径错误、权限不足 | 单独运行脚本或工具排查,把错误原文反馈给智能体 |
| 越用越偏 | 对话过长,早期指令被稀释 | 新开会话,或把关键约束放在技能最前面 |
排查顺序
- 确认技能是否被加载(大多数平台会在回复或日志中显示使用了哪些规则或技能)
- 用标准样例复现问题
- 检查最近一次修改,必要时回退
- 一次只改一处,改完重跑测试用例
针对这个技能的特别检查
- 输入是否真的是仓库,格式差异会导致后续步骤失败
- “检查必备文件”这一步是否有足够信息
- 脚本输出是否被正确读取
- 风险较低,但输出仍需快速过目再使用
什么时候该求助
如果确认是平台本身的问题(例如更新后入口变化、规则不再读取),查阅平台的官方文档与更新说明,比反复改技能更有效。
交付物结构示例
建议把健康报告固定成下面的结构(示意),方便复核与归档:
## 结论
一句话说明最重要的发现或结果
## 主要内容
- 检查必备文件:……
- 检查 CI 状态:……
- 检查依赖新旧:……
- 给出改进项:……
## 依据
- 引用输入中的具体位置或数据
## 需人工确认
- ……(没有则写“无”)
结构固定之后,复核的人只要先看“结论”和“需人工确认”两部分,就能快速判断结果能否使用。
平台选择建议
同一个「仓库健康度」技能可以落在不同平台上,选择时主要看你在哪里工作、要不要执行代码、要不要接外部系统:
- Claude Code Skill:Claude Code 的 Agent Skills 以文件夹为单位:一个 SKILL.md(YAML 头写 name 与 description)加上可选的脚本和参考资料。智能体平时只看到 description。详见Claude Code Skill 版
- GitHub Copilot 指令与提示文件:GitHub Copilot 支持仓库级自定义指令文件
.github/copilot-instructions.md。详见GitHub Copilot 指令与提示文件 版 - OpenAI Agents SDK:OpenAI Agents SDK 是一个轻量的智能体开发框架。详见OpenAI Agents SDK 版
这个技能需要运行本地脚本(解析文件、调用命令行工具等),要求运行环境允许执行代码,可据此排除不支持相应能力的平台。
延伸阅读
- 仓库健康度 · GitHub Copilot 指令与提示文件 版
- 仓库健康度 · OpenAI Agents SDK 版
- 仓库健康度 · GPTs 版
- 根据提交写站会 · 故障排查
- 版本打标 · 故障排查
- 智能体Skills 分类:625 个技能 × 32 个角度
说明:文中的配置、代码与目录结构均为示意,用于说明思路;各平台的入口、字段名与能力会更新,落地前请以对应官方文档为准。示例中的数据与场景为虚构,不代表真实案例。