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 forksEduardo Luz 在 LinkedIn 发文解读 SDD 与 Spec KitErick 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.72 月初更新文档以说明新引入的双目录扩展体系允许核心与社区扩展目录并存随后的补丁版本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.72026-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.92026-02-28——依赖维护v0.1.8chore(deps): bump actions/setup-python from 5 to 6 (#1710)v0.1.9chore(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.102026-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.122026-03-02——发布流水线修复v0.1.11fix: 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.12fix: 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.132026-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-contextCoding Agent Context管理 CLAUDE.md、copilot-instructions.md 等上下文文件assessIdea Assessment Pipelineintake/research/define/shape/decide 五步评估bugBug Triage Workflow缺陷评估-修复-验证gitGit Branching Workflow特性分支创建、编号、校验与远端检测。社区目录 extensions/catalog.community.json 则采用完全不同的条目规范每个社区扩展携带download_urlzip 下载地址、repository、homepage、documentation、license、category如 process/integration/docs/visibility、effectread-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, }几个值得注意的实现细节参数占位符的回退策略Kiro CLI 的文件式提示词不支持任何参数替换语法若把原始$ARGUMENTS原样交给模型会破坏提示词源码注释指向 issue #1926因此该集成用_KIRO_ARG_FALLBACK“用户将在本次对话中提供该参数”的自然语言占位替代机械替换多安装安全标记multi_install_safe True声明 Kiro CLI 的所有产物都位于静态隔离的.kiro/根命令放在.kiro/prompts与其他集成互不写冲突可安全共存对应 issue #3471 的隔离约定注册表对声明该标记的每个集成都有契约测试强制校验一致性测试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 Luz2 月 15 日LinkedIn《Specification Driven Development (SDD) and the GitHub Spec Kit: Elevating Software Engineering》。文章以其高级工程师经验分析技术债与不一致设计的常见成因并讲解 Spec Kit 的四层方法Constitution、Design、Tasks、Implementation与“把规格当作事实来源”的理念Erick MatsenFred Hutchinson Cancer Center2 月 10 日《Spec-Driven Development with spec-kit》。他描述一天之内用 Spec Kit 工作流从speckit.constitution到speckit.implement构建一条生物信息学流水线附命令输出与过程决策例如为补齐领域需求而反复精化规格。他写道“我真心推荐这种方式它感觉就是软件开发本来的样子”教程类内容IntuitionLabs 更新2 月 21 日了覆盖 SDD 哲学与四阶段工作流的 Spec Kit 指南Ry Walker2 月 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 区域以满足政府合规场景OpenSpecFission 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.02 月工作的整合点通讯 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)—— 两个社区贡献的项目管理集成即通讯所说“Februarys 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 复核。八、后续路线图以通讯原文为据通讯列出的未来方向可作为跟踪该项目演进的四个锚点规格生命周期管理——支持跨多次迭代演化的长生命周期规格而非绑定单一特性分支GitHub Discussions 已有用户提出对应的“spec-anchored”开发模式正在被考虑。仓库中的 docs/concepts/spec-persistence.md 与 docs/concepts/spec-of-specs.md 可视为这一方向的文档铺垫CI/CD 集成——把 Spec Kit 的验证能力如speckit.checklist与speckit.verify纳入 PR 工作流与项目管理工具2 月的 Jira 与 Azure DevOps 扩展即为此铺路持续的智能体支持——随着新的 AI 编码助手出现而持续新增集成当月新增 Kiro CLI、Tabnine CLI总数已超过 20 个社区生态——开放扩展模式允许外部贡献者直接添加功能README 现已链接 .NET、Spring Boot 等栈的社区 walkthrough 演示。九、如何复核本月的每一项事实本文所有版本事实均可在仓库内闭环验证建议的复核路径版本内容CHANGELOG.md 中## [0.1.7]至## [0.1.13]约 1781–1857 行与## [0.2.0]1781 行起各段均含 PR 编号双目录结构extensions/catalog.jsoncore4 个 bundled 扩展与 extensions/catalog.community.jsoncommunity含 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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 forksEduardo Luz 在 LinkedIn 发文解读 SDD 与 Spec KitErick 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.72 月初更新文档以说明新引入的双目录扩展体系允许核心与社区扩展目录并存随后的补丁版本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.72026-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.92026-02-28——依赖维护v0.1.8chore(deps): bump actions/setup-python from 5 to 6 (#1710)v0.1.9chore(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.102026-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.122026-03-02——发布流水线修复v0.1.11fix: 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.12fix: 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.132026-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-contextCoding Agent Context管理 CLAUDE.md、copilot-instructions.md 等上下文文件assessIdea Assessment Pipelineintake/research/define/shape/decide 五步评估bugBug Triage Workflow缺陷评估-修复-验证gitGit Branching Workflow特性分支创建、编号、校验与远端检测。社区目录 extensions/catalog.community.json 则采用完全不同的条目规范每个社区扩展携带download_urlzip 下载地址、repository、homepage、documentation、license、category如 process/integration/docs/visibility、effectread-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, }几个值得注意的实现细节参数占位符的回退策略Kiro CLI 的文件式提示词不支持任何参数替换语法若把原始$ARGUMENTS原样交给模型会破坏提示词源码注释指向 issue #1926因此该集成用_KIRO_ARG_FALLBACK“用户将在本次对话中提供该参数”的自然语言占位替代机械替换多安装安全标记multi_install_safe True声明 Kiro CLI 的所有产物都位于静态隔离的.kiro/根命令放在.kiro/prompts与其他集成互不写冲突可安全共存对应 issue #3471 的隔离约定注册表对声明该标记的每个集成都有契约测试强制校验一致性测试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 Luz2 月 15 日LinkedIn《Specification Driven Development (SDD) and the GitHub Spec Kit: Elevating Software Engineering》。文章以其高级工程师经验分析技术债与不一致设计的常见成因并讲解 Spec Kit 的四层方法Constitution、Design、Tasks、Implementation与“把规格当作事实来源”的理念Erick MatsenFred Hutchinson Cancer Center2 月 10 日《Spec-Driven Development with spec-kit》。他描述一天之内用 Spec Kit 工作流从speckit.constitution到speckit.implement构建一条生物信息学流水线附命令输出与过程决策例如为补齐领域需求而反复精化规格。他写道“我真心推荐这种方式它感觉就是软件开发本来的样子”教程类内容IntuitionLabs 更新2 月 21 日了覆盖 SDD 哲学与四阶段工作流的 Spec Kit 指南Ry Walker2 月 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 区域以满足政府合规场景OpenSpecFission 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.02 月工作的整合点通讯 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)—— 两个社区贡献的项目管理集成即通讯所说“Februarys 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 复核。八、后续路线图以通讯原文为据通讯列出的未来方向可作为跟踪该项目演进的四个锚点规格生命周期管理——支持跨多次迭代演化的长生命周期规格而非绑定单一特性分支GitHub Discussions 已有用户提出对应的“spec-anchored”开发模式正在被考虑。仓库中的 docs/concepts/spec-persistence.md 与 docs/concepts/spec-of-specs.md 可视为这一方向的文档铺垫CI/CD 集成——把 Spec Kit 的验证能力如speckit.checklist与speckit.verify纳入 PR 工作流与项目管理工具2 月的 Jira 与 Azure DevOps 扩展即为此铺路持续的智能体支持——随着新的 AI 编码助手出现而持续新增集成当月新增 Kiro CLI、Tabnine CLI总数已超过 20 个社区生态——开放扩展模式允许外部贡献者直接添加功能README 现已链接 .NET、Spring Boot 等栈的社区 walkthrough 演示。九、如何复核本月的每一项事实本文所有版本事实均可在仓库内闭环验证建议的复核路径版本内容CHANGELOG.md 中## [0.1.7]至## [0.1.13]约 1781–1857 行与## [0.2.0]1781 行起各段均含 PR 编号双目录结构extensions/catalog.jsoncore4 个 bundled 扩展与 extensions/catalog.community.jsoncommunity含 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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
