openspec-propose

用途：根据用户描述，一次生成一个新变更所需的全部规划产物。规划边界明确：该工作流只创建规划文档，即便用户请求中包含实现或修复要求，也不得编辑项目代码，产物完成后必须停止，等待新的用户请求再启动 apply 工作流。\n\n主要能力：使用默认的 spec-driven schema 会生成 proposal.md（做什么与为什么）、specs/<capability-path>/spec.md（系统必须做什么，是增量而非主 spec）、design.md（如何做）、tasks.md（实现步骤）。capability-path 是相对 specs/ 的目录路径，需保留既有能力的完整路径。\n\n使用方式：先理解请求并澄清影响范围的歧义；未提供清晰输入时，向用户提问“What change do you want to work on? Describe what you want to build or fix.”，由描述推导 kebab-case 名称。除非用户明确指定，否则省略 --schema 使用配置默认值。若用户指定了 store，运行 openspec store list --json 获取 id，并在读取或写入 specs 与 changes 的命令上追加 --store <id>，该选择在此工作流后续保持粘性。创建变更目录：openspec new change "<name>" 或加 --schema "<schema-name>"。用 openspec status --change "<name>" --json 获取 artifact 构建顺序与路径，按依赖顺序对每个 artifact 运行 openspec instructions <artifact-id> --change "<name>" --json，按其 template 写入 resolvedOutputPath，context 与 rules 仅作约束不得写入文件。完成后运行 openspec status --change "<name>" 并向用户汇总。\n\n适用场景：需要为某个功能或修复快速产出结构化变更提案与规划文档时。\n\n限制：只做规划，不实现、不启动 apply、不编辑项目代码；需创建 apply 阶段传递依赖的全部 artifact，而非仅 apply.requires 列出的；创建新 artifact 前必须从磁盘重读依赖文件；每个 artifact 写入后需确认文件存在；若同名变更已存在，需询问是继续还是新建；跳过条件性 artifact 需依 instruction 标记；未提供 store 时命令作用于最近的本地 openspec/ 根目录。