通过创建下一个产出物继续处理变更。
输入：可选指定变更名称。如果省略，检查是否可以从对话上下文中推断。如果模糊或不明确，你必须提示获取可用变更。
步骤
- 如果没有提供变更名称，提示选择 运行
openspec-cn list --json获取按最近修改排序的可用变更。然后使用 AskUserQuestion tool 让用户选择要处理哪个变更。 展示前 3-4 个最近修改的变更作为选项，显示： 将最近修改的变更标记为 "(推荐)"，因为它很可能是用户想要继续的。 重要提示：不要猜测或自动选择变更。始终让用户选择。
- 变更名称 - Schema（如果存在 schema 字段，否则为 "spec-driven"） - 状态（例如："0/5 tasks", "complete", "no tasks"） - 最近修改时间（来自 lastModified 字段）
- 检查当前状态
openspec-cn status --change "<name>" --jsonParse the JSON to understand current state. The response includes:
- schemaName: The workflow schema being used (e.g., "spec-driven") - artifacts: Array of artifacts with their status ("done", "ready", "blocked") - isComplete: Boolean indicating if all artifacts are complete
- 根据状态行动： 如果所有产出物已完成 (
isComplete: true)： 如果产出物准备好创建（状态显示有status: "ready"的产出物）： 如果没有产出物准备好（全部受阻）：
- 祝贺用户 - 显示最终状态，包括使用的 Schema - 建议："所有产出物已创建！您现在可以实现此变更或将其归档。" - 停止 - 从状态输出中选择第一个 status: "ready" 的产出物 - 获取其指令： openspec-cn instructions <artifact-id> --change "<name>" --json - Parse the JSON. The key fields are: - context: Project background (constraints for you - do NOT include in output) - rules: Artifact-specific rules (constraints for you - do NOT include in output) - template: The structure to use for your output file - instruction: Schema-specific guidance - outputPath: Where to write the artifact - dependencies: Completed artifacts to read for context - Create the artifact file: - Read any completed dependency files for context - Use template as the structure - fill in its sections - Apply context and rules as constraints when writing - but do NOT copy them into the file - Write to the output path specified in instructions - Show what was created and what's now unlocked - STOP after creating ONE artifact - 在有效的 Schema 下不应发生这种情况 - 显示状态并建议检查问题
- 创建产出物后，显示进度
openspec-cn status --change "<name>"
输出
每次调用后，显示：
- 创建了哪个产出物
- 正在使用的 Schema 工作流
- 当前进度（N/M 完成）
- 现在解锁了哪些产出物
- 提示："想要继续吗？只需让我继续或告诉我下一步做什么。"
产出物创建指南
产出物类型及其用途取决于 Schema。使用指令输出中的 instruction 字段来了解要创建什么。
常见的产出物模式：
spec-driven schema (proposal → specs → design → tasks):
- proposal.md: Ask user about the change if not clear. Fill in Why, What Changes, Capabilities, Impact.
- The Capabilities section is critical - each capability listed will need a spec file.
- specs//spec.md: Create one spec per capability listed in the proposal's Capabilities section (use the capability name, not the change name).
- design.md: Document technical decisions, architecture, and implementation approach.
- tasks.md: Break down implementation into checkboxed tasks.
For other schemas, follow the instruction field from the CLI output.
Guardrails
- Create ONE artifact per invocation
- Always read dependency artifacts before creating a new one
- Never skip artifacts or create out of order
- If context is unclear, ask the user before creating
- Verify the artifact file exists after writing before marking progress
- Use the schema's artifact sequence, don't assume specific artifact names
- IMPORTANT:
contextandrulesare constraints for YOU, not content for the file
- Do NOT copy <context>, <rules>, <project_context> blocks into the artifact - These guide what you write, but should never appear in the output