to-spec Skill 详解：它写什么，什么时候该跳过
Matt Pocock 的 /to-spec skill 如何把一段规划对话写成 spec issue，它的模板缺了什么，以及什么情况下根本不值得写 spec。
标签：流程实践
流程实践相关文章集合，覆盖规格评审、上线回滚、质量门禁、治理机制和团队协作习惯。
Harness Engineering 与 Spec-Driven Development 的区别
Harness engineering 在 AI 编码 agent 语境下是什么，它和 spec-driven development 有什么区别，以及两者怎么一起用。
写给 Spec-First 团队的 AGENTS.md：什么该写进去
AGENTS.md 是写给 coding agent 的 README。难的不是格式，而是边界：哪些规则对每次改动都成立，哪些只属于某一次改动的规格。
Cursor Rules：四种类型，以及各自何时触发
从不触发的规则比没有规则更糟，因为团队以为自己被覆盖了。三个 frontmatter 字段决定你写出的是四种类型中的哪一种，而多数团队写出了那个死的。
AI Agent 团队的 Spec-First 工作流
为运行 AI 编码 agent 的团队设计的五阶段 spec-first 工作流：规格包、任务边界、写入范围、证据门禁和可扩展的 PR 评审。
写给 AI Agent 的 MCP Server API 契约
为 MCP server 编写 API 规格契约：输入 schema、输出结构、错误分类、幂等标记和版本策略，让 AI agent 客户端可以可靠调用。
OpenSpec vs Superpowers vs Spec Kit：对比与组合用法
2026 年 11 月核对版：OpenSpec、Superpowers 和 Spec Kit 各管什么，怎么组合使用，以及该从哪个开始。
AI 编码前的规格包：先给边界，再让它写代码
围绕「AI 编码前的规格包：先给边界，再让它写代码」展开，说明可测试输入、预期结果、边界条件和评审标准，帮助 QA 与开发提前对齐，可直接用于规格评审、实现前对齐和测试计划补充。
Spec Skills 与 Spec-First 交付：实际如何结合
大多数 AI 编码工具都在为一个目标做优化：让东西在未来十分钟内跑起来。Spec Skills 优化的是另一件事——确保生成出来的代码，就是你当初真正要的那个东西。
AI 编码治理：用规格驱动的 Prompt 设立边界
用 spec-driven prompts 治理 AI 辅助编程：提示词必须包含什么、AI 必须遵守哪些边界，以及让“这是 AI 写的”变成可核验声明的审计链。
AI 编码 PR 评审：用验收标准衡量通过与否
围绕「AI 编码 PR 评审：用验收标准衡量通过与否」展开，说明可测试输入、预期结果、边界条件和评审标准，帮助 QA 与开发提前对齐，可直接用于规格评审、实现前对齐和测试计划补充。
AI 编码合并前风险登记：merge 之前要追踪的条目
围绕「AI 编码合并前风险登记：merge 之前要追踪的条目」展开，说明如何用规格约束 AI 编码、保留人工评审点，并用证据判断实现是否达标，可直接用于规格评审、实现前对齐和测试计划补充。
AI 编码的测试证据门禁：为什么通过用例还不够
AI 写出的代码读起来都像能跑。有时候它甚至能通过自己写的那套测试。本文的规矩是：不信代码，不信测试，只信"这些测试真的能抓住真实 bug"的证据。下面讲的，就是在合并前如何把这份证据落成具体文件。
契约测试计划：从 OpenAPI 到 CI
围绕「契约测试计划：从 OpenAPI 到 CI」展开，说明契约字段、兼容边界、失败路径和评审检查点，帮助团队在上线前减少集成风险，可直接用于规格评审、实现前对齐和测试计划补充。
事件驱动系统的规格模式：契约与消费语义
事件驱动系统的规格范式：事件 schema 版本化、command 与 fact 事件的区分、choreography 与 orchestration 的取舍、幂等处理器，以及最终一致性边界的明确表达。
软件规格中的 10 个常见错误
失败的项目很少是因为没有 spec。更常见的情况是：spec 有，只是没写真正重要的那些事。下面这十个错误在 spec 评审里反复出现，经验丰富的作者写的初稿也不例外。它们都不难修，但在截止日期的压力下，每一个都容易被漏掉。
AI 辅助开发下的规格质量门禁
围绕「AI 辅助开发下的规格质量门禁」展开，说明如何用规格约束 AI 编码、保留人工评审点，并用证据判断实现是否达标，可直接用于规格评审、实现前对齐和测试计划补充。
编码前的规格评审清单
大多数规格评审只是走过场。三个人扫一眼文档，有人写一句"LGTM"，然后所有人带着同样的模糊地带继续往前走。真正的规格评审，会抓住那些一周之后会让你付出代价的东西。下面这份清单，适合在放任何规格通过评审之前过一遍。
什么是 Spec-First 开发？（完整指南）
一个团队如果交付很快但不断返工，并不是在跑得更快——而是在烧跑道。问题几乎总是一样的：没人在编码之前写清楚"完成"是什么意思。Spec-First 开发解决这个问题——在实现之前定义验收标准，而不是之后。