用途：依据一份设计文档交付整个功能。设计文档界定范围，GitHub Issue 跟踪故事进度，Pull Request 记录实现、评审、验证与合并历史。
主要能力：使用三个专门环节——design-to-issues 同步故事到 GitHub；user-story-delivery 一次交付一个 issue；post-implementation-reviewer 做最终功能审计。若所需专门环节不可用，应报告该前置条件，而不是在同一上下文中把实现与独立评审悄悄合并。
使用方式：先读取仓库说明和完整设计文档，要求 Status: Revised 并以 delivery 模式运行 design-to-issues 故事校验器；在变更前清点需要凭据、权限、部署、物理硬件、人工观察或时间的交付门禁，报告每个门禁、责任人、证据和最早依赖点。运行 design-to-issues 为每个当前故事创建或更新一个规范 GitHub Issue，检查所有规范故事 issue，只处理依赖已完成的故事。对依赖就绪的开放 issue 调用 user-story-delivery，要求实现全部验收标准、获得独立评审、处理阻塞发现、按仓库策略合并并验证 issue 关闭。全部故事完成后，用原始设计文档调用 post-implementation-reviewer 审计整体实现、故事完成度、跨故事行为、文档和相关验证。
完成规则：故事完成需满足规范 issue 反映当前需求、每条验收标准有实现与验证证据、独立评审无未解决阻塞问题、所需检查与仓库合并策略通过、已评审的 PR head 被合并、规范 issue 关闭。功能完成需所有当前故事满足上述规则且整体审计无阻塞发现。
限制：当前仓库与 GitHub 状态优先于对话交接；先解决重复 issue 或 PR；保留无关和脏工作区改动；不得因执行者慢或中断就替换进行中的工作；未经用户明确授权不得移除或推迟设计故事；未执行的人工验证不得视为通过；仅剩外部、人工或时间依赖门禁时，记录确切继续条件并交回控制权；遵循仓库特定的分支、评审、检查、合并和分支保留策略；未经用户授权不得创建或完成运行时目标。