51172e8c5a
All checks were successful
Docker Build & Deploy / Build Docker Image (push) Successful in 4m27s
Docker Build & Deploy / Deploy to Production (push) Successful in 7s
Docker Build & Deploy / Cleanup Dangling Images (push) Successful in 1s
Docker Build & Deploy / WeChat Notification (push) Successful in 1s
119 lines
4.7 KiB
Markdown
119 lines
4.7 KiB
Markdown
---
|
|
name: openspec-continue-change
|
|
description: Continue working on an OpenSpec change by creating the next artifact. Use when the user wants to progress their change, create the next artifact, or continue their workflow.
|
|
license: MIT
|
|
compatibility: Requires openspec CLI.
|
|
metadata:
|
|
author: openspec
|
|
version: "1.0"
|
|
generatedBy: "1.1.1"
|
|
---
|
|
|
|
通过创建下一个 artifact 来继续处理变更。
|
|
|
|
**输入**：可选地指定变更名称。如果省略,则检查是否可以从对话上下文推断。如果模糊或不明确,您**必须**提示用户选择可用的变更。
|
|
|
|
**步骤**
|
|
|
|
1. **如果未提供变更名称,提示选择**
|
|
|
|
运行 `openspec list --json` 获取按最近修改时间排序的可用变更。然后使用 **AskUserQuestion 工具**让用户选择要处理的变更。
|
|
|
|
将最近修改的前 3-4 个变更作为选项呈现,显示:
|
|
- 变更名称
|
|
- Schema(如果存在 `schema` 字段则显示,否则为 "spec-driven")
|
|
- 状态(例如 "0/5 个任务"、"完成"、"无任务")
|
|
- 最近修改时间(来自 `lastModified` 字段)
|
|
|
|
将最近修改的变更标记为 "(推荐)",因为这可能是用户想要继续的内容。
|
|
|
|
**重要**: 不要猜测或自动选择变更。始终让用户选择。
|
|
|
|
2. **检查当前状态**
|
|
```bash
|
|
openspec status --change "<name>" --json
|
|
```
|
|
解析 JSON 以了解当前状态。响应包括:
|
|
- `schemaName`: 正在使用的工作流 schema(例如 "spec-driven")
|
|
- `artifacts`: 包含状态的 artifacts 数组("done"、"ready"、"blocked")
|
|
- `isComplete`: 指示所有 artifacts 是否完成的布尔值
|
|
|
|
3. **根据状态采取行动**:
|
|
|
|
---
|
|
|
|
**如果所有 artifacts 都已完成(`isComplete: true`)**:
|
|
- 祝贺用户
|
|
- 显示最终状态,包括使用的 schema
|
|
- 建议: "所有 artifacts 已创建! 现在可以实施此变更或归档它。"
|
|
- 停止
|
|
|
|
---
|
|
|
|
**如果 artifacts 准备创建**(状态显示 `status: "ready"` 的 artifacts):
|
|
- 从状态输出中选择**第一个** `status: "ready"` 的 artifact
|
|
- 获取其说明:
|
|
```bash
|
|
openspec instructions <artifact-id> --change "<name>" --json
|
|
```
|
|
- 解析 JSON。关键字段是:
|
|
- `context`: 项目背景(对您的约束 - 不要包含在输出中)
|
|
- `rules`: Artifact 特定规则(对您的约束 - 不要包含在输出中)
|
|
- `template`: 用于输出文件的结构
|
|
- `instruction`: Schema 特定指导
|
|
- `outputPath`: artifact 的写入位置
|
|
- `dependencies`: 已完成的 artifacts,读取以获取上下文
|
|
- **创建 artifact 文件**:
|
|
- 读取任何已完成的依赖文件以获取上下文
|
|
- 使用 `template` 作为结构 - 填充其各个部分
|
|
- 在写入时应用 `context` 和 `rules` 作为约束 - 但不要将它们复制到文件中
|
|
- 写入说明中指定的输出路径
|
|
- 显示创建的内容以及现在解锁的内容
|
|
- 创建一个 artifact 后停止
|
|
|
|
---
|
|
|
|
**如果没有 artifacts 准备好(全部被阻塞)**:
|
|
- 使用有效的 schema 不应该发生这种情况
|
|
- 显示状态并建议检查问题
|
|
|
|
4. **创建 artifact 后,显示进度**
|
|
```bash
|
|
openspec status --change "<name>"
|
|
```
|
|
|
|
**输出**
|
|
|
|
每次调用后,显示:
|
|
- 创建了哪个 artifact
|
|
- 正在使用的 Schema 工作流
|
|
- 当前进度(已完成 N/M)
|
|
- 现在解锁了哪些 artifacts
|
|
- 提示: "想要继续吗? 只需让我继续或告诉我下一步该做什么。"
|
|
|
|
**Artifact 创建指南**
|
|
|
|
artifact 类型及其用途取决于 schema。使用说明输出中的 `instruction` 字段来了解要创建什么。
|
|
|
|
常见 artifact 模式:
|
|
|
|
**spec-driven schema**(proposal → specs → design → tasks):
|
|
- **proposal.md**: 如果不清楚,询问用户关于变更的信息。填写为什么、什么变更、能力、影响。
|
|
- Capabilities 部分至关重要 - 列出的每个能力都需要一个 spec 文件。
|
|
- **specs/<capability>/spec.md**: 为 proposal 的 Capabilities 部分列出的每个能力创建一个 spec(使用能力名称,而不是变更名称)。
|
|
- **design.md**: 记录技术决策、架构和实施方法。
|
|
- **tasks.md**: 将实施分解为带复选框的任务。
|
|
|
|
对于其他 schemas,遵循 CLI 输出中的 `instruction` 字段。
|
|
|
|
**护栏**
|
|
- 每次调用创建一个 artifact
|
|
- 在创建新 artifact 之前始终读取依赖 artifacts
|
|
- 永远不要跳过 artifacts 或无序创建
|
|
- 如果上下文不清楚,在创建前询问用户
|
|
- 写入后验证 artifact 文件存在,然后再标记进度
|
|
- 使用 schema 的 artifact 序列,不要假设特定的 artifact 名称
|
|
- **重要**: `context` 和 `rules` 是对您的约束,不是文件内容
|
|
- 不要将 `<context>`、`<rules>`、`<project_context>` 块复制到 artifact 中
|
|
- 这些指导您写什么,但永远不应出现在输出中
|