用途
该技能面向自动化缺陷处理流程：从 Slack 来源线程中读取经分诊的缺陷报告，在目标应用的真实 UI 中复现问题，验证已有修复，并在满足严格条件后尝试有边界的修复并提交草稿拉取请求。
主要能力
- 冻结来源频道与根线程坐标，确保所有操作基于不可变坐标。
- 等待可信分诊标记（如 [benny:bug]、[benny:performance]），仅对 bug 或 performance 继续处理。
- 应用所有权与修复产物门禁：若有人明确认领修复或已存在修复产物，则停止或切换到验证模式。
- 通过配置的应用控制适配器驱动真实 UI 进行复现，要求同一判别性症状出现两次。
- 捕获截图与录屏，并由只读媒体审查者确认证据。
- 在满足全部条件时尝试有边界的修复，使用 TDD 原则，并证明修复前后行为差异。
- 仅在获得前后证据后打开草稿拉取请求，绝不合并或部署。
使用方式
技能由自动化流程调用，需加载外部 Benny 配置。若配置、所需操作、控制适配器或已完成的功能映射缺失，则失败关闭。协调器是唯一允许在 Slack 发帖的角色；委派的分析工作者为只读，且所有子提示必须明确禁止 Slack 写入操作。修复阶段的代码工作者仅在其环境可证明排除 Slack 凭据和所有 Slack 写入操作时才可编辑，否则由协调器编辑。
适用场景
适用于已建立 Slack 分诊流程、配置了应用控制适配器、并希望自动化复现与修复缺陷的团队。需要目标应用具备可驱动的真实 UI、可用的功能映射以及可运行基线与补丁构建的环境。
限制
- 无确认复现则不得编写修复。
- 已有拉取请求或提交时切换到验证模式，不得覆盖。
- 若适配器缺失或缺少任一所需能力，标记为阻塞并停止。
- 不得将截图、单元测试、状态变更或源码阅读伪装为 UI 复现。
- 修复必须符合配置的修复预算与仓库范围。
- 不得从该工作流合并或部署。
- 若拉取请求创建失败，不得声称成功。
- 具体配置项、预算数值、保留策略等细节暂未提供。