name: openspec-sync-specs description: 将变更中的delta规范同步到主规范。当用户想要用delta规范的更改更新主规范而不归档变更时使用。 license: MIT compatibility: 需要openspec CLI。 metadata: author: openspec version: “1.0” generatedBy: “1.0.0”

将变更中的delta规范同步到主规范。

这是一个代理驱动的操作——您将读取delta规范并直接编辑主规范以应用更改。这允许智能合并（例如，添加场景而不复制整个需求）。

输入：可选指定变更名称。如果省略，检查是否可以从对话上下文中推断。如果模糊或模糊，您必须提示可用的变更。

步骤

如果未提供变更名称，提示选择

运行openspec list --json以获取可用的变更。使用AskUserQuestion工具让用户选择。

显示具有delta规范的变更（在specs/目录下）。

重要：不要猜测或自动选择变更。始终让用户选择。
查找delta规范

在openspec/changes/<名称>/specs/*/spec.md中查找delta规范文件。

每个delta规范文件包含如下部分：
- ## 新增需求 - 要添加的新需求
- ## 修改需求 - 对现有需求的更改
- ## 删除需求 - 要删除的需求
- ## 重命名需求 - 要重命名的需求（FROM:/TO:格式）
如果未找到delta规范，通知用户并停止。
对于每个delta规范，应用更改到主规范

对于每个在openspec/changes/<名称>/specs/<能力>/spec.md处有delta规范的能力：

a. 读取delta规范以理解预期的更改

b. 读取主规范在openspec/specs/<能力>/spec.md（可能尚未存在）

c. 智能应用更改：

新增需求：
- 如果需求在主规范中不存在 → 添加它
- 如果需求已存在 → 更新它以匹配（视为隐式修改）
修改需求：
- 在主规范中找到需求
- 应用更改——这可以是：
  - 添加新场景（不需要复制现有场景）
  - 修改现有场景
  - 更改需求描述
- 保留delta中未提及的场景/内容
删除需求：
- 从主规范中删除整个需求块
重命名需求：
- 找到FROM需求，重命名为TO
d. 创建新的主规范如果能力尚不存在：
- 创建openspec/specs/<能力>/spec.md
- 添加Purpose部分（可以简短，标记为TBD）
- 添加Requirements部分与新增需求
显示摘要

应用所有更改后，总结：
- 哪些能力被更新
- 进行了哪些更改（需求新增/修改/删除/重命名）

Delta规范格式参考

## 新增需求

### 需求: 新功能
系统应做某事新。

#### 场景: 基本案例
- **当**用户做X
- **然后**系统做Y

## 修改需求

### 需求: 现有功能
#### 场景: 要添加的新场景
- **当**用户做A
- **然后**系统做B

## 删除需求

### 需求: 废弃功能

## 重命名需求

- FROM: `### 需求: 旧名称`
- TO: `### 需求: 新名称`

关键原则：智能合并

与程序化合并不同，您可以应用部分更新：

要添加场景，只需在MODIFIED下包含该场景——不要复制现有场景
delta代表意图，而不是全面替换
使用您的判断来合理合并更改

成功时的输出

## 规范已同步: <变更名称>

更新的主规范：

**<能力-1>**:
- 新增需求: "新功能"
- 修改需求: "现有功能"（添加了1个场景）

**<能力-2>**:
- 创建了新规范文件
- 新增需求: "另一个功能"

主规范现已更新。变更保持活动状态——在实现完成时归档。

防护措施

在更改前读取delta和主规范
保留delta中未提及的现有内容
如果有不清楚的地方，请求澄清
在操作过程中显示您正在更改的内容
操作应该是幂等的——运行两次应得到相同结果