用途：帮助用户把早期想法转化为 spec-driven 变更提案，属于规划阶段，不实现代码。
前提：项目根目录必须存在 .spec-driven/ 目录，可用 ls .spec-driven/ 检查；若失败需先运行 /spec-driven-init。
主要流程：从想法而非产物清单出发，询问目标、问题、约束与偏好，不要求预先提供变更名称。尽早阅读项目上下文与现有规格：.spec-driven/config.yaml（context 作为背景，rules 作为约束）、.spec-driven/specs/INDEX.md，以及 INDEX.md 中与想法相关的主规格文件。围绕期望结果、用户可见行为、范围与明确排除项、权衡与风险、可能修改的规格文件或是否需要新规格区域、待人工回答的问题进行收敛。想法足够清晰后，建议一个短 kebab-case 变更名称；用户已提供有效名称则保留。创建文件前先给出提案检查点，汇总名称、目标与范围、预计变更的规格区域、已定决策与未决问题，并请求明确确认；用户要求修改则继续头脑风暴并重新汇总。确认后运行 node {{SKILL_DIR}}/scripts/spec-driven.js propose <name> 生成 .spec-driven/changes/<name>/ 及模板。随后填写五份提案产物：proposal.md（What、Why、Scope、Unchanged Behavior）、design.md（Approach、Key Decisions、Alternatives Considered）、changes/<name>/specs/ 下与主规格路径对齐的 delta 规格文件、tasks.md（## Implementation、## Testing、## Verification 下的原子清单）、questions.md（未决点记入 ## Open，无则留 <!-- No open questions -->）。最后运行 node {{SKILL_DIR}}/scripts/spec-driven.js verify <name> 验证，修复安全的格式问题并重跑；仅剩开放问题属正常，需明确呈现；若存在非问题类错误则停止并报告。
限制：仅规划，不实现代码；未明确确认前不得生成提案产物；锁定范围或写 delta 规格前必须阅读 config.yaml、INDEX.md 及相关主规格；未决歧义记入 questions.md，不得静默猜测；确认后遵循与 /spec-driven-propose 相同的产物编写与验证标准。