用途
Feature delivery pipeline 是一项编排型技能，负责把一句话的模糊功能请求推进到可评审的拉取请求（PR）。它本身不直接完成所有工作，而是按顺序调用其他技能，并在每个阶段之间设置检查点，让用户在关键节点确认或调整方向。
主要能力
- 按固定阶段驱动功能开发：起始套件、追问与草图、编写验收契约、实现、破坏性验证、签署交付、复盘，以及部署前的生产就绪评审。
- 每个阶段结束时生成检查点：用用户的语言给出简短总结、产物路径、采用的默认值和一个明确问题，然后停下等待回应，不把下一阶段混在同一条消息里。
- 支持无人值守模式：当用户表示“不要问我”“自己决定”时加载 unattended-run，把检查点转换为已记录决策和状态行，并指出仍需用户执行的动作。
- 内置管道级约定：简化技术语言、scratchpad 工作文件、Git 提交整理、无冗余代码、决策记录日志、红绿灯式发现、纯视觉文档。
- 阶段 0 会创建分支、生成 slug、建立 .scratchpad/<slug>/progress.md，并判断请求是否适合一次迭代完成；不适合则按可独立验证的交付拆分。
- 缺陷报告可从 bug-intake 进入，走较短的修复路径。
使用方式
通过技能工具调用各阶段技能，而不是直接读取技能文件。若项目技能未列出，则直接读取项目 SKILL.md 并告知用户；同名用户技能会覆盖项目技能。在阶段 0，若 AGENTS.md 中没有 YesYak 块或标记为未设置，会提示并建议先运行 customize-yak；用户可拒绝并继续。用户给出的工作规则（语言、分支命名、提交风格）可提议写入 AGENTS.md，避免只留在聊天中而在下次会话丢失。每个检查点都会更新 progress.md 的阶段、状态、产物和提交，以便会话中断后恢复。
适用场景
适合需要把功能请求从模糊描述推进到可评审 PR 的开发工作流，尤其是希望在每个阶段获得用户确认、避免方向偏离的场景；也适合需要拆分多个可独立验证交付的功能；缺陷修复可走较短入口。可选步骤（如原型选项、红队评审、浏览器验收测试、工作项拆分、功能走查、交接与恢复、生产就绪评审）默认不执行，由用户选择。
限制
资料未提供该技能的性能指标、收费、价格、平台支持范围或实际效果数据。各阶段的具体执行细节依赖被调用的其他技能，资料仅给出阶段名称与检查点问题，未逐一展开。是否需要 YesYak 初始化、分支与远程工具是否可用等前置条件需在阶段 0 确认。