用途：把早期模糊想法逐步收敛为规格驱动的变更提案。技能本身只做规划，不实现代码。
主要能力与使用方式：前提是项目根目录已存在 .spec-driven/，可先运行 ls .spec-driven/ 检查，否则需先执行 /spec-driven-init。常用命令为 propose: node {{SKILL_DIR}}/scripts/spec-driven.js propose <name> 与 verify: node {{SKILL_DIR}}/scripts/spec-driven.js verify <name>，不要凭记忆猜命令。
流程：从目标、要解决的问题和已知约束开始，不要求先给名称；读取 .spec-driven/config.yaml（context 作背景、rules 作约束）与 .spec-driven/specs/INDEX.md 及相关主规格；讨论到可决策，明确结果与用户可见行为、范围内外、取舍风险、可能改动的规格文件和待人工回答的问题；随后建议 kebab-case 变更名，给出确认检查点，确认后执行 propose 生成 .spec-driven/changes/<name>/ 模板，再按 /spec-driven-propose 的标准填写五个产物。delta 规格需与主规格路径对齐，例如 .spec-driven/specs/skills/planning.md 对应 .spec-driven/changes/<name>/specs/skills/planning.md；无可见规格影响时该目录留空。tasks.md 的测试部分必须含 lint/validate/typecheck/build 与 unit test 关键词，并写出可运行命令。最后运行 verify 校验，仅剩未决问题属正常。
限制：未获明确确认前不得生成产物；不实现代码；不确定的实现或测试路径不得编造，应记入 questions.md；非问题类错误须停止并报告。适用场景为编码开发前的需求梳理与提案准备，分类归入编程与开发。