name: template-engineering description: 指南用于创建元提示模板，将工程工作流编码为可重用、可扩展的单位。适用于创建生成计划的斜杠命令、设计工作流模板或将团队最佳实践编码到代理提示中。 allowed-tools: Read, Grep, Glob

模板工程

指南用于创建元提示模板 - 构建提示的提示。

何时使用

创建新的斜杠命令以生成计划
将团队工作流编码为可重用模板
设计用于琐事、错误、功能的元提示
分析现有模板以进行改进

模板解剖

每个有效模板都有五个部分：

1. 目的部分

顶部的清晰描述：

# [工作类型] 计划

创建一个新计划在 specs/*.md 中，使用确切的指定 markdown 计划格式来解决 [工作类型]。

2. 指令部分

对代理的指导：

## 指令

- 您正在编写一个计划，而不是实施
- 使用您的推理模型：认真思考计划
- 专注于相关文件部分中的文件
- 包含验证完成性的命令
- 填写计划格式的每个部分

3. 相关文件部分

引导上下文加载：

## 相关文件

专注于以下文件：
- README.md (项目上下文)
- src/** (源代码)
- tests/** (测试模式)
- docs/** (文档)

4. 计划格式部分

带有占位符的模板：

## 计划格式

# [工作类型]: <名称>

## 描述
<需要完成的内容>

## 相关文件
<要修改的文件>

## 逐步任务
<编号的可操作任务>

## 验证命令
<证明完成性的命令>

## 备注
<边缘情况和考虑事项>

5. 参数部分

接受用户输入：

## [工作类型]
$ARGUMENTS

设计工作流

步骤 1：识别工作类型

这个模板解决什么类别的问题？

琐事：维护、更新、清理
错误：调查和修复
功能：新功能
重构：代码改进

步骤 2：定义计划结构

这个工作类型需要什么部分？

工作类型	基本部分
琐事	描述、文件、任务、验证
错误	问题、解决方案、重现、根本原因、任务、验证
功能	用户故事、实施计划、测试、验收
重构	之前/之后、迁移、回滚

步骤 3：编写指令

指导代理的推理：

他们应该关注什么？
需要什么推理深度？（“认真思考”）
应该避免什么常见错误？
什么格式要求是严格的？

步骤 4：指定相关文件

限制范围以提高质量：

这个工作类型的核心文件
理解模式的测试文件
如果相关，配置文件
避免过于广泛的模式

步骤 5：用示例测试

验证您的模板：

使用简单输入运行
检查生成计划的完整性
尝试边缘情况
根据结果精炼

质量检查清单

部署模板前：

[ ] 目的清楚说明模板的作用
[ ] 指令包括用于推理的“认真思考”
[ ] 相关文件具体，不太广泛
[ ] 计划格式有所有必要部分
[ ] 验证命令部分是强制性的
[ ] 参数正确使用 $ARGUMENTS
[ ] 指定输出位置（specs/*.md）

常见模式

推理激活

使用您的推理模型：认真思考计划
以及完成这项工作的步骤。

文件输出模式

在 specs/*.md 中创建一个新计划，使用以下命名：
specs/[工作类型]-[描述性名称].md

验证强制

验证命令部分是必需的。每个计划必须
包含证明工作完成的命令。

要避免的反模式

缺少验证部分

坏：无法验证完成性好：特定的测试和检查命令

模糊指令

坏： “制定一个好计划” 好： “专注于错误处理边缘情况，包括回滚步骤”

没有输出位置

坏：计划写在未定义的地方好： specs/[工作类型]-[名称].md 模式

版本历史

v1.0.0 (2025-12-26)：初始发布

最后更新

日期： 2025-12-26 模型： claude-opus-4-5-20251101

模板工程Skill template-engineering