SDD 如何在复杂业务系统中真正落地？ - 链载Ai

全称：spec-driven develop，spec 是 specification 的缩写，代表规范，我们以OpenSpec这个库为例。

💡核心区别：CLI 命令 vs. AI 指令

初学者容易混淆终端命令和Cursor斜杠命令，它们的关系如下：

平时你最常用的 CLI 命令应该只有两个：openspec list(看进度) 和openspec update(维护)。其他的通常都由 AI 代劳了。

一看这个spec的描述是不是很像我们要求的系分文档？从我的角度上看，他比系分更全面，也更符合当前的实际开发流程。

大家应该都知道，在目前这个阶段，claude 写的代码足以覆盖任何我们碰到的场景（或者对我来说足够了），我们原先的旧有的提效方式，组件库、动态表单、低代码搭建，他是稳定的提效方案，但对于 AI 来说，他们具有的上手成本、研发体验也都是负担。对于 AI 来说，如果都是开源的内容，他一天就可以帮我构建出一个系统，在旧有的提效方案上仍然不是一个级别。

但 AI 存在上下文窗口限制导致的幻觉；不理解项目规范、旧有实现，变更都在破坏旧有结构；代码 review 的负担（我一直觉得这是一个伪命题，你除非自己已经在脑子中完全构建了一遍细节，要不然怎么可能能发现一些细节的问题）。

所以社区又重新开始用它来作为 AI 辅助编程的一种开发范式，之前是 TDD，通过测试来保证，因为我们只用对功能负责，如果他的功能是正常的，那实现复杂一些或者丑陋一些是历史债务，总会有个幸运儿来接手的，或者我们称他为 AI 善后工程师。

解决一个 bug 的最好时机永远是引入的阶段，所以 TDD 这种后驱黑盒的方式并不能给你带来安全感。因为你知道实际你在把赌注押在 AI 没有幻觉。但很可惜他有。

传统的 SDD 之所以让人讨厌，是因为写 Spec 的是人，写 code 的也是人。

因为 AI 把我们的生产关系变了，现在写 spec 的是 AI，review 的是人，写 code 的还是 AI，我们从 review 代码变成了 review 设计。

# Change: 移动端支持 PPT 大纲生成完成通知
## Why
目前 PC 端已实现在 PPT 大纲生成完成时的全局通知功能，但在移动端该功能被明确禁用。为了提供一致的用户体验，需要在移动端也支持该通知，但考虑到移动端屏幕尺寸和交互习惯，需要采用底部的 Snackbar 样式而非 PC 端的右上角通知。
## What Changes
-修改`showPPTOutlineNotification`逻辑，移除对移动端的禁用限制。-新增移动端专用的 Snackbar 通知组件/样式。-移动端通知显示在页面底部。-移动端通知内容和交互逻辑（"去查看"按钮）与 PC 端保持一致。
## Impact
-**Affected Specs**:`artifact-notification`-**Affected Code**: -`src/xxx/Chat.tsx` - 新增 Mobile Snackbar 组件 (待定位置，可能在`src/components`或就在`Chat.tsx`内部实现)

##1. Implementation
-[x]1.1设计并实现移动端 Snackbar 组件 -[x]1.1.1创建 MobileSnackbar 组件 (或复用现有组件库的类似组件) -[x]1.1.2实现底部弹出动画和样式 -[x]1.1.3支持自定义内容和操作按钮-[x]1.2修改通知触发逻辑 -[x]1.2.1在 `xxx.tsx` 中修改 `showPPTOutlineNotification` -[x]1.2.2移除 `if (isMobileDevice()) return;` 判断 -[x]1.2.3根据设备类型分发不同的通知展示方式 (PC 使用 `notification.info`, Mobile 使用新 Snackbar)-[]1.3验证与测试 -[]1.3.1验证移动端触发时机是否正确 -[]1.3.2验证移动端样式是否符合设计 (底部 Snackbar) -[]1.3.3验证"去查看"按钮在移动端是否正常工作

## MODIFIED Requirements
### Requirement: PPT 大纲生成完成通知
系统 SHALL 在检测到智能体中断并首次生成 PPT 大纲时，如果用户当前未选中该产物，自动显示通知提醒用户。
#### Scenario: 触发通知显示
-**GIVEN**用户在使用智能体对话（PC 端或移动端）-**AND**系统接收到中断消息-**AND**用户当前选中的内容不是该产物-**WHEN**系统处理中断消息完成-**THEN**系统显示一个通知-**AND**PC 端显示为右上角全局通知，移动端显示为底部 Snackbar 通知-**AND**通知标题为"大纲生成完成"-**AND**通知内容为"{产物名称} 大纲内容已生成，请确认大纲内容"-**AND**通知包含一个"去查看"按钮-**AND**通知不会自动关闭（需要用户手动关闭）
#### Scenario: 点击"去查看"按钮
-**GIVEN**PPT 大纲生成完成通知已显示-**WHEN**用户点击通知中的"去查看"按钮-**THEN**系统调用`xxx`方法-**AND**传入参数包含： -`id`: 当前产物的 artifactId-**AND**工作面板切换到所有文件面板并选中对应产物-**AND**通知自动关闭
#### Scenario: 移动端显示底部 Snackbar 通知
-**GIVEN**用户在移动端使用智能体对话-**AND**触发了 PPT 大纲生成完成通知-**WHEN**通知显示时-**THEN**通知以 Snackbar 形式出现在屏幕底部-**AND**样式区别于 PC 端通知，适配移动端屏幕
#### Scenario: 用户已选中该产物时不显示通知
-**GIVEN**用户在 PC 端或移动端使用智能体对话-**AND**智能体处于中断状态并生成了 PPT 大纲-**AND**用户当前选中的内容就是该产物-**WHEN**组件检测到`canEdit`状态变化-**THEN**系统不显示通知
#### Scenario: 避免重复通知
-**GIVEN**PPT 大纲生成完成通知已经显示过一次-**WHEN**组件重新渲染但`canEdit`状态未发生实际变化-**THEN**系统不再重复显示通知

其他支持自定义命令的可以通过配置自定义命令来实现，提示词咱主打一个直接借鉴（先抄一版 cursor的）。

场景：多人协作或者新人加入时，他想开发一个功能，其实已经在归档里已经有了，但是他输入后仍然触发了新的需求。

通过openspec-propoasl进行已归档需求测试时，他并没有想象的那么美好，我尝试了两个 AI IDE 都帮我重新生成了一份文档，问题出在哪里？LLM（大模型）Prompt 工程与 IDE 实际执行能力之间的鸿沟。

我们来看他提示词里 steps，第一步他描述了 review openspec 下的内容，但是他是通过run xxx这依赖agent 的终端执行能力，如果因为一些原因失败了，他又会给你生成一份新的了。

问题的核心是因为，openspec 本身是一个 cli 命令工具，cursor 似乎也对自己的命令执行很有自信，但真实的环境总是复杂的，就像软件总会有 bug 一样。

那我们就把命令执行的方案改为依赖 IDE 目前的 codebase，让他强制总是先去读目录下的文件（我们已经在最终完整版的命令里添加，这里不再赘述相关代码）。

我们可以看到无论是 cursor 天然支持的命令还是他自己的 CLI 好像都没有提供 update 这个场景。

官方针对这个没有任何说明， AI 给了我一个回答，感觉也合理。

这是一个非常深刻的产品设计问题。
你没看错，**OpenSpec 的设计哲学里确实故意“遗漏”了 `update` 这个动作。**这并不是开发者忘了做，而是基于**“文档即真理（Docs as Code）”**和**“不可变历史”**这两个核心设计理念。以下是为什么没有`/openspec-update`的 4 个核心原因：### 1. 哲学原因：编辑文档不需要“命令”OpenSpec 把 Markdown 文档看作是**代码**的一部分。* **类比 Git**：你在修改代码逻辑时，需要运行`git update-code`吗？不需要。你直接打开文件编辑，然后保存。* **OpenSpec 逻辑**：  *  如果你想改需求，直接打开`spec.md`改文字。  *  如果你想改计划，直接打开`tasks.md`改列表。  * **“修改”是编辑器的基础功能，不是 CLI 的功能。**引入一个`/openspec-update`命令反而会显得多余：因为 AI 的修改本质上就是“读取文件 -> 覆写文件”，这在自然语言对话中（“把登录改成支持手机号”）已经涵盖了。### 2. 流程原因：Proposal 包含了 Update在 OpenSpec 的定义里，**Proposal（提案）是一个持续迭代的过程**，而不是一次性的动作。* **第一次运行 `/openspec-proposal`**= 从 0 到 1 创建文档。* **第二次运行 `/openspec-proposal`**= 基于现有文档进行修改（迭代）。在 Cursor 的 Prompt 逻辑里，`/openspec-proposal`的定义其实包含了“Review gaps”和“Draft spec deltas”。如果你对 AI 说：“**`/openspec-proposal` 之前的方案太复杂了，简化一下**”，AI 会直接修改现有的文件。**所以在 AI 看来，Create 和 Update 是同一个能力的两个面。**### 3. 架构原因：避免“状态地狱”如果引入了`update`命令，就会带来状态管理的复杂性：* “我是要在`apply`之前 update，还是之后 update？”* “Update 是重置任务，还是保留进度？”OpenSpec 选择了最简单的路径：* **没有状态锁**：文件随时可改。* **执行驱动**：`/openspec-apply`永远只看**当前这一刻**的`tasks.md`。不管你是刚生成的，还是手动改了 100 次的，Apply 只负责执行当下。### 4. 归档逻辑：已完成的不可 Update对于已经**Archive（归档）**的需求，OpenSpec**严禁**使用`update`。* **历史不可篡改**：归档等于“合同已结案”。* **新变更**：如果你要改旧功能，必须发起一个新的`new`(Proposal)。* **CLI 里的 `openspec update`**：  *  注意，CLI 确实有一个 `openspec update` 命令，但它的作用是**更新 `AGENTS.md` 和配置文件**（升级库本身），而不是更新你的业务 Spec。---### 最佳实践：当你真的想 "Update" 时该怎么办？虽然没有这个命令，但在实际操作中，你可以通过以下三种方式达成 "Update" 的目的：#### 方式 A：手动修改（最推荐，最快）直接在编辑器里打开`openspec/changes/xxx/spec.md`，删掉不想要的，加上想要的。* *优势*：人类改文档比跟 AI 废话要快得多，且精准。#### 方式 B：复用 Proposal 命令直接再次输入：> `/openspec-proposal` 需求有变，请把数据库改成 MongoDB，并更新 spec 和 tasks。* *效果*：AI 会覆写当前目录下的文档。#### 方式 C：在 Apply 时“挟持”在执行前临时变卦：> `/openspec-apply`**注意：在执行前，请先更新 tasks.md，去掉所有关于 Redis 的步骤。**### 总结**OpenSpec 没有 `update`，因为 Markdown 文件本身就是可变的接口。**它鼓励你：1.**Draft**(起草/迭代) -> 复用`/openspec-proposal`或直接编辑。2.**Apply**(执行) -> 照着文档做。3.**Archive**(归档) -> 封存，下次再来请开新单。
这种“少即是多”的设计，反而避免了在复杂的命令参数中迷路。

他提供的核心能力其实是文档管理功能，而文档本身就是可编辑的。考虑极端一些的场景，他其实只是给我们对已有功能进行归档。我如果抛开 AI，他的逻辑也是成立的，只是他的存在正好可以让大模型从搜索代码到先搜索总结后的功能。

手动进行修改是他的哲学设计，但基于此也会延伸出来一个问题。

没有特殊的 prompt 约束，模型并不知道一个 change 下的文件是需要联动更新的，但是实际上他们是依赖关系。

我们还是需要自定义一个openspec-update命令，来处于需求变更的场景，让 prompt 只专注在修改changes 下的文件内容。当用户调用它时，他会查询当前还未归档的变更，如果存在多个需要跟用户手动确认是作用于哪一个变更。（我们已经在最终完整版的命令里添加，这里不再赘述相关代码）

我们回看标准目录，其实答案已经藏在那里。他是通过changes/[change-name]/specs/[capability]的capability来决定的，如果你发现有问题，因为这个不涉及到文件的联动更新，直接手动修改即可。

我们看到这个报错写的是变更的时候需求未找到。当处于变更状态下，变更的 specs 文件里会标明原有的需求是什么，我们当前这次 specs 里的需求跟原来归档的需求不一致，所以发生了这个问题。

针对命令执行报错的场景，我们需要在提示词中都显式声明，告诉他应该立即停止，然后抛出对应的信息，让用户进行手动验证。（我们已经在最终完整版的命令里添加，这里不再赘述相关代码）

场景：当我存在一个已经归档的需求，然后我发现了一个 bug，这时候我告诉他需求变更，他的 specs 文件里标明的是 MODIFIED 的，当我完成归档后，发现初始归档的内容被覆盖了。

而 MODIFIED 对他来说意味的就是需求变更，是文件覆盖操作，与我们的开发心智是存在一些区别的，他提倡的是增量式更新。

在任意变更前都先明确你的变更预期，检查 changes 下的 spec 文件的动作。

#### 1. ADDED (追加/新增)* **定义**：向 Spec 文件中**插入**新的`Requirement`或`Scenario`。* **心智模型**：`Array.push(newScenario)`或`File.append(text)`。* **典型场景**：  *  新功能上线（废话）。  * **优化需求（扩展型）**：比如“登录增加验证码”、“列表增加筛选功能”。虽然你在“优化”列表，但你在文档里是**加了一段描述**，并没有删改原来的列表查询逻辑。  * **边缘情况补全**：比如“增加网络超时的处理逻辑”。
#### 2. MODIFIED (覆盖/修改)* **定义**：**替换**Spec 文件中已存在的某个`Scenario`的全部内容。* **心智模型**：`Map.set(existingKey, newValue)`或`Overwrite`。* **危险性**：⚠️ 高。因为它会丢弃旧的逻辑。* **典型场景**：  * **业务规则变更**：比如“积分获取规则从 10元1分 变成 20元1分”。  * **Bug 修复（逻辑错误的）**：原来的 Spec 写错了（比如写成“允许空密码”），现在要修正这个错误。  * **重构（导致行为变化的）**：比如“同步处理改为异步处理，用户不再立即收到结果”。
#### 3. REMOVED (删除)* **定义**：从 Spec 文件中**移除**某个`Scenario`。* **心智模型**：`Array.filter(item => item.id !== id)`。* **典型场景**：  *  功能下线。  *  简化产品，砍掉不常用的功能。

大家可以看到一个趋势，目前社区的趋势已经从模型自身的军备竞赛回归到了我们熟悉的工程化，在工程化落地阶段有很多可以做的事情。cc 和 cursor 都是调用 claude，为什么 cc 比 cursor 强。因为他要求你先规划，再执行。现在大家跟进的 plan 模式也是一样。

plan 模式和 spec 在单一对话上很像，他也提供了保存到本地的能力，大家在做的事其实是一样的，都是为了让模型有一个更稳定的输出，帮助我们解决实际的问题。

社区也有很多其他的 spec 方案，颗粒度不一样，这是另一个比较高星的仓库，他的理念和哲学会有一些差别。

**OpenSpec**和**GitHub Spec Kit**都是“规格驱动开发（SDD）”的工具，它们的目标一致（先写文档再写代码），但**设计哲学**和**适用场景**截然不同。
用一个最形象的比喻来概括：* **GitHub Spec Kit**像是**“建造摩天大楼的总工程师”**。严谨、繁琐、流程长，适合从 0 到 1 搞大工程，强调“企业级治理”。* **OpenSpec**像是**“敏捷开发的装修队长”**。轻快、直接、灵活，适合日常修修补补和快速迭代，强调“开发者体验”。
以下是详细的对比分析：
### 1. 核心差异对比表
| 特性 |**OpenSpec**(Fission-AI) |**Spec Kit**(GitHub) || :--- | :--- | :--- ||**核心哲学**|**Agile Renovator(敏捷装修)**<br>轻量级，假设你是在一个**现有的**代码库上工作。 |**Structured Architect(结构化建筑师)**<br>重量级，假设你是从 0 开始构建一个全新的系统。 ||**工作流**|**3 步循环**(Draft -> Review -> Apply)<br>只有三个命令，像 Git 一样简单。 |**4 阶段门控**(Specify -> Plan -> Tasks -> Implement)<br>每一步都有严格的“关卡”，必须通过才能进下一步。 ||**适用场景**|**维护/迭代现有项目 (Brownfield)**<br>修 Bug、加功能、改逻辑。 |**全新项目启动 (Greenfield)**<br>做 Demo、新开一个微服务。 ||**文件管理**|**双文件夹模式**<br>`specs/`(真理) 和`changes/`(变更) 分离。<br>不仅管“新建”，更擅长管“修改”。 |**单向流动**<br>通过`constitution.md`(宪法) 定义原则。<br>通常会为你自动创建 Git 分支。 ||**Token 消耗**|**低**。文档精简（约 200 行），只关注变更部分。 |**高**。生成的文档非常详尽（约 800 行），包含大量样板信息。 ||**上手难度**| ⭐**低**(npm install 即可) | ⭐⭐⭐**中**(需理解其四阶段理念) |
---
### 2. 深度解析：为什么说 OpenSpec 更适合日常？
#### A. “修改” vs “新建” 的逻辑差异* **Spec Kit**的思维模型是线性向前的。当你用它做一个新功能时，它非常爽，会生成完美的需求文档、技术方案。但如果你只是想“把登录按钮往左移 10px”，Spec Kit 的那套“需求->计划->任务->实施”的重型流程会让你觉得像在**杀鸡用牛刀**。* **OpenSpec**专门解决了这个问题。它把变更（Change）作为一个独立的概念。  *  你可以发起一个“修改按钮位置”的 Change。  *  你可以发起一个“重构数据库”的 Change。  *  不论大小，流程都是统一的 Draft -> Apply -> Archive。
#### B. 此时此刻的“真理” (Source of Truth)* **Spec Kit**倾向于把生成的 Spec 作为一个阶段性的产物。* **OpenSpec**引入了`openspec/specs/`目录作为**永久的**“真理来源”。  *  当你把一个功能 Archive（归档）后，它的 Spec 会被合并到主目录。  * **杀手级特性**：下次你让 AI 改代码时，OpenSpec 会先让 AI 读`specs/`目录，AI 立刻就能知道“哦，这个功能上次是这样设计的”，**防止了新代码破坏旧逻辑（Regression）**。
#### C. “宪法” vs “项目说明书”* **Spec Kit**有一个`constitution.md`（宪法）的概念，里面写满了不可违背的原则（比如“必须使用 TDD”、“必须写注释”）。这很有企业级风范。* **OpenSpec**使用`project.md`，更像是一个“项目备忘录”。它更务实，通常只包含技术栈、目录结构和关键约定。
---
### 3. 如何选择？
#### ✅ 选**OpenSpec**，如果：1.**你在维护一个现有的项目**：你需要在巨大的代码山上修修补补，而不是每天都在`npm init`新项目。2.**你追求速度**：你不想为了写一个简单的 API 接口而经历漫长的 4 步审批流程。3.**你是个人开发者或小团队**：你们需要规范，但不需要官僚主义。4.**你在乎 Token 费用**：OpenSpec 的 Prompt 更精简。
#### ✅ 选**GitHub Spec Kit**，如果：1.**你是 Tech Lead，要开一个新坑**：你想在写第一行代码前，逼迫团队把所有细节（API 定义、数据库模型、甚至错误码）都想清楚。2.**团队很大，水平参差不齐**：你需要用`constitution.md`来强制所有人遵守编码规范，不给 AI（或人）自由发挥的空间。3.**你需要产出非常详尽的文档**：Spec Kit 生成的文档可以直接拿去给老板或客户汇报用。
### 总结**OpenSpec 是 Spec Kit 的“实用主义”进化版。**Spec Kit 像是教科书上的“瀑布流+敏捷”混合体，很理想化；而 OpenSpec 则是那个真正坐在你旁边写代码的同事，懂你需要什么，也懂你不想麻烦。

这只是更适合我自己心智的提示词，可能一些错误场景也还没有碰到，你可以基于我的继续去演进或者直接使用。他的优势在于没有任何魔法，完全可以自己控制。

## 描述Scaffold anewOpenSpec changeandvalidate strictly.
## 命令<!-- OPENSPEC:START -->
**Guardrails**
-Favor straightforward, minimal implementationsfirstandaddcomplexityonlywhenitisrequestedorclearly required.-Keep changes tightly scopedtothe requested outcome.-Referto`openspec/AGENTS.md` (located inside the `openspec/` directory—run `ls openspec`or`openspecupdate` if you don't see it) if you need additional OpenSpec conventions or clarifications.- Identify any vague or ambiguous details and ask the necessary follow-up questions before editing files.- Do not write any code during the proposal stage. Only create design documents (proposal.md, tasks.md, design.md, and spec deltas). Implementation happens in the apply stage after approval.
**Steps**
1. **CRITICAL PRE-CHECK**: - **DO NOT assume context.** You MUST perform a **codebase search** (using your internal search tool) specifically targeting the `openspec/specs/` directory for keywords related to the user's request. -**STOPANDASK**: If you find _any_ existing spec files that seem related (even remotely),**STOP IMMEDIATELY**. Donotgenerateanyscaffold. List the found specsandask theuser: "Did you mean to modify [filename] instead?" -OnlyproceedtoStep2if thesearchreturnsZERO relevant results.2.**(Onlyifnoduplicates found)**Choose auniqueverb-led `change-id`andscaffold `proposal.md`, `tasks.md`,and`design.md` (whenneeded) under `openspec/changes/<id>/`.3.Map the changeintoconcrete capabilitiesorrequirements, breaking multi-scopeeffortsintodistinctspec deltaswithclear relationshipsandsequencing.4.Capture architectural reasoningin`design.md`whenthe solution spans multiple systems, introducesnewpatterns,ordemands trade-off discussion before committingtospecs.5.Draft spec deltasin`changes/<id>/specs/<capability>/spec.md` (onefolderpercapability)using`## ADDED|MODIFIED|REMOVED Requirements`withatleastone`#### Scenario:`perrequirementandcross-reference related capabilitieswhenrelevant.6.Draft `tasks.md`asan ordered listofsmall, verifiable work items that deliveruser-visible progress, include validation (tests, tooling),andhighlight dependenciesorparallelizable work.7.Validatewith`openspec validate<id>--strict` and resolve every issue before sharing the proposal.
**Reference**
-Use `openspecshow<id>--json --deltas-only` or `openspec show <spec> --type spec` to inspect details when validation fails.-Searchexisting requirementswith`rg-n "Requirement:|Scenario:" openspec/specs` before writingnewones.-Explore the codebasewith`rg<keyword>`, `ls`,ordirect filereadsso proposals alignwithcurrentimplementation realities.<!-- OPENSPEC:END -->

## 描述Modify an existing, active OpenSpec draft(proposal, spec, tasks) without creating a new one.
## 命令<!-- OPENSPEC:START -->
**Guardrails**
-**SCOPE RESTRICTION**: This command operates ONLY on files within`openspec/changes/`. Do NOT create new change folders. Do NOT edit`src/`code.-**CONSISTENCY**: If requirements(`spec.md`)ordesign(`design.md`) change, you MUST update`tasks.md`to reflect these changes immediately.-**INTERACTION**: If multiple active changes exist, you MUST ask the user to select one before editing any files.
**Steps**
1.**Discovery & Selection(Context Loading)**  - Run`openspec list`(orlist directories in`openspec/changes/`) to identify active drafts.  -**Scenario A(0 Active Changes)**:    - STOP and inform the user: "No active drafts found to update. Use`/openspec-proposal`to start a new one."  -**Scenario B(1 Active Change)**:    - Automatically select thisID(e.g.,`feature-login`).    - Inform the user: "Updating active draft:`feature-login`..."    -**Read Files**: Read`proposal.md`,`tasks.md`,`design.md`, and`spec.md`inside that directory.  -**Scenario C(>1 Active Changes)**:    - List all found IDs.    - STOP and ask: "Multiple active drafts found. Which one do you want to update? (e.g.,`feature-A`or`feature-B`)"    - Wait for user confirmation, then read the files of the selected ID.
2.**Intent Analysis & Execution**  - Analyze the user's update request(e.g., "Extract Modal component", "Change DB to Mongo").  -**Step 2.1: Update Truth(Spec/Design/Proposal)**:    - Modify`spec.md`if business requirements change.    - Modify`design.md`if technical implementation details change.    - Modify`proposal.md`if the high-level goal changes.  -**Step 2.2: Re-align Plan(Tasks)**:    -**CRITICAL**: Rewrite or adjust`tasks.md`to ensure it matches the new files from Step 2.1.    - If tasks were partially completed(`[x]`), try to preserve status where possible, but uncheck items if the logic underneath them has fundamentally changed.
3.**Validation**  - Run`openspec validate <id>`to ensure the update didn't break the document structure.  - Present the summary of changes to the user(e.g., "Updated`design.md`to include SharedModal; Added 2 new steps to`tasks.md`").
**Reference**
-Use`openspec list`to find targets.-Always keep`tasks.md`as the executable plan for the current`spec.md`.<!-- OPENSPEC:END -->

## 描述Implement an approved OpenSpec change and keep tasks in sync.
## 命令<!-- OPENSPEC:START -->
**Guardrails**
-Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.-Keep changes tightly scoped to the requested outcome.-Refer to`openspec/AGENTS.md`(located inside the`openspec/`directory—run`ls openspec`or`openspec update`if you don't see it) if you need additional OpenSpec conventions or clarifications.
**Steps**Track these steps as TODOs and complete them one by one.
1.Read`changes/<id>/proposal.md`,`design.md`(if present), and`tasks.md`to confirm scope and acceptance criteria,Strictly follow the tasks.md sequence. Do not skip steps or merge tasks unless explicitly necessary.2.Work through tasks sequentially, keeping edits minimal and focused on the requested change.3.Confirm completion before updating statuses—make sure every item in`tasks.md`is finished.4.**Update `tasks.md` selectively:** - Mark**implementation tasks**(e.g., "Create component", "Add API endpoint") as`- [x]`immediately after writing the code. -**Do NOT**mark**verification/validation tasks**(e.g., "Verify login works", "Check responsiveness", "Run tests") as completed. Leave them as`- [ ]`for the user to confirm manually.5.Reference`openspec list`or`openspec show <item>`when additional context is required.
**Reference**
-Use`openspec show <id> --json --deltas-only`if you need additional context from the proposal while implementing.
**tips**If the user only enters this command, the latest`tasks.md`and files under the`specs/*`directory need to be read.
<!-- OPENSPEC:END -->

## 描述Archive a deployed OpenSpec change and update specs.
## 命令**Guardrails**
-Favor straightforward, minimal implementations first and add complexity only when it is requested or clearly required.-Keep changes tightly scoped to the requested outcome.-Refer to`openspec/AGENTS.md`(located inside the`openspec/`directory—run`ls openspec`or`openspec update`if you don't see it) if you need additional OpenSpec conventions or clarifications.
**Steps**
1.Determine the change ID to archive: - If this prompt already includes a specific change ID(for example inside a`<ChangeId>`block populated by slash-command arguments), use that value after trimming whitespace. - If the conversation references a change loosely(for example by title or summary), run`openspec list`to surface likely IDs, share the relevant candidates, and confirm which one the user intends. - Otherwise, review the conversation, run`openspec list`, and ask the user which change to archive; wait for a confirmed change ID before proceeding. - If you still cannot identify a single change ID, stop and tell the user you cannot archive anything yet.
2.**PRE-CHECK**: Validate the change ID and status: - Run`openspec list`to confirm the ID exists and is not already archived. -**CRITICAL**: Run`openspec validate <id> --strict`. -**STOP IF FAILED**: If validation reports ANY errors(e.g., unfinished tasks, malformed frontmatter),**DO NOT PROCEED**. Show the validation errors to the user and ask them to fix the issues first.
3.**ARCHIVE**: Only if validation passes, run`openspec archive <id> --yes`. - This moves the change to`changes/archive/`and applies spec updates without prompts. - (Optional) Use`--skip-specs`only if the user explicitly requested a tooling-only archive.
4.Review the command output to confirm the target specs were updated successfully.
**Reference**
-Use`openspec list`to confirm change IDs before archiving.-Inspect refreshed specs with`openspec list --specs`after archiving to confirm the merge.<!-- OPENSPEC:END -->