开发团队经常要做「Issue 模板设计」这类事：为仓库设计缺陷与需求模板。每次都从头写提示词，结果时好时坏；把它做成智能体 Skill，就能让智能体每次按同一套步骤执行，输出结构也更稳定。

背景（虚构）

阿周是一名开发团队，每周都要做几次Issue 模板设计。过去靠复制粘贴提示词，结果不稳定。这次团队把它做成了技能，下面记录一次完整运行。

1. 发出请求

阿周在Git 仓库与代码托管平台中输入：

帮我做一下Issue 模板设计，材料是附上的仓库说明。

2. 技能被触发

智能体根据技能描述判断任务匹配，加载「Issue 模板设计」的完整指令。它不需要外部工具，直接按指令处理。

3. 确定必填信息

“确定必填信息”是最容易出错的环节，技能里专门写了要求，所以智能体给出了清楚的结果与理由。

4. 设计缺陷模板

“设计缺陷模板”是最容易出错的环节，技能里专门写了要求，所以智能体给出了清楚的结果与理由。

5. 设计需求模板

“设计需求模板”是最容易出错的环节，技能里专门写了要求，所以智能体给出了清楚的结果与理由。

6. 加入提示语

“加入提示语”是最容易出错的环节，技能里专门写了要求，所以智能体给出了清楚的结果与理由。

7. 交付与复核

智能体交付模板文件，末尾列出两条需人工确认的内容。阿周对照原始仓库说明抽查关键信息，修正一处表述后采用。

复盘：这次做对了什么

  • 步骤写在技能里，没有遗漏
  • 不确定处被标出，而不是被编造
  • 遵守了「改写历史、删除分支类操作只给建议，不直接执行」
  • 风险较低，但输出仍需快速过目再使用

可以改进的地方

阿周发现智能体对团队内部术语理解不一致，于是在技能目录中加了一份术语表（reference.md），并在 SKILL.md 中写明“遇到术语先查表”。更多改法见定制指南。

领域注意事项

「Issue 模板设计」属于Git 与协作领域，使用者多是开发团队，工作环境通常是Git 仓库与代码托管平台。这个领域最重要的一条底线是：改写历史、删除分支类操作只给建议，不直接执行。

建议把这条底线原样写进技能的约束部分，而不是指望智能体自己意识到。同时，在团队内部明确：智能体给出的模板文件只是初稿或建议，最终由谁签字确认、出了问题由谁负责。

常见变体

同一个技能可以按使用场景派生出几个变体：

  • 简版：只保留核心步骤（确定必填信息、加入提示语），适合快速过一遍
  • 详版：每一步都写出理由与依据，适合交给他人复核或留档
  • 批量版：一次处理多份仓库说明，输出汇总表，适合定期集中处理

变体之间共享同一套约束，只在步骤详略和输出格式上有差异。可以在一个技能里用参数区分，也可以拆成几个名称明确的技能。

延伸阅读

说明：文中的配置、代码与目录结构均为示意，用于说明思路；各平台的入口、字段名与能力会更新，落地前请以对应官方文档为准。示例中的数据与场景为虚构，不代表真实案例。