0d649b76a2
All checks were successful
Docker Build & Deploy / Build Docker Image (push) Successful in 23s
Docker Build & Deploy / Deploy to Production (push) Successful in 8s
Docker Build & Deploy / Cleanup Dangling Images (push) Successful in 1s
Docker Build & Deploy / WeChat Notification (push) Successful in 1s
102 lines
4.1 KiB
Markdown
102 lines
4.1 KiB
Markdown
---
|
|
name: openspec-ff-change
|
|
description: 快进 OpenSpec artifact 创建过程。当用户想要快速创建实施所需的所有 artifacts 而无需逐个步骤时使用。
|
|
license: MIT
|
|
compatibility: Requires openspec CLI.
|
|
metadata:
|
|
author: openspec
|
|
version: "1.0"
|
|
generatedBy: "1.1.1"
|
|
---
|
|
|
|
快速完成 artifact 创建 - 一次性生成开始实现所需的所有内容。
|
|
|
|
**输入**: 用户的请求应该包含变更名称 (kebab-case) 或对他们想要构建的内容的描述。
|
|
|
|
**步骤**
|
|
|
|
1. **如果未提供明确输入,询问他们想要构建什么**
|
|
|
|
使用 **AskUserQuestion 工具** (开放式,无预设选项) 询问:
|
|
> "你想要处理什么变更?描述你想要构建或修复的内容。"
|
|
|
|
从他们的描述中,导出 kebab-case 名称 (例如: "add user authentication" → `add-user-auth`)。
|
|
|
|
**重要**: 不要在不了解用户想要构建什么的情况下继续。
|
|
|
|
2. **创建变更目录**
|
|
```bash
|
|
openspec new change "<name>"
|
|
```
|
|
这将在 `openspec/changes/<name>/` 创建一个脚手架变更。
|
|
|
|
3. **获取 artifact 构建顺序**
|
|
```bash
|
|
openspec status --change "<name>" --json
|
|
```
|
|
解析 JSON 以获取:
|
|
- `applyRequires`: 实现前需要的 artifact ID 数组 (例如: `["tasks"]`)
|
|
- `artifacts`: 所有 artifacts 的列表及其状态和依赖关系
|
|
|
|
4. **按顺序创建 artifacts 直到准备好应用**
|
|
|
|
使用 **TodoWrite 工具**跟踪 artifacts 的进度。
|
|
|
|
按依赖顺序循环 artifacts (没有待处理依赖关系的 artifacts 优先):
|
|
|
|
a. **对于每个 `ready` 状态的 artifact (依赖关系已满足)**:
|
|
- 获取指令:
|
|
```bash
|
|
openspec instructions <artifact-id> --change "<name>" --json
|
|
```
|
|
- 指令 JSON 包括:
|
|
- `context`: 项目背景 (对你的约束 - 不要包含在输出中)
|
|
- `rules`: Artifact 特定规则 (对你的约束 - 不要包含在输出中)
|
|
- `template`: 用于输出文件的结构
|
|
- `instruction`: 此 artifact 类型的 schema 特定指导
|
|
- `outputPath`: artifact 写入位置
|
|
- `dependencies`: 要读取以获取上下文的已完成 artifacts
|
|
- 读取任何已完成的依赖文件以获取上下文
|
|
- 使用 `template` 作为结构创建 artifact 文件
|
|
- 将 `context` 和 `rules` 作为约束应用 - 但不要将它们复制到文件中
|
|
- 显示简短进度: "✓ 已创建 <artifact-id>"
|
|
|
|
b. **继续直到所有 `applyRequires` artifacts 完成**
|
|
- 创建每个 artifact 后,重新运行 `openspec status --change "<name>" --json`
|
|
- 检查 `applyRequires` 中的每个 artifact ID 在 artifacts 数组中的 `status: "done"`
|
|
- 当所有 `applyRequires` artifacts 都完成时停止
|
|
|
|
c. **如果 artifact 需要用户输入** (上下文不清楚):
|
|
- 使用 **AskUserQuestion 工具**澄清
|
|
- 然后继续创建
|
|
|
|
5. **显示最终状态**
|
|
```bash
|
|
openspec status --change "<name>"
|
|
```
|
|
|
|
**输出**
|
|
|
|
完成所有 artifacts 后,总结:
|
|
- 变更名称和位置
|
|
- 创建的 artifacts 列表及简短描述
|
|
- 准备就绪的内容: "所有 artifacts 已创建!准备实现。"
|
|
- 提示: "运行 `/opsx-apply` 或要求我实现以开始处理任务。"
|
|
|
|
**Artifact 创建指南**
|
|
|
|
- 遵循每个 artifact 类型的 `openspec instructions` 中的 `instruction` 字段
|
|
- Schema 定义了每个 artifact 应该包含什么 - 遵循它
|
|
- 在创建新 artifacts 之前读取依赖 artifacts 以获取上下文
|
|
- 使用 `template` 作为输出文件的结构 - 填充其部分
|
|
- **重要**: `context` 和 `rules` 是对你的约束,而不是文件的内容
|
|
- 不要将 `<context>`, `<rules>`, `<project_context>` 块复制到 artifact 中
|
|
- 这些指导你写什么,但永远不应该出现在输出中
|
|
|
|
**防护机制**
|
|
- 创建实现所需的所有 artifacts (由 schema 的 `apply.requires` 定义)
|
|
- 在创建新 artifact 之前始终读取依赖 artifacts
|
|
- 如果上下文严重不清楚,询问用户 - 但更倾向于做出合理决策以保持势头
|
|
- 如果已存在同名变更,建议继续该变更
|
|
- 在继续下一个之前验证每个 artifact 文件是否存在
|