用途
task-spec 用于为一个具体的工程任务撰写或修订一份紧凑的行为规格说明。其目标是创建一份最小的规格，使评审者能够理解并质疑该任务，而无需依赖任何聊天记录或对话上下文。
主要能力
- 独立工作：阅读仓库说明、提供的任务、相关代码与文档，以及任何现有的规格约定。
- 在现有任务或规格工件仍能保持清晰时更新它；否则提议在任务附近或仓库一致位置创建一个小的本地 Markdown 文件。
- 从仓库中解析现状事实，仅就实质性改变结果的未来意图提问。
- 以没有聊天记录的评审者视角撰写规格，并重新阅读以移除仅存在于对话中的假设。
- 不要求路线图、跟踪器、文档目录、分支、计划或评审仪式。
- 在撰写前双向测试任务边界：如果请求的验收包含多个可独立交付、评审或拒绝的结果，不应将它们隐藏在一个规格中；如果只是文件编辑、端点、测试步骤、迁移操作或其他本身没有有意义阶段结果的片段，应返回过小的边界，而不是制造任务规格。将任一问题路由到提供的路线图或选定工作流，或在用户要求分解时提议单独的规格。
使用方式
规格中需在某处显式包含以下事实：
- 问题或动机、期望结果，以及为何重要；
- 范围内行为和有意义的非目标；
- 相关时的参与者、输入、输出、规则，以及用户或操作者可见的状态转换；
- 重要的产品或行为决策及其选择原因；
- 相关时可观察的错误、回退、部分失败或兼容性要求；
- 限制可接受解决方案的外部约束；
- 完成证明，包括什么证据表明成功。
使用适合任务的标题。不要强制空章节、选项矩阵、图表或从未真正考虑过的替代方案。紧凑的规格可以是几个聚焦的章节；紧凑不意味着隐含。
拥有系统必须做什么，而不是用于实现它的内部机制。不要选择架构、模块接缝、内部接口、数据库模式、持久化策略、内部状态机、并发控制、缓存、算法、文件路径或代码结构。当强制技术约束是请求的一部分时保留它，但将未解决的评审关键实现选择路由到 technical-design。
将实现顺序排除在外。当顺序、迁移、兼容性、发布或跨模块协调有风险时，保持规格稳定，并单独使用 implementation-plan。
仅当没有更强的本地模式存在时，使用 references/spec-template.md。
适用场景
适用于需要为单个具体工程任务创建或修订行为规格说明的场景，尤其是当协作者需要一份持久的问题与结果、范围与边界描述，且评审者应在没有聊天历史的情况下评估该规格时。
限制
- 不规定架构、模块划分、内部接口、数据库模式、持久化策略、内部状态机、并发控制、缓存、算法、文件路径或代码结构。
- 不包含实现顺序。
- 不要求路线图、跟踪器、文档目录、分支、计划或评审仪式。
- 配套技能 grilling、research 和 tdd 来自 mattpocock/skills，可通过 npx skills add mattpocock/skills --skill <name> 安装；不要将其协议复制到规格中。