用途：这是一套规格驱动（spec-driven）的软件开发工作流技能，覆盖从需求、设计、任务跟踪到仓库贡献的完整生命周期。资料称其可利用原生并行子智能体调度和 200k+ 上下文窗口。
主要能力与核心产物：维护三份文档——requirements.md（用户故事与 EARS 验收标准）、design.md（技术架构、时序图、实现考虑）、tasks.md（可跟踪的实现计划），分别放在项目根目录或 /docs/requirements/、/docs/design/、/docs/planning/。
EARS 需求记法：EARS 即 Easy Approach to Requirements Syntax。基本模式包括：通用需求（“The system shall …”）、状态驱动（When/If 触发条件）、事件驱动（When/Upon 触发）、可选特性（may）、不期望行为（shall not），以及面向 AI 智能体的需求（约束智能体可见范围、交付证据、自主执行边界）。示例编号前缀为 U/E/S/N/O/A 加三位数字。资料还给出语法规则和正则解析器示例。
design.md 涵盖：概述、架构（系统图、组件结构、数据模型、API 契约、错误码表）、时序图、安全与性能考虑、Agentic Considerations（智能体可改目录、完成前必跑命令、需人工批准的决策、交接证据）、实现阶段划分。
任务跟踪：tasks.md 按阶段列出可勾选项，从确认范围、数据模型、核心功能、前端集成、验证到发布说明；完整脚手架参考 examples/feature-spec-example.md 或 scripts/create-spec-scaffold.ps1。
贡献指南：包含提交前清单（读 README/CONTRIBUTING、fork/clone、环境搭建）、issue 模板与创建时机、分支命名（feature/bugfix/hotfix/release + JIRA 编号）与分支保护规则、Conventional Commits 提交规范（feat/fix/docs/style/refactor/perf/test/build/ci/chore/revert，破坏性变更用 ! 和 BREAKING CHANGE 脚注）、提交命令示例、PR 清单与模板。
质量保证：强调两阶段审查（先规格符合性、后代码质量）、验证协议与反模式提示（不在计划明确前动手、不把验证当收尾、不混并规划与发布）。
跨客户端说明：可在 GitHub Copilot、Claude Code、Codex 中保持可移植。Codex 需将文件夹安装或同步到 $CODEX_HOME/skills/development-workflow 并在重大改动后重启。不强制 MCP；无 MCP 时用本地指令、捆绑资源、标准 shell/编辑器工具和直接验证作为回退，并以本地文件、测试、渲染输出、日志或截图为证据，不得在宿主未提供时声称使用了 MCP。
限制：资料未提供收费、价格、具体平台支持细节或效果数据；部分内容（如部分代码块）在原始资料中截断，暂未提供完整内容。