用途：在 spec-kit 工作流开始时，把自然语言的功能描述转化为一份功能规格说明（spec.md），聚焦 WHAT 与 WHY，不描述 HOW。
主要能力：接收功能描述；若输入缺失或含糊，会追问“你想规格化什么功能？描述它应做什么以及为什么”。随后推导 kebab-case 名称（如 add user authentication → user-auth），创建 specs/changes/<name>/ 目录并写入 spec.md。规格结构包含 Problem、Goals、Non-Goals、User Stories（带 P1/P2/P3 优先级）、Success Criteria、Open Questions。
使用方式：提供功能描述即可。specs/changes/ 被 gitignore，只有 specs/features/ 是规范且纳入版本控制的目录。完成后会汇总变更名称与文件位置、开放问题数量，并提示下一步：用 spec-kit-clarify 解决开放问题，或规格清晰时用 spec-kit-plan。
限制与规则：规格中不得出现技术栈、框架或实现细节；成功标准须可度量且与技术无关；[NEEDS CLARIFICATION] 标记最多 3 个，优先级为 scope > security > UX > technical；面向业务干系人而非开发者；若同名变更已存在，会询问继续还是新建；倾向做合理假设而非提不必要的问题。
适用场景：需要在编码前明确需求边界、目标与验收标准，并与后续 clarify、plan 技能衔接时使用。