用途：speckit.specify 用于从自然语言功能描述生成或更新功能规格（spec）。用户输入在 /speckit.specify 之后的文本即为功能描述，命令假定其始终可用；若为空则报错“No feature description provided”。
主要能力：分析描述提取关键词，生成 2-4 个词的短名（动作-名词格式，保留 OAuth2、API、JWT 等技术词）；扫描 specs/[0-9]+-<short-name> 目录、远程与本地分支，取最高编号加一（补零为 001、025 等）；创建 GitHub 功能议题，标题形如 [001-add-frontend] 描述，正文含功能说明与 Specify、Plan、Task、Implement 清单；切换到新分支并创建 specs/<N+1>-<short-name> 目录，把 templates/spec-template.md 复制为 spec.md；按模板章节填入用户场景与测试、可测试的功能需求、可衡量的成功标准及关键实体。
使用方式：需先提供功能描述，执行流程解析描述、抽取参与者/动作/数据/约束，对不明确处最多使用 3 个 [NEEDS CLARIFICATION] 标记（优先级：范围 > 安全隐私 > 用户体验 > 技术细节）；无法确定用户流程时报错。随后生成规格并要求人工评审，询问是否需推送到 GitHub，经许可后提交并推送分支、创建带 Spec 标签的子议题（子议题关联使用 gh api graphql 的 addSubIssue 变更），创建合并到 main 的拉取请求（正文首行 fix #[spec-issue-number]），更新功能议题，列出贡献者让用户选择评审人（PR 作者不能作为评审人），最后报告分支名、spec 路径、清单结果及下一步（/speckit.clarify 或 /speckit.plan）。
适用场景：需要为功能编写面向业务干系人、聚焦“做什么与为什么”的规格说明，并把它接入 GitHub 议题与 PR 流程时。
限制：每个功能只运行一次该脚本；不创建内嵌清单（那属于单独命令）；不使用技术栈、API 或代码结构描述实现；成功标准须可衡量且与技术无关；不适用的章节应整段移除而非写 N/A；缺乏合理默认时才提问。具体模板细节、脚本实现与仓库配置在资料中暂未提供。