项目介绍
Spec Kit 是 GitHub 官方开源的规格驱动开发工具包。它把需求定义、澄清、技术计划、任务拆分、一致性分析、实现与收敛检查做成一组项目内 Prompt 命令，并通过 Specify CLI 将模板安装到不同 AI 编码 Agent 的目录。它不是替你证明软件正确的自动化测试，也不会替宿主 Agent 收窄文件、命令或网络权限；更合适的用法是把它当作可审查的开发流程骨架，在每个质量门槛保留人工判断。
核心功能
需求规格与澄清
/speckit.specify 从自然语言描述创建或更新功能规格，/speckit.clarify 最多提出五个针对性问题并把答案回写到规格。
计划与任务拆分
/speckit.plan 把技术栈和约束转成设计产物，/speckit.tasks 根据规格与计划生成按依赖排序、按用户故事组织的任务。
一致性分析与实现
/speckit.analyze 只读检查 spec、plan 和 tasks 的冲突与遗漏；/speckit.implement 按任务阶段执行，并把清单状态作为继续前的门槛。
收敛循环
/speckit.converge 在实现后比对代码与规格产物，只在发现遗漏时向 tasks.md 追加任务，配合 implement 反复运行直至没有差距。
多 Agent 集成
Specify CLI 针对命令式和 Skill 式宿主生成对应文件，并提供 generic 集成供未列出的 Agent 指定自定义命令目录。
获取与使用
优先把 v1.0.4 安装到 uv 的独立工具环境，并在新测试目录显式选择一个已安装的 Agent 集成；确认生成文件后再应用到真实仓库。
让 AI Agent 帮你安装
把这段话发送给 Codex、Claude Code 或其他可以操作本地环境的 AI Agent。
请帮我安全安装并评估 GitHub Spec Kit v1.0.4。
项目地址：https://github.com/github/spec-kit
先阅读 README、docs/installation.md、docs/reference/core.md、docs/reference/integrations.md、SECURITY.md 与 LICENSE，确认 Python 版本、uv、目标 Agent 集成键、目标目录和版本控制状态。使用固定版本命令 uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v1.0.4，不要跟随 main。先运行 specify version，再在全新的测试目录初始化；不要对现有非空目录使用 --force。列出将创建的 .specify、specs 与 Agent 专属文件，说明 Prompt 将继承宿主 Agent 的文件、命令和网络权限。不要配置凭据、安装社区扩展、执行实现任务或覆盖现有文件；这些操作需要先停下确认。最后报告实际命令、文件变化、验证结果与未验证项。- Python 3.11 或更高版本
- uv（推荐）或 pipx
- 一个已安装且可调用的受支持 AI 编码 Agent
- 访问 GitHub 的网络能力
- 目标项目的写入权限和可回滚版本控制状态
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v1.0.4- 1固定版本并核对环境
确认 Python 3.11+、uv 和目标 Agent 已安装，选择 v1.0.4 Release，而不是直接从持续变化的 main 部署。
- 2在新目录初始化
运行 specify init my-project --integration <key>，检查 .specify、specs 和宿主专属命令或 Skill 文件；暂不在现有仓库使用 --force。
- 3先建立项目原则与规格
用 /speckit.constitution 记录不可违背的工程原则，再以 /speckit.specify 描述功能的目标、用户故事和验收边界。
- 4在规划前消除歧义
对重要功能运行 /speckit.clarify 和 /speckit.checklist，由人审查问题与清单；不要让实现 Agent 自行替代审批。
- 5生成计划与任务并分析
依次运行 /speckit.plan、/speckit.tasks 和只读的 /speckit.analyze，发现矛盾时回到拥有该问题的上游产物修改。
- 6分阶段实现并收敛
按范围调用 /speckit.implement，运行项目自身测试与审查，再用 /speckit.converge 查找遗漏；重复不等于免除最终验收。
先运行 specify version 确认 CLI 可用，再在全新目录执行 specify init my-project --integration <key>。检查 .specify/、specs/ 与 Agent 专属目录是否生成，随后只运行 /speckit.specify 创建一个低风险示例规格并人工核对文件变化；这不代表后续实现质量已经验证。
- README 也提供 PyPI、pipx 与一次性 uvx 方式；团队部署更适合固定 Release tag
- CI 或无 PTY 环境使用 --non-interactive，并显式指定 --integration 或 --ignore-agent-tools
- Git 对核心初始化是可选依赖，但 git 扩展及常规分支工作流会需要它
- 升级或切换集成前先检查本地改动；--force 可能覆盖受管理文件
使用场景
新功能需求落地
把模糊产品想法转为用户故事、澄清答案、技术计划和可执行任务，减少 Agent 直接从一句话跳到代码。
团队工程守则
用 constitution 和 preset 把测试、安全、架构或合规原则放进每个功能的计划与审查流程。
跨 Agent 工作流迁移
在多个受支持宿主间复用核心规格产物，并由 CLI 生成各宿主所需的命令或 Skill 布局。
大型功能的分阶段实现
按任务阶段限制 implement 的范围，每阶段独立验证，再通过 analyze 与 converge 查找跨产物差距。
使用评价
Spec Kit 的突出价值不是某个神奇 Prompt，而是把需求到实现拆成可见、可回退、可重复检查的产物链，并对大量 Agent 提供明确集成。公开仓库具备 MIT 许可、SECURITY、稳定 Release、测试和持续维护，安装说明也清楚标出 Python、uv、非交互与覆盖选项。风险主要来自两层：初始化和 Agent 执行都会写项目文件，而第三方 catalog 内容还能引入远程下载；此外，流程产物仍由模型生成，清单和收敛命令不能替代人工验收。本次收录核验到源码与文档层，没有宣称实际安装或执行 Prompt。
值得一试的地方
- 需求、计划、任务、分析、实现和收敛形成完整且可审查的工作流
- 30 多种宿主集成并提供 generic 适配入口
- 稳定 Release、MIT 许可证、安全披露政策、测试和近期修复均可核验
- 对非交互、覆盖、扩展来源、认证与离线行为提供了较完整文档
使用前要知道
- 本次未安装 CLI，也未在任一 Agent 中运行核心命令
- 宿主兼容性随各 Agent 版本和调用机制变化，需要在目标环境复验
- --force、集成切换和升级可能覆盖受管理文件
- 社区扩展、预设和工作流需要独立的来源与权限审查
README
Spec Kit
Overview
GitHub 官方开源的规格驱动开发工具包，通过一组可审查的 Prompt 命令把需求、澄清、计划、任务、实现与收敛检查串成完整工作流。 GitHub 官方的规格驱动开发工具包，为 30 多种 AI 编码 Agent 提供需求、计划、任务、实现与收敛 Prompt 工作流。
Getting started
- 优先把 v1.0.4 安装到 uv 的独立工具环境，并在新测试目录显式选择一个已安装的 Agent 集成；确认生成文件后再应用到真实仓库。
- 官方流程从 /speckit.constitution 建立项目原则开始，经 /speckit.specify 定义需求、/speckit.plan 生成技术设计、/speckit.tasks 拆分依赖任务，再由 /speckit.implement 执行；clarify、checklist 与 analyze 是按风险加入的质量门槛，converge 用于检查实现遗漏。
- 安装文档推荐使用 uv，并要求 Python 3.11 以上。固定版本安装可从 GitHub v1.0.4 tag 获取，初始化时用 --integration 显式选择宿主；无交互环境应加 --non-interactive，现有非空目录只有在明确接受合并或覆盖风险时才使用 --force。
- 先运行 specify version 确认 CLI 可用，再在全新目录执行 specify init my-project --integration <key>。检查 .specify/、specs/ 与 Agent 专属目录是否生成，随后只运行 /speckit.specify 创建一个低风险示例规格并人工核对文件变化；这不代表后续实现质量已经验证。
Configuration
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git@v1.0.4