用途：openspec-propose 是 OpenSpec 的规划类技能，用于在一步内创建新变更并生成全部规划产物。用户只需描述想构建或修复的内容，即可得到完整提案。该工作流只授权规划，不修改项目代码，产物完成后即停止，需等待用户新请求再启动 apply 工作流。
主要能力：按 schema 定义生成产物。默认 spec-driven schema 包括 proposal.md（做什么与为什么）、specs/<capability-path>/spec.md（系统必须做什么，是增量而非主规格）、design.md（怎么做）、tasks.md（实现步骤）。<capability-path> 是 specs/ 下的规格目录，如 user-auth 或 identity/user-auth。
使用方式：输入需包含 kebab-case 变更名或需求描述，否则先询问用户。若存在影响范围、外部行为、兼容性或验收标准的歧义，先向用户确认；细节可合理假设并记录。默认使用配置的 schema，用户明确指定时用 --schema <schema-name>。创建变更目录：openspec new change "<name>"。获取产物构建顺序：openspec status --change "<name>" --json，解析 applyRequires、artifacts、planningHome、changeRoot、artifactPaths、actionContext。按依赖顺序逐个创建产物，先取指令：openspec instructions <artifact-id> --change "<name>" --json，读取已完成依赖文件（从磁盘重读），按 template 写入 resolvedOutputPath。每创建一个产物后重跑 status。最后运行 openspec status --change "<name>" 并汇总。
Store 选择：若用户指定 store 或工作位于其中，先运行 openspec store list --json 获取已注册 store id，再在读写规格与变更的命令上追加 --store <id>，选定后保持粘性。无 store 时命令作用于最近的本地 openspec/ 根目录。
限制：仅规划，不实现、不启动 apply、不编辑项目代码；必须创建 apply 阶段传递依赖的全部产物，而非仅 apply.requires 列出的 id；status 仅反映文件是否存在，需依据 requires 边构建必需集合；已标记 skipped 的产物不得创建；若同名变更已存在，询问用户是继续还是新建。资料未提供收费、价格、平台与效果信息。