一次操作归档多个已完成的变更。
该技能允许你批量归档变更，并通过检查代码库来判断实际实现，从而智能处理规范冲突。
输入：无需输入（会提示选择）
步骤
- •
获取活动中的变更
运行
openspec list --json获取所有活动中的变更。如果没有活动中的变更，告知用户并停止。
- •
提示选择变更
使用 AskUserQuestion 工具 的多选让用户选择变更：
- •显示每个变更及其 schema
- •提供“所有变更”选项
- •允许任意数量的选择（1+ 可用，2+ 更常见）
重要：不要自动选择。始终让用户选择。
- •
批量校验 - 收集所有选定变更的状态
对每个选定变更，收集：
a. 工件状态 - 运行
openspec status --change "<name>" --json- •解析
schemaName与artifacts列表 - •标注哪些工件为
done，哪些为其他状态
b. 任务完成情况 - 读取
openspec/changes/<name>/tasks.md- •统计
- [ ]（未完成）与- [x]（完成） - •如无 tasks 文件，标注为“无任务”
c. delta 规范 - 检查
openspec/changes/<name>/specs/目录- •列出存在的能力规范
- •对每个规范，提取需求名称（匹配
### Requirement: <name>的行）
- •解析
- •
检测规范冲突
构建
capability -> [触及该能力的变更]的映射：codeauth -> [change-a, change-b] <- 冲突（2+ 变更） api -> [change-c] <- OK（仅 1 个变更）
当 2+ 个变更对同一能力有 delta 规范时视为冲突。
- •
智能解决冲突
针对每个冲突，调查代码库：
a. 读取冲突变更的 delta 规范，理解各自声称新增/修改的内容
b. 在代码库中搜索实现证据：
- •查找与各自需求相关的实现代码
- •检查相关文件、函数或测试
c. 确定处理方案：
- •仅一个变更已实现 -> 仅同步该变更的规范
- •两个都已实现 -> 按时间顺序应用（先旧后新，新覆盖旧）
- •都未实现 -> 跳过规范同步并警告
d. 记录每个冲突的解决方案：
- •应用哪个变更的规范
- •应用顺序（如两者都实现）
- •依据（代码库中的发现）
- •
显示汇总状态表
展示所有变更的汇总表：
code| Change | Artifacts | Tasks | Specs | Conflicts | Status | |---------------------|-----------|-------|---------|-----------|--------| | schema-management | Done | 5/5 | 2 delta | None | Ready | | project-config | Done | 3/3 | 1 delta | None | Ready | | add-oauth | Done | 4/4 | 1 delta | auth (!) | Ready* | | add-verify-skill | 1 left | 2/5 | None | None | Warn |
对冲突展示解决方案：
code* 冲突解决方案： - auth 规范：将先应用 add-oauth，再应用 add-jwt（两者已实现，按时间顺序）
对未完成变更展示警告：
code警告： - add-verify-skill：1 个工件未完成，3 个任务未完成
- •
确认批量操作
使用 AskUserQuestion 工具 进行单次确认：
- •“归档 N 个变更？”并根据状态提供选项
- •选项可能包括：
- •“归档全部 N 个变更”
- •“仅归档 N 个就绪变更（跳过未完成）”
- •“取消”
如果存在未完成变更，明确说明将带警告归档。
- •
对每个确认的变更执行归档
按确定的顺序处理（遵循冲突解决顺序）：
a. 如存在 delta 规范则同步规范：
- •使用 openspec-sync-specs 的方式（agent 驱动的智能合并）
- •冲突时按已确定的顺序应用
- •记录是否已同步
b. 执行归档：
bashmkdir -p openspec/changes/archive mv openspec/changes/<name> openspec/changes/archive/YYYY-MM-DD-<name>
c. 记录每个变更的结果：
- •成功：已成功归档
- •失败：归档出错（记录错误）
- •跳过：用户选择不归档（如适用）
- •
显示摘要
展示最终结果：
code## 批量归档完成 已归档 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 个 delta 规范到主规范 - 已解决 1 个冲突（auth：按时间顺序应用两者）
如果有失败：
code失败 1 个变更： - some-change: 归档目录已存在
冲突解决示例
示例 1：仅一个已实现
code
Conflict: specs/auth/spec.md touched by [add-oauth, add-jwt] Checking add-oauth: - Delta adds "OAuth Provider Integration" requirement - Searching codebase... found src/auth/oauth.ts implementing OAuth flow Checking add-jwt: - Delta adds "JWT Token Handling" requirement - Searching codebase... no JWT implementation found Resolution: Only add-oauth is implemented. Will sync add-oauth specs only.
示例 2：两者均已实现
code
Conflict: specs/api/spec.md touched by [add-rest-api, add-graphql] Checking add-rest-api (created 2026-01-10): - Delta adds "REST Endpoints" requirement - Searching codebase... found src/api/rest.ts Checking add-graphql (created 2026-01-15): - Delta adds "GraphQL Schema" requirement - Searching codebase... found src/api/graphql.ts Resolution: Both implemented. Will apply add-rest-api specs first, then add-graphql specs (chronological order, newer takes precedence).
成功输出
code
## 批量归档完成 已归档 N 个变更： - <change-1> -> archive/YYYY-MM-DD-<change-1>/ - <change-2> -> archive/YYYY-MM-DD-<change-2>/ 规范同步摘要： - 已同步 N 个 delta 规范到主规范 - 无冲突（或：已解决 M 个冲突）
部分成功输出
code
## 批量归档完成（部分） 已归档 N 个变更： - <change-1> -> archive/YYYY-MM-DD-<change-1>/ 跳过 M 个变更： - <change-2>（用户选择不归档未完成变更） 失败 K 个变更： - <change-3>: 归档目录已存在
无可归档变更时输出
code
## 没有可归档的变更 未找到活动中的变更。使用 `/opsx:new` 创建新的变更。
护栏
- •允许任意数量的变更（1+ 可用，2+ 更常见）
- •始终提示选择，不要自动选择
- •提前检测规范冲突并通过检查代码库解决
- •当两者都已实现时，按时间顺序应用规范
- •仅在实现缺失时跳过规范同步（提示警告）
- •确认前清晰展示每个变更的状态
- •整批只做一次确认
- •跟踪并报告所有结果（成功/跳过/失败）
- •移动时保留 .openspec.yaml
- •归档目录使用当前日期：YYYY-MM-DD-<name>
- •若归档目标已存在，当前变更失败但继续处理其他变更