OpenSpec 变更继续处理指南：自动化创建下一个工件，提升开发效率

3. 根据状态采取行动：

如果所有工件都已完成（isComplete: true）：

 * 祝贺用户
 * 显示最终状态，包括使用的模式
 * 建议："所有工件已创建！您现在可以实现此变更或将其归档。"
 * 停止

如果有工件准备就绪可以创建（状态显示 status: "ready" 的工件）：

 * 从状态输出中选取第一个 `status: "ready"` 的工件
 * 获取其指令：
       
       openspec instructions <artifact-id> --change "<name>" --json
       

 * 解析 JSON。关键字段是：
   * `context`：项目背景（对你的约束 - 不要包含在输出中）
   * `rules`：工件特定规则（对你的约束 - 不要包含在输出中）
   * `template`：用于输出文件的结构
   * `instruction`：模式特定的指导
   * `outputPath`：写入工件的位置
   * `dependencies`：为获取上下文而读取的已完成工件
 * **创建工件文件**：
   * 读取任何已完成的依赖文件以获取上下文
   * 使用 `template` 作为结构 - 填写其各个部分
   * 在编写时应用 `context` 和 `rules` 作为约束 - 但不要将它们复制到文件中
   * 写入指令中指定的输出路径
 * 显示创建了什么以及现在解锁了什么
 * 创建一个工件后停止

如果没有工件准备就绪（全部被阻塞）：

 * 对于有效的模式，这不应该发生
 * 显示状态并建议检查问题

4. 创建工件后，显示进度

     openspec status --change "<name>"
     

输出

每次调用后，显示：

• 创建了哪个工件
• 正在使用的模式工作流
• 当前进度（完成 N/M）
• 现在解锁了哪些工件
• 提示："想要继续吗？只需让我继续或告诉我下一步做什么。"

工件创建指南

工件的类型及其用途取决于模式。使用指令输出中的 instruction 字段来理解要创建什么。

常见的工件模式：

spec-driven 模式（提案 → 规范 → 设计 → 任务）：

• proposal.md：如果不清楚，询问用户关于变更的信息。填写为什么、更改内容、能力、影响。
  • 能力部分至关重要 - 列出的每个能力都需要一个规范文件。
• specs//spec.md：为提案的能力部分中列出的每个能力创建一个规范（使用能力名称，而不是变更名称）。
• design.md：记录技术决策、架构和实现方法。
• tasks.md：将实现分解为带复选框的任务。

对于其他模式，遵循 CLI 输出中的 instruction 字段。

防护措施

• 每次调用创建一个工件
• 创建新工件前始终读取依赖工件
• 永远不要跳过工件或乱序创建
• 如果上下文不清楚，在创建前询问用户
• 在标记进度之前，验证写入后工件文件是否存在
• 使用模式的工件序列，不要假设特定的工件名称
• 重要：context 和 rules 是对你的约束，不是文件的内容
  • 不要将 <context>、<rules>、<project_context> 块复制到工件中
  • 这些指导你编写的内容，但绝不应出现在输出中

每周安装数

1

仓库

afterthought/sa…ntroller

首次出现

1 天前

安全审计

Gen Agent Trust HubPassSocketFailSnykPass

安装于

zencoder1

amp1

cline1

openclaw1

opencode1

cursor1

Parse 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

3. Act based on status :

If all artifacts are complete (isComplete: true):

 * Congratulate the user
 * Show final status including the schema used
 * Suggest: "All artifacts created! You can now implement this change or archive it."
 * STOP

If artifacts are ready to create (status shows artifacts with status: "ready"):

 * Pick the FIRST artifact with `status: "ready"` from the status output
 * Get its instructions: 
       
       openspec 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

If no artifacts are ready (all blocked) :

 * This shouldn't happen with a valid schema
 * Show status and suggest checking for issues

4. After creating an artifact, show progress

     openspec status --change "<name>"
     

Output

After each invocation, show:

• Which artifact was created
• Schema workflow being used
• Current progress (N/M complete)
• What artifacts are now unlocked
• Prompt: "Want to continue? Just ask me to continue or tell me what to do next."

Artifact Creation Guidelines

The artifact types and their purpose depend on the schema. Use the instruction field from the instructions output to understand what to create.

Common artifact patterns:

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 : context and rules are 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

Weekly Installs

1

Repository

afterthought/sa…ntroller

First Seen

1 day ago

Security Audits

Gen Agent Trust HubPassSocketFailSnykPass

Installed on

zencoder1

amp1

cline1

openclaw1

opencode1

cursor1