🌱 Spec Kit CN

更快地构建高质量软件.

一个开源工具包, 让你专注于产品场景和可预期的结果, 而不是从零开始随意编写每一个部分.

💡 这是 GitHub Spec Kit 的非官方中文复刻版本

🔄 对应原版版本: v0.5.0

📦 包名: specify-cn-cli

🛠️ 命令: specify-cn

⚠️ 保持同步: 本项目将定期与原版保持同步, 确保中文用户能够享受最新的功能和改进.

specify-cn init --offline 国内用户推荐使用
- 直接使用包内置资源初始化, 不依赖 GitHub 下载.
- 在网络受限, 代理不稳定, 企业内网或离线环境下更稳妥.
- 还能避免模板下载超时, 证书校验失败, 防火墙拦截等常见问题.
specify-cn init --ai-skills, 可以将 command 安装为 skill，习惯 skill 的用户推荐使用
- 将内置命令直接安装为 agent skills, 适合已迁移到 skills 工作流的 agent.
- 对 Codex, Kimi, Antigravity 等 agent 尤其重要, 可以避免旧 command 布局兼容性问题.
- 初始化后可以直接使用对应 skills, 减少后续手动调整目录结构的成本.

推荐组合:

# 网络环境不稳定时, 优先使用离线初始化
specify-cn init my-project --ai claude --offline

# 对已迁移到 skills 的 agent, 建议直接启用 --ai-skills
specify-cn init my-project --ai codex --offline --ai-skills
specify-cn init my-project --ai kimi --offline --ai-skills
specify-cn init my-project --ai agy --offline --ai-skills

🤔 什么是规范驱动开发?

规范驱动开发彻底颠覆了传统软件开发的方式. 几十年来, 代码一直占据主导地位——规范只是我们在编码"真正工作"开始时构建和丢弃的脚手架. 规范驱动开发改变了这一点: 规范变得可执行, 直接生成可工作的实现, 而不仅仅是指导它们.

⚡ 快速开始

1. 安装 Specify CLI

选择你偏好的安装方式:

方式 1: 持久化安装(推荐)

一次安装, 随处使用. 固定到特定的发布标签以获得稳定性 (查看 Releases 获取最新版本):

# 安装特定的稳定版本(推荐 — 将 vX.Y.Z 替换为最新标签)
uv tool install specify-cn-cli --from git+https://github.com/linfee/spec-kit-cn.git@vX.Y.Z

# 或安装最新的 main 分支(可能包含未发布的变更)
uv tool install specify-cn-cli --from git+https://github.com/linfee/spec-kit-cn.git

然后直接使用工具:

# 创建新项目
specify-cn init <PROJECT_NAME>

# 或在现有项目中初始化
specify-cn init . --ai claude
# 或
specify-cn init --here --ai claude

# 检查已安装的工具
specify-cn check

要升级 Specify CLI, 请参阅升级指南获取详细说明. 快速升级:

uv tool install specify-cn-cli --force --from git+https://github.com/linfee/spec-kit-cn.git@vX.Y.Z

方式 2: 一次性使用

直接运行, 无需安装:

# 创建新项目(固定到稳定版本 — 将 vX.Y.Z 替换为最新标签)
uvx --from git+https://github.com/linfee/spec-kit-cn.git@vX.Y.Z specify-cn init <PROJECT_NAME>

# 或在现有项目中初始化
uvx --from git+https://github.com/linfee/spec-kit-cn.git@vX.Y.Z specify-cn init . --ai claude
# 或
uvx --from git+https://github.com/linfee/spec-kit-cn.git@vX.Y.Z specify-cn init --here --ai claude

持久化安装的优势:

工具保持安装状态并在 PATH 中可用
无需创建 shell 别名
更好的工具管理: uv tool list, uv tool upgrade, uv tool uninstall
更简洁的 shell 配置

方式 3: 企业级/离线环境安装

如果你的环境阻止访问 PyPI 或 GitHub, 请参阅企业级/离线环境安装指南, 了解如何使用 pip download 在联网机器上创建可移植的, 特定于操作系统的 wheel 包的分步说明.

2. 建立项目原则

在项目目录中启动你的 AI 助手. 大多数代理以 /speckit.* 斜杠命令的形式暴露 spec-kit; Codex CLI 在技能模式下使用 $speckit-* 代替.

使用 **/speckit.constitution** 命令创建项目的指导原则和开发指南, 这将指导所有后续开发.

/speckit.constitution 创建专注于代码质量, 测试标准, 用户体验一致性和性能要求的原则

3. 创建规范

使用 **/speckit.specify** 命令描述你想要构建的内容. 专注于做什么和为什么, 而不是技术栈.

/speckit.specify 构建一个可以帮助我将照片整理到不同相册中的应用程序. 相册按日期分组, 可以通过在主页上拖拽来重新组织. 相册不会嵌套在其他相册中. 在每个相册内, 照片以瓷砖界面预览.

4. 创建技术实施计划

使用 **/speckit.plan** 命令提供你的技术栈和架构选择.

/speckit.plan 应用程序使用 Vite 和最少数量的库. 尽可能使用纯 HTML, CSS 和 JavaScript. 图片不会上传到任何地方, 元数据存储在本地 SQLite 数据库中.

5. 分解任务

使用 **/speckit.tasks** 从你的实施计划创建可操作的任务列表.

/speckit.tasks

6. 执行实施

使用 **/speckit.implement** 执行所有任务并根据计划构建你的功能.

/speckit.implement

详细的分步说明, 请参阅我们的综合指南.

📽️ 视频概述

想要观看 Spec Kit 的实际操作? 观看我们的视频概述!

🧩 社区扩展

Note

社区扩展由各自作者独立创建和维护. GitHub 和 Spec Kit 维护者可能会审查向社区目录添加条目的拉取请求的格式, 目录结构或策略合规性, 但他们不审查, 审计, 认可或支持扩展代码本身. 社区扩展网站也是第三方资源. 请在安装前审查扩展源代码, 并自行判断使用.

🔍 在社区扩展网站上浏览和搜索社区扩展.

以下社区贡献的扩展可在 catalog.community.json 中找到:

类别:

docs — 读取, 验证或生成规范制品
code — 审查, 验证或修改源代码
process — 跨阶段编排工作流
integration — 与外部平台同步
visibility — 报告项目健康或进度

效果:

Read-only — 生成报告但不修改文件
Read+Write — 修改文件, 创建制品或更新规范

扩展	用途	类别	效果	URL
AI-Driven Engineering (AIDE)	结构化的 7 步工作流, 使用 AI 助手从零构建新项目 — 从愿景到实施	`process`	Read+Write	aide
Archive Extension	将已合并的功能归档到主项目记忆中	`docs`	Read+Write	spec-kit-archive
Azure DevOps Integration	使用 OAuth 认证将用户故事和任务同步到 Azure DevOps 工作项	`integration`	Read+Write	spec-kit-azure-devops
Checkpoint Extension	在实施过程中提交变更, 避免最终只有一个非常大的提交	`code`	Read+Write	spec-kit-checkpoint
Cleanup Extension	实施后的质量关卡, 审查变更, 修复小问题(童子军规则), 为中等问题创建任务, 为大问题生成分析	`code`	Read+Write	spec-kit-cleanup
Conduct Extension	通过子代理委派编排 spec-kit 阶段, 减少上下文污染	`process`	Read+Write	spec-kit-conduct-ext
DocGuard — CDD Enforcement	规范驱动开发(CDD)强制执行. 通过自动化检查, AI 驱动的工作流和 spec-kit 钩子验证, 评分和追踪项目文档. 零 NPM 运行时依赖	`docs`	Read+Write	spec-kit-docguard
Extensify	创建和验证扩展及扩展目录	`process`	Read+Write	extensify
Fix Findings	自动化的分析-修复-再分析循环, 解决规范发现直到清除	`code`	Read+Write	spec-kit-fix-findings
Fleet Orchestrator	通过人工审批关卡编排完整的功能生命周期, 覆盖所有 SpecKit 阶段	`process`	Read+Write	spec-kit-fleet
Iterate	使用两阶段定义和应用工作流迭代规范文档 — 在实施中途细化规范, 然后直接继续构建	`docs`	Read+Write	spec-kit-iterate
Jira Integration	从 spec-kit 规范和任务分解创建 Jira Epic, Story 和 Issue, 支持可配置的层级和自定义字段	`integration`	Read+Write	spec-kit-jira
Learning Extension	从实施中生成教育指南, 并通过导师上下文增强澄清环节	`docs`	Read+Write	spec-kit-learn
MAQA — Multi-Agent & Quality Assurance	协调者 → 功能 → QA 代理工作流, 支持基于 worktree 的并行实施. 语言无关. 自动检测已安装的看板插件. 可选 CI 关卡	`process`	Read+Write	spec-kit-maqa-ext
MAQA Azure DevOps Integration	MAQA 的 Azure DevOps Boards 集成 — 随功能进展同步用户故事和子任务	`integration`	Read+Write	spec-kit-maqa-azure-devops
MAQA CI/CD Gate	自动检测 GitHub Actions, CircleCI, GitLab CI 和 Bitbucket Pipelines. 在流水线通过前阻止 QA 交接	`process`	Read+Write	spec-kit-maqa-ci
MAQA GitHub Projects Integration	MAQA 的 GitHub Projects v2 集成 — 随功能进展同步草拟 issue 和状态列	`integration`	Read+Write	spec-kit-maqa-github-projects
MAQA Jira Integration	MAQA 的 Jira 集成 — 随功能在看板中的进展同步 Story 和 Subtask	`integration`	Read+Write	spec-kit-maqa-jira
MAQA Linear Integration	MAQA 的 Linear 集成 — 随功能进展跨工作流状态同步 issue 和子 issue	`integration`	Read+Write	spec-kit-maqa-linear
MAQA Trello Integration	MAQA 的 Trello 看板集成 — 从规范填充看板, 移动卡片, 实时勾选清单	`integration`	Read+Write	spec-kit-maqa-trello
Onboard	为 spec-kit 项目新开发者提供上下文引导和渐进式成长. 解释规范, 映射依赖, 验证理解, 指导下一步	`process`	Read+Write	spec-kit-onboard
Plan Review Gate	要求 spec.md 和 plan.md 通过 MR/PR 合并后才能生成任务	`process`	Read-only	spec-kit-plan-review-gate
Presetify	创建和验证预设及预设目录	`process`	Read+Write	presetify
Product Forge	完整产品生命周期: 研究 → 产品规范 → SpecKit → 实施 → 验证 → 测试	`process`	Read+Write	speckit-product-forge
Project Health Check	诊断 Spec Kit 项目并报告结构, 代理, 功能, 脚本, 扩展和 Git 方面的健康问题	`visibility`	Read-only	spec-kit-doctor
Project Status	显示当前 SDD 工作流进度 — 活跃功能, 制品状态, 任务完成度, 工作流阶段和扩展摘要	`visibility`	Read-only	spec-kit-status
QA Testing Extension	使用浏览器驱动或基于 CLI 的验收标准系统化 QA 测试	`code`	Read-only	spec-kit-qa
Ralph Loop	使用 AI 代理 CLI 的自主实施循环	`code`	Read+Write	spec-kit-ralph
Reconcile Extension	通过精确更新功能制品来协调实施偏差	`docs`	Read+Write	spec-kit-reconcile
Repository Index	为现有仓库生成概览, 架构和模块级别的索引	`docs`	Read-only	spec-kit-repoindex
Retro Extension	冲刺回顾分析, 包含指标, 规范准确性评估和改进建议	`process`	Read+Write	spec-kit-retro
Retrospective Extension	实施后回顾, 包含规范遵循评分, 偏差分析和人工审批的规范更新	`docs`	Read+Write	spec-kit-retrospective
Review Extension	实施后全面代码审查, 使用专门的代理检查代码质量, 注释, 测试, 错误处理, 类型设计和简化	`code`	Read-only	spec-kit-review
SDD Utilities	恢复中断的工作流, 验证项目健康状态, 验证规范到任务的追溯性	`process`	Read+Write	speckit-utils
Staff Review Extension	资深工程师级别的代码审查, 根据规范验证实施, 检查安全性, 性能和测试覆盖率	`code`	Read-only	spec-kit-staff-review
Superpowers Bridge	在 spec-kit SDD 工作流中编排 obra/superpowers 技能, 覆盖完整生命周期(澄清, TDD, 审查, 验证, 评审, 调试, 分支完成)	`process`	Read+Write	superpowers-bridge
Ship Release Extension	自动化发布流水线: 预检, 分支同步, 变更日志生成, CI 验证和 PR 创建	`process`	Read+Write	spec-kit-ship
Spec Critique Extension	从产品策略和工程风险两个角度对规范和计划进行批判性审查	`docs`	Read-only	spec-kit-critique
Spec Sync	检测并解决规范与实施之间的偏差. AI 辅助解决, 需人工审批	`docs`	Read+Write	spec-kit-sync
V-Model Extension Pack	强制 V-Model 配对生成开发规范和测试规范, 提供完整的追溯性	`docs`	Read+Write	spec-kit-v-model
Verify Extension	实施后质量关卡, 根据规范制品验证已实施的代码	`code`	Read-only	spec-kit-verify
Verify Tasks Extension	检测虚假完成: tasks.md 中标记为 [X] 但没有实际实施的任务	`code`	Read-only	spec-kit-verify-tasks

要提交你自己的扩展, 请参阅扩展发布指南.

🎨 社区预设

Note

社区预设由各自作者独立创建和维护. GitHub 和 Spec Kit 维护者可能会审查向社区目录添加条目的拉取请求的格式, 目录结构或策略合规性, 但他们不审查, 审计, 认可或支持预设代码本身. 请在安装前审查预设源代码, 并自行判断使用.

以下社区贡献的预设自定义 Spec Kit 的行为方式 — 覆盖模板, 命令和术语而不更改任何工具. 预设可在 catalog.community.json 中找到:

预设	用途	提供	依赖	URL
AIDE In-Place Migration	将 AIDE 扩展工作流适配为就地技术迁移(X → Y 模式) — 添加迁移目标, 验证关卡, 知识文档和行为等价标准	2 个模板, 8 个命令	AIDE 扩展	spec-kit-presets
Pirate Speak (Full)	将所有 Spec Kit 输出转换为海盗语言 — 规范变成"航海宣言", 计划变成"作战计划", 任务变成"船员分配"	6 个模板, 9 个命令	—	spec-kit-presets

要构建和发布你自己的预设, 请参阅预设发布指南.

🚶 社区演练

Note

社区演练由各自作者独立创建和维护. 它们未经 GitHub 审查, 认可或支持. 请在跟随演练前审查其内容, 并自行判断使用.

通过这些社区贡献的演练, 在不同场景中观看规范驱动开发的实际操作:

全新 .NET CLI 工具 — 从空白目录构建时区工具作为 .NET 单一二进制 CLI 工具, 涵盖完整的 spec-kit 工作流: constitution, specify, plan, tasks, 以及使用 GitHub Copilot 代理的多轮实现。
全新 Spring Boot + React 平台 — 使用 Spring Boot, 嵌入式 React, PostgreSQL 和 Docker Compose 从零构建 LLM 性能分析平台(REST API, 图表, 迭代跟踪), 包含 clarify 步骤和跨制品一致性分析。
存量 ASP.NET CMS 扩展 — 扩展现有的开源 .NET CMS(CarrotCakeCMS-Core, 约 307,000 行 C#, Razor, SQL, JavaScript 和配置文件), 添加两个新功能 — 跨平台 Docker Compose 基础设施和令牌认证的无头 REST API — 展示 spec-kit 如何在没有预先规范或章程的情况下融入现有代码库。
存量 Java 运行时扩展 — 扩展现有的开源 Jakarta EE 运行时(Piranha, 约 420,000 行 Java, XML, JSP, HTML 和配置文件, 跨 180 个 Maven 模块), 添加密码保护的服务器管理控制台, 展示在没有预先规范或章程的大型多模块 Java 项目上使用 spec-kit。
存量 Go / React 仪表板演示 — 展示完全从终端使用 GitHub Copilot CLI 驱动 spec-kit。扩展 NASA 的开源 Hermes 地面支持系统(Go), 添加轻量级的基于 React 的 Web 遥测仪表板, 展示完整的 constitution → specify → plan → tasks → implement 工作流可以从终端运行。
使用自定义预设的全新 Spring Boot MVC — 使用自定义海盗语言预设从零构建 Spring Boot MVC 应用程序, 展示预设如何重塑整个 spec-kit 体验: 规范变成"航海宣言", 计划变成"作战计划", 任务变成"船员分配" — 全部以完整的海盗方言生成, 而无需更改任何工具。
使用自定义扩展的全新 Spring Boot + React — 演练 AIDE 扩展, 这是一个社区扩展, 为 spec-kit 添加了另一种规范驱动工作流, 使用高层规范(愿景)和低层规范(工作项)组织为 7 步迭代生命周期: 愿景 → 路线图 → 进度跟踪 → 工作队列 → 工作项 → 执行 → 反馈循环. 使用家庭交易平台(Spring Boot 4, React 19, PostgreSQL, Docker Compose)作为场景, 展示扩展机制如何让你插入不同风格的规范驱动开发而无需更改任何核心工具 — 真正利用 Spec Kit 中的"Kit".

🛠️ 社区项目

Note

此处列出的社区项目由各自作者独立创建和维护. 它们未经 GitHub 审查, 认可或支持. 请在安装前审查其源代码, 并自行判断使用.

扩展, 可视化或基于 Spec Kit 构建的社区项目:

cc-spex — Claude Code 插件, 在 Spec Kit 之上添加可组合的特性, 包括基于 Superpowers 的质量关卡, 规范/代码审查, git worktree 隔离和通过代理团队进行并行实施.
Spec Kit Assistant — VS Code 扩展, 提供完整 SDD 工作流(constitution → specification → planning → tasks → implementation)的可视化编排器, 包含阶段状态可视化, 交互式任务清单, DAG 可视化, 以及对 Claude, Gemini, GitHub Copilot 和 OpenAI 后端的支持. 需要在 PATH 中安装 specify CLI.

🤖 支持的 AI 代理

代理	支持	说明
Qoder CLI	✅
Kiro CLI	✅	使用 `--ai kiro-cli` (别名: `--ai kiro`)
Amp	✅
Auggie CLI	✅
Claude Code	✅	将技能安装到 `.claude/skills`; 以 `/speckit-constitution`, `/speckit-plan` 等方式调用
CodeBuddy CLI	✅
Codex CLI	✅	需要 `--ai-skills`. Codex 推荐 skills 并将 custom prompts 视为已弃用. Spec-kit 将 Codex 技能安装到 `.agents/skills` 并以 `$speckit-<command>` 方式调用
Cursor	✅
Gemini CLI	✅
GitHub Copilot	✅
IBM Bob	✅	基于 IDE 的代理, 支持斜杠命令
Jules	✅
Kilo Code	✅
opencode	✅
Pi Coding Agent	✅	Pi 开箱不支持 MCP, 因此 `taskstoissues` 无法按预期工作. 可通过 extensions 添加 MCP 支持
Qwen Code	✅
Roo Code	✅
SHAI (OVHcloud)	✅
Tabnine CLI	✅
Mistral Vibe	✅
Kimi Code	✅
iFlow CLI	✅
Windsurf	✅
Junie	✅
Antigravity (agy)	✅	需要 `--ai-skills`
Trae	✅
Generic	✅	自带代理 — 使用 `--ai generic --ai-commands-dir <path>` 支持未列出的代理

🔧 Specify CLI 参考

specify-cn 命令支持以下选项:

命令

命令	描述
`init`	从最新模板初始化新的 Specify 项目
`check`	检查已安装的工具: `git` 以及 `AGENT_CONFIG` 中配置的所有基于 CLI 的代理 (例如: `claude`, `gemini`, `code`/`code-insiders`, `cursor-agent`, `windsurf`, `junie`, `qwen`, `opencode`, `codex`, `kiro-cli`, `shai`, `qodercli`, `vibe`, `kimi`, `iflow`, `pi` 等)

`specify-cn init` 参数和选项

参数/选项	类型	描述
`<project-name>`	参数	新项目目录的名称(使用 `--here` 时可选, 或使用 `.` 表示当前目录)
`--ai`	选项	要使用的 AI 助手 (完整列表参见 `AGENT_CONFIG`): `claude`, `gemini`, `copilot`, `cursor-agent`, `qwen`, `opencode`, `codex`, `windsurf`, `junie`, `kilocode`, `auggie`, `roo`, `codebuddy`, `amp`, `shai`, `kiro-cli` (`kiro` 别名), `agy`, `bob`, `qodercli`, `vibe`, `kimi`, `iflow`, `pi`, 或 `generic` (需要 `--ai-commands-dir`)
`--ai-commands-dir`	选项	代理命令文件的目录 (与 `--ai generic` 一起使用, 例如 `.myagent/commands/`)
`--script`	选项	要使用的脚本变体: `sh` (bash/zsh) 或 `ps` (PowerShell)
`--ignore-agent-tools`	标志	跳过 AI 代理工具的检查, 如 Claude Code
`--no-git`	标志	跳过 git 仓库初始化
`--here`	标志	在当前目录初始化项目, 而不是创建新目录
`--force`	标志	在当前目录中初始化时强制合并/覆盖(跳过确认)
`--skip-tls`	标志	跳过 SSL/TLS 验证(不推荐)
`--debug`	标志	启用详细调试输出以进行故障排除
`--github-token`	选项	API 请求的 GitHub 令牌(或设置 GH_TOKEN/GITHUB_TOKEN 环境变量)
`--ai-skills`	标志	将 Prompt.MD 模板作为代理技能安装到代理特定的 `skills/` 目录中 (需要 `--ai`). 稍后添加扩展时, 扩展命令也会自动注册为技能
`--branch-numbering`	选项	分支编号策略: `sequential` (默认 — `001`, `002`, `003`) 或 `timestamp` (`YYYYMMDD-HHMMSS`). 时间戳模式适用于分布式团队以避免编号冲突

示例

# 基本项目初始化
specify-cn init my-project

# 使用特定 AI 助手初始化
specify-cn init my-project --ai claude

# 使用 Cursor 支持初始化
specify-cn init my-project --ai cursor-agent

# 使用 Qoder 支持初始化
specify-cn init my-project --ai qodercli

# 使用 Kiro CLI 支持初始化
specify-cn init my-project --ai kiro-cli

# 使用 Windsurf 支持初始化
specify-cn init my-project --ai windsurf

# 使用 Amp 支持初始化
specify-cn init my-project --ai amp

# 使用 SHAI 支持初始化
specify-cn init my-project --ai shai

# 使用 Mistral Vibe 支持初始化
specify-cn init my-project --ai vibe

# 使用 IBM Bob 支持初始化
specify-cn init my-project --ai bob

# 使用 Pi Coding Agent 支持初始化
specify-cn init my-project --ai pi

# 使用 Codex CLI 支持初始化
specify-cn init my-project --ai codex --ai-skills

# 使用 Antigravity 支持初始化
specify-cn init my-project --ai agy --ai-skills

# 使用不支持的代理初始化(通用/自带代理)
specify-cn init my-project --ai generic --ai-commands-dir .myagent/commands/

# 使用 PowerShell 脚本初始化(Windows/跨平台)
specify-cn init my-project --ai copilot --script ps

# 在当前目录初始化
specify-cn init . --ai copilot
# 或使用 --here 标志
specify-cn init --here --ai copilot

# 强制合并到当前(非空)目录而无需确认
specify-cn init . --force --ai copilot
# 或
specify-cn init --here --force --ai copilot

# 跳过 git 初始化
specify-cn init my-project --ai gemini --no-git

# 启用调试输出以进行故障排除
specify-cn init my-project --ai claude --debug

# 使用 GitHub 令牌进行 API 请求(对企业环境有帮助)
specify-cn init my-project --ai claude --github-token ghp_your_token_here

# 安装代理技能到项目中
specify-cn init my-project --ai claude --ai-skills

# 在当前目录初始化并安装代理技能
specify-cn init --here --ai gemini --ai-skills

# 使用基于时间戳的分支编号(适用于分布式团队)
specify-cn init my-project --ai claude --branch-numbering timestamp

# 检查系统要求
specify-cn check

可用的斜杠命令

运行 specify-cn init 后, 你的 AI 编码代理将可以使用这些结构化开发命令.

大多数代理以传统的点分隔斜杠命令形式暴露以下命令, 如 /speckit.plan.

Claude Code 将 spec-kit 安装为技能, 并以 /speckit-constitution, /speckit-specify, /speckit-plan, /speckit-tasks 和 /speckit-implement 的方式调用.

对于 Codex CLI, --ai-skills 将 spec-kit 安装为代理技能而非斜杠命令提示文件. 在 Codex 技能模式下, 以 $speckit-constitution, $speckit-specify, $speckit-plan, $speckit-tasks 和 $speckit-implement 的方式调用.

核心命令

规范驱动开发工作流的基本命令:

命令	描述
`/speckit.constitution`	创建或更新项目指导原则和开发指南
`/speckit.specify`	定义你想要构建的内容(需求和用户故事)
`/speckit.plan`	使用你选择的技术栈创建技术实施计划
`/speckit.tasks`	为实施生成可操作的任务列表
`/speckit.implement`	执行所有任务以根据计划构建功能

可选命令

用于增强质量和验证的附加命令:

命令	描述
`/speckit.clarify`	澄清未充分说明的区域(建议在 `/speckit.plan` 之前运行; 以前为 `/quizme`)
`/speckit.analyze`	跨制品一致性和覆盖范围分析(在 /speckit.tasks 之后, /speckit.implement 之前运行)
`/speckit.checklist`	生成自定义质量检查清单, 验证需求的完整性, 清晰性和一致性(类似"英文的单元测试")

环境变量

变量	描述
`SPECIFY_FEATURE`	为非 Git 仓库覆盖功能检测. 设置为功能目录名称(例如, `001-photo-albums`)以在不使用 Git 分支的情况下处理特定功能. 必须在你正在使用的代理上下文中设置, 然后才能使用 `/speckit.plan` 或后续命令.

🧩 打造专属 Spec Kit: 扩展与预设

Spec Kit 可以通过两个互补的系统来满足你的需求 — 扩展和预设 — 以及项目本地覆盖用于一次性调整:

block-beta
    columns 1
    overrides["⬆ 最高优先级\n项目本地覆盖\n.specify/templates/overrides/"]
    presets["预设 — 定制核心和扩展\n.specify/presets/<preset-id>/templates/"]
    extensions["扩展 — 添加新功能\n.specify/extensions/<ext-id>/templates/"]
    core["Spec Kit 核心 — 内置 SDD 命令和模板\n.specify/templates/\n⬇ 最低优先级"]

    style overrides fill:transparent,stroke:#999
    style presets fill:transparent,stroke:#4a9eda
    style extensions fill:transparent,stroke:#4a9e4a
    style core fill:transparent,stroke:#e6a817

模板在运行时解析 — Spec Kit 从上到下遍历堆栈并使用第一个匹配项。项目本地覆盖(.specify/templates/overrides/)让你可以为单个项目进行一次性调整, 而无需创建完整的预设。命令在安装时应用 — 当你运行 specify extension add 或 specify preset add 时, 命令文件会被写入代理目录(例如 .claude/commands/)。如果多个预设或扩展提供相同的命令, 则最高优先级的版本获胜。删除时, 下一个最高优先级的版本会自动恢复。如果没有覆盖或自定义, Spec Kit 使用其核心默认值。

扩展 — 添加新功能

当你需要超出 Spec Kit 核心功能时使用扩展。扩展引入新的命令和模板 — 例如, 添加内置 SDD 命令未涵盖的领域特定工作流, 与外部工具集成, 或添加全新的开发阶段。它们扩展Spec Kit 能做什么。

# 搜索可用扩展
specify-cn extension search

# 安装扩展
specify-cn extension add <extension-name>

例如, 扩展可以添加 Jira 集成, 实施后代码审查, V-Model 测试可追溯性, 或项目健康诊断。

请参阅扩展 README 获取完整指南, 完整的社区目录, 以及如何构建和发布你自己的扩展。

预设 — 定制现有工作流

当你想要更改Spec Kit 如何工作而不添加新功能时使用预设。预设覆盖核心和已安装扩展附带的模板和命令 — 例如, 强制执行符合合规要求的规范格式, 使用领域特定术语, 或将组织标准应用于计划和任务。它们定制 Spec Kit 及其扩展产生的制品和指令。

# 搜索可用预设
specify-cn preset search

# 安装预设
specify-cn preset add <preset-name>

例如, 预设可以重构规范模板以要求法规可追溯性, 调整工作流以适应你使用的方法(例如, 敏捷, 看板, 瀑布, 待完成工作, 或领域驱动设计), 向计划添加强制性安全审查关卡, 强制测试优先的任务排序, 或将整个工作流本地化为不同的语言。海盗语言演示展示了定制可以有多深入。多个预设可以按优先级顺序堆叠。

请参阅预设 README 获取完整指南, 包括解析顺序, 优先级, 以及如何创建你自己的预设。

何时使用哪个

目标	使用
添加全新的命令或工作流	扩展
定制规范, 计划或任务的格式	预设
与外部工具或服务集成	扩展
强制执行组织或法规标准	预设
发布可重用的领域特定模板	两者皆可 — 预设用于模板覆盖, 扩展用于与新命令捆绑的模板

📚 核心理念

规范驱动开发是一个强调以下方面的结构化过程:

意图驱动开发, 规范在"如何"之前定义"什么"
丰富的规范创建, 使用护栏和组织原则
多步细化, 而不是从提示一次性生成代码
高度依赖高级 AI 模型能力进行规范解释

🌟 开发阶段

阶段	重点	关键活动
0到1开发("新建项目")	从头生成	- 从高层需求开始 - 生成规范 - 规划实施步骤 - 构建生产就绪的应用程序
创意探索	并行实现	- 探索多样化的解决方案 - 支持多种技术栈和架构 - 实验 UX 模式
迭代增强("现有项目改造")	现有项目现代化	- 迭代添加功能 - 现代化遗留系统 - 适应流程

🎯 实验目标

我们的研究和实验专注于:

技术独立性

使用多样化的技术栈创建应用程序
验证规范驱动开发是一个不依赖于特定技术, 编程语言或框架的过程

企业约束

展示关键任务应用程序开发
融入组织约束(云提供商, 技术栈, 工程实践)
支持企业设计系统和合规要求

以用户为中心的开发

为不同用户群体和偏好构建应用程序
支持各种开发方法(从氛围编码到 AI 原生开发)

创意和迭代过程

验证并行实现探索的概念
提供强大的迭代功能开发工作流
扩展流程以处理升级和现代化任务

🔧 前置要求

Linux/macOS/Windows
支持的 AI 编码代理.
uv 用于包管理
Python 3.11+
Git

如果你在使用代理时遇到问题, 请打开 issue 以便我们完善集成.

📖 了解更多

完整的规范驱动开发方法论 - 深入了解完整流程
详细演练 - 分步实施指南

📋 详细流程

点击展开详细的分步演练

你可以使用 Specify CLI 来引导你的项目, 这将在你的环境中引入所需的制品. 运行:

specify-cn init <project_name>

或在当前目录初始化:

specify-cn init .
# 或使用 --here 标志
specify-cn init --here
# 跳过确认当目录已有文件时
specify-cn init . --force
# 或
specify-cn init --here --force

Specify CLI 在终端中引导新项目

系统会提示你选择正在使用的 AI 代理. 你也可以直接在终端中主动指定:

specify-cn init <project_name> --ai claude
specify-cn init <project_name> --ai gemini
specify-cn init <project_name> --ai copilot

# 或在当前目录:
specify-cn init . --ai claude
specify-cn init . --ai codex --ai-skills

# 或使用 --here 标志
specify-cn init --here --ai claude
specify-cn init --here --ai codex --ai-skills

# 强制合并到非空的当前目录
specify-cn init . --force --ai claude

# 或
specify-cn init --here --force --ai claude

CLI 会检查你是否安装了 Claude Code, Gemini CLI, Cursor CLI, Qwen CLI, opencode, Codex CLI, Qoder CLI, Tabnine CLI, Kiro CLI, Pi 或 Mistral Vibe. 如果你没有安装, 或者你希望在不检查正确工具的情况下获取模板, 请在命令中使用 --ignore-agent-tools:

specify-cn init <project_name> --ai claude --ignore-agent-tools

步骤 1: 建立项目原则

转到项目文件夹并运行你的 AI 代理. 在我们的示例中, 我们使用 claude.

引导 Claude Code 环境

如果你看到 /speckit.constitution, /speckit.specify, /speckit.plan, /speckit.tasks 和 /speckit.implement 命令可用, 就说明配置正确.

第一步应该是使用 /speckit.constitution 命令建立项目的指导原则. 这有助于确保在所有后续开发阶段中做出一致的决策:

/speckit.constitution 创建专注于代码质量, 测试标准, 用户体验一致性和性能要求的原则. 包括这些原则应如何指导技术决策和实施选择的治理.

此步骤会创建或更新 .specify/memory/constitution.md 文件, 其中包含项目的基础指南, AI 代理将在规范, 规划和实施阶段参考这些指南.

步骤 2: 创建项目规范

有了项目原则后, 你现在可以创建功能规范. 使用 /speckit.specify 命令, 然后为你想要开发的项目提供具体需求.

[!IMPORTANT] 尽可能明确地说明你要构建的什么和为什么. 此时不要关注技术栈.

示例提示:

开发 Taskify, 一个团队生产力平台. 它应该允许用户创建项目, 添加团队成员,
分配任务, 评论并以看板风格在板之间移动任务. 在此功能的初始阶段,
我们称之为"创建 Taskify", 我们将有多个用户, 但用户将提前预定义.
我想要两个不同类别的五个用户, 一个产品经理和四个工程师. 让我们创建三个
不同的示例项目. 让我们为每个任务的状态使用标准的看板列, 如"待办",
"进行中", "审核中"和"已完成". 此应用程序将没有登录, 因为这只是
确保我们基本功能设置的第一次测试. 对于 UI 中的任务卡片,
你应该能够在看板工作板的不同列之间更改任务的当前状态.
你应该能够为特定卡片留下无限数量的评论. 你应该能够从该任务
卡片中分配一个有效用户. 当你首次启动 Taskify 时, 它会给你一个五个用户的列表供你选择.
不需要密码. 当你点击用户时, 你进入主视图, 显示项目列表.
当你点击项目时, 你会打开该项目的看板. 你将看到列.
你将能够在不同列之间来回拖放卡片. 你将看到分配给你的任何卡片,
即当前登录用户, 与其他卡片颜色不同, 以便你快速看到你的卡片.
你可以编辑你所做的任何评论, 但不能编辑其他人所做的评论. 你可以
删除你所做的任何评论, 但不能删除其他人所做的评论.

输入此提示后, 你应该看到 Claude Code 启动规划和规范起草过程. Claude Code 还将触发一些内置脚本来设置仓库.

完成此步骤后, 你应该有一个新创建的分支(例如, 001-create-taskify), 以及 specs/001-create-taskify 目录中的新规范.

生成的规范应包含一组用户故事和功能需求, 如模板中所定义.

在此阶段, 你的项目文件夹内容应类似于以下内容:

└── .specify
    ├── memory
    │	 └── constitution.md
    ├── scripts
    │	 ├── check-prerequisites.sh
    │	 ├── common.sh
    │	 ├── create-new-feature.sh
    │	 ├── setup-plan.sh
    │	 └── update-claude-md.sh
    ├── specs
    │	 └── 001-create-taskify
    │	     └── spec.md
    └── templates
        ├── plan-template.md
        ├── spec-template.md
        └── tasks-template.md

步骤 3: 功能规范澄清(计划前必需)

创建了基线规范后, 你可以继续澄清在第一次尝试中未正确捕获的任何需求.

你应该在创建技术计划之前运行结构化澄清工作流程, 以减少下游的返工.

首选顺序:

使用 /speckit.clarify(结构化)- 顺序的, 基于覆盖率的提问, 将答案记录在澄清部分.
如果仍然感觉模糊, 可以选择性地进行临时自由形式细化.

如果你有意跳过细节澄清环节(例如, 进行概念验证或探索性原型设计), 请明确说明, 这样智能体就不会因缺少澄清信息而停滞不前.

一个自由形式的优化提示示例(在 /speckit.clarify 之后如果仍然需要):

对于你创建的每个示例项目或项目, 每个项目应该有5到15个之间的可变数量任务, 
随机分布到不同的完成状态. 确保每个完成阶段至少有一个任务.

你还应该要求Claude Code验证审核和验收清单, 勾选验证/通过要求的项目, 未通过的项目保持未勾选状态. 可以使用以下提示:

阅读审核和验收清单, 如果功能规范符合标准, 请勾选清单中的每个项目. 如果不符合, 请留空.

重要的是, 要将与Claude Code的互动作为澄清和围绕规范提问的机会——不要将其第一次尝试视为最终版本.

步骤 4: 生成计划

你现在可以具体说明技术栈和其他技术要求. 你可以使用项目模板中内置的 /speckit.plan 命令, 使用这样的提示:

我们将使用.NET Aspire生成这个, 使用Postgres作为数据库. 前端应该使用
Blazor服务器与拖拽任务板, 实时更新. 应该创建一个REST API, 包含项目API,
任务API和通知API.

此步骤的输出将包括许多实施细节文档, 你的目录树类似于:

.
├── CLAUDE.md
├── memory
│	 └── constitution.md
├── scripts
│	 ├── check-prerequisites.sh
│	 ├── common.sh
│	 ├── create-new-feature.sh
│	 ├── setup-plan.sh
│	 └── update-claude-md.sh
├── specs
│	 └── 001-create-taskify
│	     ├── contracts
│	     │	 ├── api-spec.json
│	     │	 └── signalr-spec.md
│	     ├── data-model.md
│	     ├── plan.md
│	     ├── quickstart.md
│	     ├── research.md
│	     └── spec.md
└── templates
    ├── CLAUDE-template.md
    ├── plan-template.md
    ├── spec-template.md
    └── tasks-template.md

检查 research.md 文档, 确保根据你的说明使用了正确的技术栈. 如果任何组件突出显示, 你可以要求Claude Code完善它, 甚至让它检查你想要使用的平台/框架的本地安装版本(例如, .NET).

此外, 如果你选择的技术栈是快速变化的(例如, .NET Aspire, JS框架), 你可能想要要求Claude Code研究有关所选技术栈的详细信息, 使用这样的提示:

我希望你查看实施计划和实施细节, 寻找可能从额外研究中受益的领域, 
因为.NET Aspire是一个快速变化的库. 对于你识别的需要进一步研究的那些领域, 
我希望你使用有关我们将在Taskify应用程序中使用的特定版本的额外详细信息更新研究文档, 
并启动并行研究任务, 使用网络研究澄清任何细节.

在此过程中, 你可能会发现Claude Code卡在研究错误的内容——你可以使用这样的提示帮助它朝着正确的方向推进:

我认为我们需要将其分解为一系列步骤. 首先, 识别你在实施期间需要做的不确定
或从进一步研究中受益的任务列表. 写下这些任务的列表. 然后对于这些任务中的每一个, 
我希望你启动一个单独的研究任务, 这样最终结果是我们并行研究所有这些非常具体的任务.
我看到你所做的是看起来你在研究.NET Aspire一般情况, 我认为这对我们不会有太大帮助.
那太没有针对性的研究了. 研究需要帮助你解决特定的针对性问题.

[!NOTE] Claude Code可能过于急切, 添加你没有要求的组件. 要求它澄清变更的理由和来源.

步骤 5: 让 Claude Code 验证计划

有了计划后, 你应该让Claude Code检查它, 确保没有遗漏的部分. 你可以使用这样的提示:

现在我希望你去审核实施计划和实施细节文件.
带着确定是否存在从阅读中可以明显看出的你需要做的一系列任务的眼光来阅读.
因为我不确定这里是否足够. 例如, 当我查看核心实施时, 参考实施细节中的适当位置
会很有用, 以便在它执行核心实施或细化中的每个步骤时可以找到信息.

这有助于完善实施计划, 并帮助你避免Claude Code在其规划周期中遗漏的潜在盲点. 一旦初始细化完成, 在你可以进入实施之前, 要求Claude Code再次检查清单.

你也可以要求Claude Code(如果你安装了GitHub CLI)继续从你当前的分支向 main 创建一个详细描述的pull request, 以确保工作得到正确跟踪.

[!NOTE] 在让代理实施之前, 还值得提示Claude Code交叉检查细节, 看看是否有任何过度设计的部分(记住——它可能过于急切). 如果存在过度设计的组件或决策, 你可以要求Claude Code解决它们. 确保Claude Code遵循项目章程作为建立计划时必须遵守的基础.

步骤 6: 使用 /speckit.tasks 生成任务分解

实施计划验证通过后, 你现在可以将计划分解为具体的, 可执行的任务, 这些任务可以按正确的顺序执行. 使用 /speckit.tasks 命令从你的实施计划自动生成详细的任务分解:

/speckit.tasks

此步骤会在你的功能规范目录中创建一个 tasks.md 文件, 其中包含:

按用户故事组织的任务分解 - 每个用户故事成为一个独立的实施阶段, 包含自己的任务集
依赖管理 - 任务按依赖关系排序, 尊重组件间的依赖(例如, 模型在服务之前, 服务在端点之前)
并行执行标记 - 可以并行运行的任务用 [P] 标记, 以优化开发工作流
文件路径规范 - 每个任务包含实施应发生的确切文件路径
测试驱动开发结构 - 如果要求测试, 则包含测试任务并排序为在实施之前编写
检查点验证 - 每个用户故事阶段包含检查点以验证独立功能

生成的 tasks.md 为 /speckit.implement 命令提供了清晰的路线图, 确保系统性实施, 保持代码质量并允许用户故事的增量交付.

步骤 7: 实施

准备就绪后, 使用 /speckit.implement 命令执行你的实施计划:

/speckit.implement

/speckit.implement 命令将:

验证所有先决条件都已就绪(章程, 规范, 计划和任务)
解析 tasks.md 中的任务分解
按正确顺序执行任务, 尊重依赖关系和并行执行标记
遵循任务计划中定义的 TDD 方法
提供进度更新并适当处理错误

[!IMPORTANT] AI代理将执行本地CLI命令(如 dotnet, npm 等)- 确保你在机器上安装了所需的工具.

实施完成后, 测试应用程序并解决任何在CLI日志中可能不可见的运行时错误(例如, 浏览器控制台错误). 你可以将此类错误复制粘贴回AI代理以进行解决.

🔍 故障排除

Linux上的Git凭据管理器

如果你在Linux上遇到Git身份验证问题, 可以安装Git凭据管理器:

#!/usr/bin/env bash
set -e
echo "正在下载Git凭据管理器v2.6.1..."
wget https://github.com/git-ecosystem/git-credential-manager/releases/download/v2.6.1/gcm-linux_amd64.2.6.1.deb
echo "正在安装Git凭据管理器..."
sudo dpkg -i gcm-linux_amd64.2.6.1.deb
echo "正在配置Git使用GCM..."
git config --global credential.helper manager
echo "正在清理..."
rm gcm-linux_amd64.2.6.1.deb

💬 支持

如需支持, 请打开GitHub issue. 我们欢迎错误报告, 功能请求和关于使用规范驱动开发的问题.

🙏 致谢

这个项目深受John Lam的工作和研究的影响并基于其成果.

📄 许可证

本项目根据MIT开源许可证的条款授权. 请参阅LICENSE文件了解完整条款.

Name		Name	Last commit message	Last commit date
.claude		.claude
.devcontainer		.devcontainer
.github		.github
.superset		.superset
docs		docs
extensions		extensions
media		media
presets		presets
scripts		scripts
src/specify_cli		src/specify_cli
templates		templates
tests		tests
.gitignore		.gitignore
.markdownlint-cli2.jsonc		.markdownlint-cli2.jsonc
AGENTS.md		AGENTS.md
CHANGELOG.md		CHANGELOG.md
CLAUDE.md		CLAUDE.md
CODE_OF_CONDUCT.md		CODE_OF_CONDUCT.md
CONTRIBUTING.md		CONTRIBUTING.md
DEVELOPMENT.md		DEVELOPMENT.md
LICENSE		LICENSE
README.md		README.md
SECURITY.md		SECURITY.md
SUPPORT.md		SUPPORT.md
TERMINOLOGY.md		TERMINOLOGY.md
TESTING.md		TESTING.md
TRANSLATION_STANDARDS.md		TRANSLATION_STANDARDS.md
pyproject.toml		pyproject.toml
spec-driven.md		spec-driven.md

项目	Spec Kit 原版	Spec Kit CN 中文版
命令	`specify`	`specify-cn`
包名	`specify-cli`	`specify-cn-cli`
文档	英文	中文

Latest commit

History

Folders and files

Repository files navigation

🌱 Spec Kit CN

更快地构建高质量软件.

目录

🎯 差异说明

Tips

🤔 什么是规范驱动开发?

⚡ 快速开始

1. 安装 Specify CLI

方式 1: 持久化安装(推荐)

方式 2: 一次性使用

方式 3: 企业级/离线环境安装

2. 建立项目原则

3. 创建规范

4. 创建技术实施计划

5. 分解任务

6. 执行实施

📽️ 视频概述

🧩 社区扩展

🎨 社区预设

🚶 社区演练

🛠️ 社区项目

🤖 支持的 AI 代理

🔧 Specify CLI 参考

命令

specify-cn init 参数和选项

示例

可用的斜杠命令

核心命令

可选命令

环境变量

🧩 打造专属 Spec Kit: 扩展与预设

扩展 — 添加新功能

预设 — 定制现有工作流

何时使用哪个

📚 核心理念

🌟 开发阶段

🎯 实验目标

技术独立性

企业约束

以用户为中心的开发

创意和迭代过程

🔧 前置要求

📖 了解更多

📋 详细流程

步骤 1: 建立项目原则

步骤 2: 创建项目规范

步骤 3: 功能规范澄清(计划前必需)

步骤 4: 生成计划

步骤 5: 让 Claude Code 验证计划

步骤 6: 使用 /speckit.tasks 生成任务分解

步骤 7: 实施

🔍 故障排除

Linux上的Git凭据管理器

💬 支持

🙏 致谢

📄 许可证

About

Resources

Code of conduct

Contributing

Security policy

Stars

Watchers

Forks

Releases

Packages

Contributors

Languages

`specify-cn init` 参数和选项