Spec Kit 2026 年 2 月版本复盘：v0.1.7–v0.1.13 演进、双目录扩展体系与 v0.2.0 的诞生

Spec Kit 2026 年 2 月版本复盘：v0.1.7–v0.1.13 演进、双目录扩展体系与 v0.2.0 的诞生

【免费下载链接】spec-kit💫 Toolkit to help you get started with Spec-Driven Development项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kit

本篇以 Spec Kit 官方 2026 年 2 月通讯（newsletters/2026-February.md）为主线，完整复盘该月 v0.1.7 至 v0.1.13 的版本演进、双目录（core/community）扩展体系的落地、Kiro CLI 与 Tabnine CLI 等新智能体集成的接入过程，以及 v0.2.0 版本的发布与后续路线图。读完本文，你可以掌握 Spec Kit 扩展目录的双轨结构、扩展清单（catalog）的字段规范、智能体集成的注册机制，并能从 CHANGELOG.md 与源码中复核每一项月度进展。

一、本月概览：版本、社区与路线图

2026 年 2 月，Spec Kit 发布了v0.1.7 至 v0.1.13共 7 个版本，主线是修复缺陷并引入**双目录扩展体系（dual-catalog extension system）**与新增智能体集成。社区侧则有博客、教程与用户组分享持续输出。按通讯原文的分类摘要如下：

Spec Kit 核心（2026-02）	社区与内容	路线图与下一步
v0.1.7 至 v0.1.13 发布，含缺陷修复与新特性，包括双目录扩展体系与新智能体集成。当月关闭 issue 超过 300 个（累计提交约 800 个），仓库达到约 71k stars、6.4k forks	Eduardo Luz 在 LinkedIn 发文解读 SDD 与 Spec Kit；Erick Matsen 发布用 Spec Kit 构建生物信息学流水线的实操文章；Microsoft MVP Eric Boyd 在克利夫兰 .NET 用户组做 SDD 分享	v0.2.0于 3 月初发布，整合了 2 月全部工作：新增 Jira、Azure DevOps 扩展，支持社区插件与 Tabnine CLI、Kiro CLI 智能体。后续方向包括规格生命周期管理与向 1.0 稳定版推进

二、版本演进：v0.1.7 → v0.1.13 逐项解读

通讯给出的月度叙述是：“v0.1.7（2 月初）更新文档以说明新引入的双目录扩展体系，允许核心与社区扩展目录并存；随后的补丁版本（0.1.8、0.1.9 等）升级了 GitHub Actions 等依赖并修复小问题；v0.1.10修复了生成文件中 YAML front-matter 的处理；2 月下旬v0.1.12与v0.1.13带着更多修复发布，为下一个版本号做准备。”

对照 CHANGELOG.md 中 1781–1857 行的记录，可以精确还原每个版本做了什么：

2.1 v0.1.7（2026-02-27 标注发布）——双目录体系的文档化起点

• chore: Update outdated GitHub Actions versions (#1706)：升级过期的 GitHub Actions 版本，即通讯所说“升级依赖”的实例；
• docs: Document dual-catalog system for extensions (#1689)：双目录扩展体系的文档正式入库，这是本月的架构级事件；
• Fix version command in documentation (#1685)：修正文档中版本命令的写法；
• Add Cleanup Extension to README (#1678)、Add retrospective extension to community catalog (#1681)：社区扩展目录开始收录回顾（retrospective）类扩展——通讯中提到的“retrospective documentation 实用扩展”即指此类。

2.2 v0.1.8 / v0.1.9（2026-02-28）——依赖维护

• v0.1.8：chore(deps): bump actions/setup-python from 5 to 6 (#1710)；
• v0.1.9：chore(deps): bump astral-sh/setup-uv from 6 to 7 (#1709)。

两个版本均为 CI 依赖升级，印证通讯中“subsequent patches bumped dependencies such as GitHub Actions versions”的表述。

2.3 v0.1.10（2026-02-27 标注）——YAML front-matter 修复

• fix: prepend YAML frontmatter to Cursor .mdc files (#1699)：这就是通讯中“v0.1.10 fixed YAML front-matter handling in generated files”的具体所指——为 Cursor 生成的.mdc规则文件补上 YAML front-matter 头部，使其符合 Cursor 规则文件的格式约定。

2.4 v0.1.11 / v0.1.12（2026-03-02）——发布流水线修复

• v0.1.11：fix: release-trigger uses release branch + PR instead of direct push to main (#1733)与fix: Split release process to sync pyproject.toml version with git tags (#1732)；
• v0.1.12：fix: use RELEASE_PAT so tag push triggers release workflow (#1736)。

这三次修复对应通讯中“improved the reliability of the automated release pipeline”的描述：发布流程从直接推 main 改为 release 分支加 PR，并把pyproject.toml版本与 git tag 的同步拆分出来，保证 tag 推送能稳定触发 release 工作流。

2.5 v0.1.13（2026-03-03）——Kiro CLI 与收尾修复

v0.1.13 是当月信息量最大的一个版本，也是 2 月工作的收官：

• feat: add kiro-cli and AGENT_CONFIG consistency coverage (#1690)：Kiro CLI 智能体集成正式进入支持列表，并补充了 AGENT_CONFIG 一致性测试覆盖；
• feat: add verify extension to community catalog (#1726)、Add sync extension to community catalog (#1728)：验证与同步类社区扩展入库；
• fix(scripts): add empty description validation and branch checkout error handling (#1559)：脚本层空描述校验与分支切换错误处理；
• fix(checklist): clarify file handling behavior for append vs create (#1556)：即通讯提到的“澄清输出文件如何创建/追加”的文件处理问题；
• fix(clarify): correct conflicting question limit from 10 to 5 (#1557)：修正 clarify 命令中相互矛盾的问题数量上限。

注：CHANGELOG 中 0.1.11–0.1.13 的标注日期落在 3 月 2 日、3 日，与通讯“late February shipped in preparation for the next version bump”的叙述一致——这些版本在 2 月下旬开发、3 月初标注，随后并入 v0.2.0。

三、双目录扩展体系：core 与 community 双轨并行

通讯称本月“主要架构新增”是模块化扩展系统，即第三方插件分为“core”与“community”两个独立目录。这个设计在当前仓库中有清晰的落地形态：

3.1 两个目录文件的结构对比

核心目录 extensions/catalog.json 只收录 4 个spec-kit-core出品、bundled: true的扩展：

• agent-context（Coding Agent Context，管理 CLAUDE.md、copilot-instructions.md 等上下文文件）；
• assess（Idea Assessment Pipeline，intake/research/define/shape/decide 五步评估）；
• bug（Bug Triage Workflow，缺陷评估-修复-验证）；
• git（Git Branching Workflow，特性分支创建、编号、校验与远端检测）。

社区目录 extensions/catalog.community.json 则采用完全不同的条目规范：每个社区扩展携带download_url（zip 下载地址）、repository、homepage、documentation、license、category（如 process/integration/docs/visibility）、effect（read-only/read-write）以及依赖约束requires.speckit_version（例如 Azure DevOps 集成要求>=0.1.0并强制az工具）。条目还带verified、downloads、tags等字段用于展示与筛选。

3.2 双目录并存的工程支撑

从源码结构看，双目录不是“两个 JSON 文件”这么简单，而是有完整的服务层支撑：src/specify_cli/bundler/ 下的services/catalog_stack.py与services/resolver.py负责多层目录的叠加解析与冲突消解（services/conflict.py 处理同名组件冲突），tests/integration/test_bundler_catalog_stack.py 对目录叠加行为有专门的集成测试。

此外，pyproject.toml 的force-include配置将extensions/git、extensions/agent-context、extensions/assess、extensions/bug打进 wheel 包（specify_cli/core_pack/extensions/），使specify extension add在离线环境也可安装核心扩展；而bundles/catalog.community.json快照同样被打包（用于离线发现）。

3.2.1 多目录并发激活在 v0.2.0 完成

2 月的 0.1.7 文档化了双目录并存，而“同时激活多个目录”的能力（feat(extensions): support multiple active catalogs simultaneously (#1720)，即通讯所说“support for multiple agent catalogs concurrently”）在 v0.2.0 中落地。

四、智能体集成扩展：从 Kiro CLI 看接入模式

通讯指出，2 月“将 Kiro CLI 加入支持智能体列表，并为 Cursor 与 Code Interpreter 更新集成脚本，使受支持的 AI 编码助手总数超过 20 个”。当前 src/specify_cli/integrations/ 目录下按字母序排列了 agy、alquimia、amp、auggie、claude、cline、codex、copilot、gemini、grok、kiro_cli、qwen、tabnine、vibe 等 36 个集成包，与“超过 20 个智能体”的描述吻合。

以 Kiro CLI 为例，其集成实现 src/specify_cli/integrations/kiro_cli/init.py 展示了 Spec Kit 接入新智能体的典型模式：

class KiroCliIntegration(MarkdownIntegration): key = "kiro-cli" multi_install_safe = True config = { "name": "Kiro CLI", "folder": ".kiro/", "commands_subdir": "prompts", "install_url": "https://kiro.dev/docs/cli/", "requires_cli": True, } registrar_config = { "dir": ".kiro/prompts", "format": "markdown", "args": _KIRO_ARG_FALLBACK, "extension": ".md", }

几个值得注意的实现细节：

1. 参数占位符的回退策略：Kiro CLI 的文件式提示词不支持任何参数替换语法，若把原始$ARGUMENTS原样交给模型会破坏提示词（源码注释指向 issue #1926），因此该集成用_KIRO_ARG_FALLBACK（“用户将在本次对话中提供该参数”的自然语言占位）替代机械替换；
2. 多安装安全标记：multi_install_safe = True声明 Kiro CLI 的所有产物都位于静态隔离的.kiro/根（命令放在.kiro/prompts），与其他集成互不写冲突，可安全共存（对应 issue #3471 的隔离约定，注册表对声明该标记的每个集成都有契约测试强制校验）；
3. 一致性测试：v0.1.13 的 #1690 补充的 “AGENT_CONFIG consistency coverage”，对应 tests/test_agent_config_consistency.py，确保智能体配置在各集成间保持一致；Kiro CLI 自身的行为由 tests/integrations/test_integration_kiro_cli.py 覆盖。

Tabnine CLI 的支持则由外部贡献者以 PR #1503 提交、在 2 月下旬合入，最终随 v0.2.0 发布——这正是通讯中“外部贡献者提交了包括 Tabnine CLI 支持在内的 pull request”的出处。

五、社区与内容：SDD 认知扩散的一个切面

2 月的社区活动集中在“把 SDD 讲清楚”上：

• Eduardo Luz（2 月 15 日，LinkedIn）：《Specification Driven Development (SDD) and the GitHub Spec Kit: Elevating Software Engineering》。文章以其高级工程师经验分析技术债与不一致设计的常见成因，并讲解 Spec Kit 的四层方法（Constitution、Design、Tasks、Implementation）与“把规格当作事实来源”的理念；
• Erick Matsen（Fred Hutchinson Cancer Center，2 月 10 日）：《Spec-Driven Development with spec-kit》。他描述一天之内用 Spec Kit 工作流（从speckit.constitution到speckit.implement）构建一条生物信息学流水线，附命令输出与过程决策，例如为补齐领域需求而反复精化规格。他写道：“我真心推荐这种方式，它感觉就是软件开发本来的样子”；
• 教程类内容：IntuitionLabs 更新（2 月 21 日）了覆盖 SDD 哲学与四阶段工作流的 Spec Kit 指南；Ry Walker（2 月 22 日）总结了 Spec Kit 的 agent-agnostic 设计与 71k-star 规模；微软开发者博客 2025 年末 Den Delimarsky 的《Diving Into Spec-Driven Development with GitHub Spec Kit》持续在新用户中流传；
• 线下活动：2 月 25 日，克利夫兰 C#/.NET 用户组举办《Spec Driven Development with GitHub Spec Kit》专场，由 Microsoft MVP Eric Boyd 主讲（他本人特别注明与微软 AI 平台副总裁同名不同人），内容涵盖规格如何改变 AI 编码助手的输出、规格多轮迭代精化的模式，以及从“随手提示”转向可重复的规格驱动工作流。GDG Madison 等用户组也在 2 月底至 3 月初安排了 SDD 议题；
• GitHub Discussions：安装排障、多特性项目下分支模型的使用、功能建议等话题活跃。其中一个讨论指出 Spec Kit 把每个 spec 视为绑定特性分支的短生命周期产物，进而引出对长期“spec of record”用法的支持讨论——这直接进入了下文路线图。

六、SDD 生态坐标：Spec Kit 在同类工具中的位置

2 月的生态动态帮助定位 Spec Kit 的方法论属性：

• AWS Kiro2 月 18 日发布 0.10 版本：新增Design-First工作流（从架构/伪代码反推需求）与Bugfix模式（结构化根因分析，产出bugfix.md规格文件），并加入 AI 变更的 hunk 级代码评审与任务前后钩子；2 月 17 日 Kiro 扩展到 GovCloud 区域以满足政府合规场景；
• OpenSpec（Fission AI）：轻量 SDD 框架，约 29.3k stars、近 2k forks（通讯记录值），当月社区发布了多篇指南与对比文章，强调通过 YAML 配置对接多种 AI 编码助手，主打简洁与灵活；
• Tessl：仍处于私有测试阶段。据 Thoughtworks 的 Birgitta Boeckeler 描述，Tessl 走spec-as-source路线——规格长期维护并一对一直接生成代码文件，生成代码标注“do not edit”。这与 Spec Kit“按特性/分支创建规格”的现状形成对照；
• arXiv 预印本（2026 年 1 月）将 SDD 实现分为三个层级：spec-first（规格优先）、spec-anchored（规格锚定）、spec-as-source（规格即源）。该文将 Spec Kit 归类为“以 spec-first 为主、兼具 spec-anchored 要素”。技术媒体的评测则结论性地认为：借助 AI 的 SDD 比传统 Waterfall 更具迭代性，而非“重造瀑布”。

七、v0.2.0：2 月工作的整合点

通讯 Roadmap 部分确认v0.2.0 于 3 月上旬发布（CHANGELOG.md 标注 2026-03-09），整合了整个 2 月的产出，其变更清单与通讯描述逐条对应：

• feat(extensions): support multiple active catalogs simultaneously (#1720)—— 多扩展目录并发支持；
• feat(extensions): add Jira Integration to community catalog (#1764)与Add Azure DevOps Integration extension to community catalog (#1734)—— 两个社区贡献的项目管理集成（即通讯所说“February's Jira and Azure DevOps plugins were community-contributed”）；
• Pavel/add tabnine cli support (#1503)—— Tabnine CLI 智能体；
• feat: add review extension to community catalog (#1775)、Add fleet extension to community catalog (#1771)—— 代码评审与舰队（fleet）类扩展；
• Integration of Mistral vibe support into speckit (#1725)—— Mistral Vibe 集成；
• fix: wire after_tasks and after_implement hook events into command templates (#1702)—— 钩子事件真正接入命令模板；
• fix: use global branch numbering instead of per-short-name detection (#1757)—— 分支编号改为全局策略（分支编号逻辑可由 scripts/python/create_new_feature.py 与 tests/test_branch_numbering.py 复核）。

八、后续路线图（以通讯原文为据）

通讯列出的未来方向，可作为跟踪该项目演进的四个锚点：

1. 规格生命周期管理——支持跨多次迭代演化的长生命周期规格，而非绑定单一特性分支；GitHub Discussions 已有用户提出，对应的“spec-anchored”开发模式正在被考虑。仓库中的 docs/concepts/spec-persistence.md 与 docs/concepts/spec-of-specs.md 可视为这一方向的文档铺垫；
2. CI/CD 集成——把 Spec Kit 的验证能力（如speckit.checklist与speckit.verify）纳入 PR 工作流与项目管理工具；2 月的 Jira 与 Azure DevOps 扩展即为此铺路；
3. 持续的智能体支持——随着新的 AI 编码助手出现而持续新增集成；当月新增 Kiro CLI、Tabnine CLI，总数已超过 20 个；
4. 社区生态——开放扩展模式允许外部贡献者直接添加功能，README 现已链接 .NET、Spring Boot 等栈的社区 walkthrough 演示。

九、如何复核本月的每一项事实

本文所有版本事实均可在仓库内闭环验证，建议的复核路径：

• 版本内容：CHANGELOG.md 中## [0.1.7]至## [0.1.13]（约 1781–1857 行）与## [0.2.0]（1781 行起）各段，均含 PR 编号；
• 双目录结构：extensions/catalog.json（core，4 个 bundled 扩展）与 extensions/catalog.community.json（community，含 download_url/requires 等完整条目规范）；契约测试见 tests/contract/test_catalog_schema.py；
• 打包方式：pyproject.toml 的[tool.hatch.build.targets.wheel.force-include]段，说明核心扩展与社区目录快照如何随 wheel 分发以支持离线安装；
• 智能体集成：src/specify_cli/integrations/ 下各集成包、tests/integrations/ 下每智能体一测试文件的组织方式（如 test_integration_kiro_cli.py），以及 tests/test_agent_config_consistency.py 的配置一致性约束。

需要说明的证据边界：stars、forks、issue 数量等统计数据均来自通讯原文的记录（约 71k stars、6.4k forks、当月关闭 330+/累计 870 个 issue 等不同段落口径略有出入），属于通讯转述值，本文未另行核验；而版本行为、扩展清单字段与集成实现则以当前仓库的 CHANGELOG、目录文件与源码为准。

【免费下载链接】spec-kit💫 Toolkit to help you get started with Spec-Driven Development项目地址: https://gitcode.com/GitHub_Trending/sp/spec-kit