用途：openspec-propose 是 OpenSpec 的规划工作流技能，用于在一步内创建新变更并生成 schema 定义的全部规划产物。它只做规划，不修改项目代码；即使用户请求中包含实现或修复意图，该请求也只授权规划。产物完成后应停止，等待用户新的请求再启动 apply 工作流。
主要能力：按默认 spec-driven schema 生成 proposal.md（做什么与为什么）、specs/<capability-path>/spec.md（系统必须做什么，是增量而非主 spec）、design.md（怎么做）、tasks.md（实现步骤）。capability-path 是相对 specs/ 的目录路径，需保留已有能力的完整路径。
使用方式：输入需包含 kebab-case 变更名或需求描述，否则先询问用户想构建或修复什么。若存在影响范围、外部可观察行为、兼容性或验收标准的歧义，先向用户确认；次要细节可合理假设并记录。若用户指定 store，先运行 openspec store list --json 获取 id，并在读写 spec 与变更的命令上追加 --store <id>，选定后保持粘性。创建变更目录：openspec new change "<name>"，指定 schema 时加 --schema "<schema-name>"。用 openspec status --change "<name>" --json 获取 applyRequires、artifacts 及依赖边，按依赖顺序逐个用 openspec instructions <artifact-id> --change "<name>" --json 获取模板与指引并写入 resolvedOutputPath。每创建一个产物后重新运行 status，直到必需集合（applyRequires 及其传递依赖）全部完成、跳过或按条件跳过。最后运行 openspec status --change "<name>" 并汇总变更名、位置、产物清单与跳过原因。
适用场景：需要快速把想法转成结构化变更提案、生成规格增量与任务拆分的规划阶段。
限制：不实现变更、不启动 apply、不编辑项目代码；context 与 rules 是约束而非文件内容，不得写入产物；status 仅反映文件是否存在，需按 requires 边判断依赖；已标记 skipped 的产物不得创建；design.md 等条件性产物仅在指令标注可选时跳过。若同名变更已存在，需询问用户是继续还是新建。具体 schema 名称、store 配置与命令输出细节以实际 CLI 为准，资料未提供更多平台与收费信息。