0d649b76a2
7.2 KiB
name, description, license, compatibility, metadata
| name | description | license | compatibility | metadata | ||||||
|---|---|---|---|---|---|---|---|---|---|---|
| openspec-bulk-archive-change | 一次性归档多个已完成的变更。当归档多个并行变更时使用。 | MIT | Requires openspec CLI. |
|
在单个操作中归档多个已完成的变更。
该技能允许你批量归档变更,通过检查代码库来确定实际实现的内容,智能地处理 spec 冲突。
输入: 无需输入 (会提示选择)
步骤
-
获取活跃的变更
运行
openspec list --json获取所有活跃的变更。如果不存在活跃的变更,通知用户并停止。
-
提示变更选择
使用 AskUserQuestion 工具进行多选,让用户选择变更:
- 显示每个变更及其 schema
- 包含"所有变更"选项
- 允许任意数量的选择 (1+ 即可,2+ 是典型用例)
重要: 不要自动选择。始终让用户选择。
-
批量验证 - 收集所有选定变更的状态
对于每个选定的变更,收集:
a. Artifact 状态 - 运行
openspec status --change "<name>" --json- 解析
schemaName和artifacts列表 - 注意哪些 artifacts 是
done状态 vs 其他状态
b. 任务完成度 - 读取
openspec/changes/<name>/tasks.md- 统计
- [ ](未完成) vs- [x](已完成) - 如果不存在任务文件,注明 "无任务"
c. Delta specs - 检查
openspec/changes/<name>/specs/目录- 列出存在哪些 capability specs
- 对于每个,提取需求名称 (匹配
### Requirement: <name>的行)
- 解析
-
检测 spec 冲突
建立
capability -> [涉及它的变更]映射:auth -> [change-a, change-b] <- 冲突 (2+ 个变更) api -> [change-c] <- 正常 (只有 1 个变更)当 2+ 个选定的变更对同一个 capability 有 delta specs 时,存在冲突。
-
智能解决冲突
对于每个冲突,调查代码库:
a. 读取 delta specs 从每个冲突的变更中,了解每个声称添加/修改的内容
b. 搜索代码库寻找实现证据:
- 寻找实现每个 delta spec 需求的代码
- 检查相关的文件、函数或测试
c. 确定解决方案:
- 如果只有一个变更实际实现了 -> 同步那个的 specs
- 如果两者都实现了 -> 按时间顺序应用 (较旧的先,较新的覆盖)
- 如果都未实现 -> 跳过 spec 同步,警告用户
d. 记录解决方案对于每个冲突:
- 应用哪个变更的 specs
- 以什么顺序 (如果两者都有)
- 理由 (在代码库中找到了什么)
-
显示综合状态表
显示总结所有变更的表格:
| 变更 | Artifacts | 任务 | Specs | 冲突 | 状态 | |--------------------|-----------|-------|---------|-----------|--------| | schema-management | 完成 | 5/5 | 2 delta | 无 | 就绪 | | project-config | 完成 | 3/3 | 1 delta | 无 | 就绪 | | add-oauth | 完成 | 4/4 | 1 delta | auth (!) | 就绪* | | add-verify-skill | 剩余 1 | 2/5 | 无 | 无 | 警告 |对于冲突,显示解决方案:
* 冲突解决: - auth spec: 将应用 add-oauth 然后 add-jwt (两者都已实现,按时间顺序)对于未完成的变更,显示警告:
警告: - add-verify-skill: 1 个未完成 artifact, 3 个未完成任务 -
确认批量操作
使用 AskUserQuestion 工具进行单次确认:
- "归档 N 个变更?" 根据状态提供选项
- 选项可能包括:
- "归档所有 N 个变更"
- "仅归档 N 个就绪的变更 (跳过未完成的)"
- "取消"
如果有未完成的变更,明确说明它们将带警告归档。
-
为每个确认的变更执行归档
按确定的顺序处理变更 (遵循冲突解决方案):
a. 同步 specs 如果存在 delta specs:
- 使用 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 (用户选择不归档未完成的) Spec 同步摘要: - 4 个 delta specs 同步到主 specs - 1 个冲突已解决 (auth: 按时间顺序应用两者)如果有任何失败:
失败 1 个变更: - some-change: 归档目录已存在
冲突解决示例
示例 1: 只有一个已实现
冲突: specs/auth/spec.md 被 [add-oauth, add-jwt] 涉及
检查 add-oauth:
- Delta 添加了 "OAuth 提供者集成" 需求
- 搜索代码库... 找到 src/auth/oauth.ts 实现 OAuth 流程
检查 add-jwt:
- Delta 添加了 "JWT 令牌处理" 需求
- 搜索代码库... 未找到 JWT 实现
解决: 只有 add-oauth 已实现。将仅同步 add-oauth specs。
示例 2: 两者都已实现
冲突: specs/api/spec.md 被 [add-rest-api, add-graphql] 涉及
检查 add-rest-api (创建于 2026-01-10):
- Delta 添加了 "REST 端点" 需求
- 搜索代码库... 找到 src/api/rest.ts
检查 add-graphql (创建于 2026-01-15):
- Delta 添加了 "GraphQL Schema" 需求
- 搜索代码库... 找到 src/api/graphql.ts
解决: 两者都已实现。将先应用 add-rest-api specs,
然后应用 add-graphql specs (按时间顺序,较新的优先)。
成功时的输出
## 批量归档完成
已归档 N 个变更:
- <change-1> -> archive/YYYY-MM-DD-<change-1>/
- <change-2> -> archive/YYYY-MM-DD-<change-2>/
Spec 同步摘要:
- N 个 delta specs 同步到主 specs
- 无冲突 (或: M 个冲突已解决)
部分成功时的输出
## 批量归档完成 (部分)
已归档 N 个变更:
- <change-1> -> archive/YYYY-MM-DD-<change-1>/
跳过 M 个变更:
- <change-2> (用户选择不归档未完成的)
失败 K 个变更:
- <change-3>: 归档目录已存在
无变更时的输出
## 无变更可归档
未找到活跃的变更。使用 `/opsx-new` 创建新变更。
防护机制
- 允许任意数量的变更 (1+ 即可,2+ 是典型用例)
- 始终提示选择,永不自动选择
- 提前检测 spec 冲突并通过检查代码库解决
- 当两个变更都已实现时,按时间顺序应用 specs
- 仅当实现缺失时跳过 spec 同步 (警告用户)
- 在确认前显示清晰的每个变更状态
- 对整个批次使用单次确认
- 跟踪并报告所有结果 (成功/跳过/失败)
- 移动到归档时保留 .openspec.yaml
- 归档目录目标使用当前日期: YYYY-MM-DD-
- 如果归档目标存在,使该变更失败但继续处理其他变更