名称: openspec-bulk-archive-change 描述: 一次性归档多个已完成的变化。在归档多个并行变化时使用。许可证: MIT 兼容性: 需要 openspec CLI。元数据: 作者: openspec 版本: “1.0” 生成者: “1.0.0”

一次性归档多个已完成的变化。

这个技能允许您批量归档变化，通过检查代码库智能处理规格冲突来确定实际实现的内容。

输入: 无需输入（提示选择）

步骤

获取活动变化

运行 openspec list --json 获取所有活动变化。

如果没有活动变化，通知用户并停止。
提示选择变化

使用 AskUserQuestion 工具 进行多选，让用户选择变化：
- 显示每个变化及其模式
- 包括“所有变化”选项
- 允许选择任意数量（1+ 有效，2+ 是典型用例）
重要: 不要自动选择。始终让用户选择。
批量验证 - 收集所有选定变化的状态

对于每个选定的变化，收集：

a. 工件状态 - 运行 openspec status --change "<name>" --json
- 解析 schemaName 和 artifacts 列表
- 注意哪些工件是 done 与其他状态
b. 任务完成 - 读取 openspec/changes/<name>/tasks.md
- 计数 - [ ]（未完成） vs - [x]（完成）
- 如果没有任务文件，记为“无任务”
c. 增量规格 - 检查 openspec/changes/<name>/specs/ 目录
- 列出存在的功能规格
- 对于每个，提取需求名称（匹配 ### Requirement: <name> 的行）
检测规格冲突

构建一个映射 capability -> [changes that touch it]：
```
auth -> [change-a, change-b]  <- 冲突（2+ 变化）
api  -> [change-c]            <- 正常（仅1个变化）
```
当 2+ 个选定变化对同一功能有增量规格时，存在冲突。
智能解决冲突

对于每个冲突，调查代码库：

a. 读取增量规格 从每个冲突变化，了解每个声称添加/修改的内容

b. 搜索代码库 寻找实现证据：
- 寻找实现每个增量规格需求的代码
- 检查相关文件、函数或测试
c. 确定解决方案：
- 如果只有一个变化实际实现 -> 同步该变化的规格
- 如果两者都实现 -> 按时间顺序应用（旧的先，新的覆盖）
- 如果都没有实现 -> 跳过规格同步，警告用户
d. 记录解决方案 对于每个冲突：
- 应用哪个变化的规格
- 顺序（如果两者）
- 理由（在代码库中找到的内容）

显示合并状态表

显示一个总结所有变化的表格：

| 变化               | 工件 | 任务 | 规格   | 冲突 | 状态 |
|---------------------|-----------|-------|---------|-----------|--------|
| schema-management   | 完成      | 5/5   | 2 增量 | 无      | 准备就绪  |
| project-config      | 完成      | 3/3   | 1 增量 | 无      | 准备就绪  |
| add-oauth           | 完成      | 4/4   | 1 增量 | auth (!)  | 准备就绪* |
| add-verify-skill    | 1 剩余    | 2/5   | 无    | 无      | 警告   |

对于冲突，显示解决方案：

* 冲突解决：
  - auth 规格：将应用 add-oauth 然后 add-jwt（两者都实现，时间顺序）

对于未完成的变化，显示警告：

警告：
- add-verify-skill：1 个未完成工件，3 个未完成任务

确认批量操作

使用 AskUserQuestion 工具 进行单一确认：
- “归档 N 个变化？”根据状态提供选项
- 选项可能包括：
  - “归档所有 N 个变化”
  - “仅归档 N 个准备就绪的变化（跳过未完成）”
  - “取消”
如果有未完成的变化，明确说明它们将以警告归档。
对每个确认的变化执行归档

按确定的顺序处理变化（尊重冲突解决）：

a. 同步规格 如果有增量规格：
- 使用 openspec-sync-specs 方法（智能驱动的合并）
- 对于冲突，按解决顺序应用
- 跟踪是否同步
b. 执行归档：
```
mkdir -p openspec/changes/archive
mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
```
c. 跟踪结果 对于每个变化：
- 成功：成功归档
- 失败：归档期间出错（记录错误）
- 跳过：用户选择不归档（如果适用）

显示总结

显示最终结果：

## 批量归档完成

归档了 3 个变化：
- schema-management-cli -> archive/2026-01-19-schema-management-cli/
- project-config -> archive/2026-01-19-project-config/
- add-oauth -> archive/2026-01-19-add-oauth/

跳过了 1 个变化：
- add-verify-skill（用户选择不归档未完成的）

规格同步总结：
- 4 个增量规格同步到主规格
- 1 个冲突解决（auth：按时间顺序应用两者）

如果有任何失败：

失败了 1 个变化：
- some-change：归档目录已存在

冲突解决示例

示例 1: 只有一个实现

冲突: specs/auth/spec.md 被 [add-oauth, add-jwt] 触及

检查 add-oauth:
- 增量添加“OAuth 提供者集成”需求
- 搜索代码库... 找到 src/auth/oauth.ts 实现 OAuth 流程

检查 add-jwt:
- 增量添加“JWT 令牌处理”需求
- 搜索代码库... 未找到 JWT 实现

解决方案: 只有 add-oauth 实现。将仅同步 add-oauth 规格。

示例 2: 两者都实现

冲突: specs/api/spec.md 被 [add-rest-api, add-graphql] 触及

检查 add-rest-api (创建于 2026-01-10):
- 增量添加“REST 端点”需求
- 搜索代码库... 找到 src/api/rest.ts

检查 add-graphql (创建于 2026-01-15):
- 增量添加“GraphQL 模式”需求
- 搜索代码库... 找到 src/api/graphql.ts

解决方案: 两者都实现。将先应用 add-rest-api 规格，
然后 add-graphql 规格（时间顺序，新的优先）。

成功时输出

## 批量归档完成

归档了 N 个变化：
- <change-1> -> archive/YYYY-MM-DD-<change-1>/
- <change-2> -> archive/YYYY-MM-DD-<change-2>/

规格同步总结：
- N 个增量规格同步到主规格
- 无冲突（或: M 个冲突解决）

部分成功时输出

## 批量归档完成（部分）

归档了 N 个变化：
- <change-1> -> archive/YYYY-MM-DD-<change-1>/

跳过了 M 个变化：
- <change-2>（用户选择不归档未完成的）

失败了 K 个变化：
- <change-3>：归档目录已存在

无变化时输出

## 无变化可归档

未找到活动变化。使用 `/opsx:new` 创建新变化。

防护措施

允许任意数量的变化（1+ 有效，2+ 是典型用例）
始终提示选择，从不自动选择
早期检测规格冲突并通过检查代码库解决
当两者变化都实现时，按时间顺序应用规格
仅当实现缺失时跳过规格同步（警告用户）
在确认前显示清晰的每变化状态
对整个批次使用单一确认
跟踪并报告所有结果（成功/跳过/失败）
移动归档时保留 .openspec.yaml
归档目录目标使用当前日期：YYYY-MM-DD-<name>
如果归档目标存在，该变化失败但继续其他

名称: openspec-bulk-archive-change 描述: 一次性归档多个已完成的变化。在归档多个并行变化时使用。 许可证: MIT 兼容性: 需要 openspec CLI。 元数据: 作者: openspec 版本: “1.0” 生成者: “1.0.0”

名称: openspec-bulk-archive-change 描述: 一次性归档多个已完成的变化。在归档多个并行变化时使用。许可证: MIT 兼容性: 需要 openspec CLI。元数据: 作者: openspec 版本: “1.0” 生成者: “1.0.0”