用途：这是 arc-bug-finder 的修复侧技能。输入是已归档的缺陷工单，输出是能关闭该工单、具备合并条件的 PR，并同步更新工单状态。技能只在独立确认缺陷真实且所引根因正确后才改动产品代码——工单是假设，不是工作指令。
主要能力与流程：1）接单，按 tracker（GitHub 用 gh issue view <number> --comments；GitLab 用 glab issue view <iid>；Linear 用 MCP/GraphQL）拉取工单全文并解析各部分；2）复核验证，重新复现缺陷、在 file:line 重新确认根因、检查是否已被修复、评估推荐修复方案、确认影响范围，产出 REVIEW VERDICT；3）确定修复策略；4）非平凡修复制定任务计划并回帖；5）从最新默认分支切 fix/W-XXXXXX-<short-slug> 分支实现最小正确改动；6）验证：复现消失、新增回归测试、既有测试套件通过、检查影响范围、UI 缺陷需视觉确认；7）Ship：按 Conventional Commits 提交，经 arc-git-pr-check 开 PR 并启用 squash 自动合并，PR 中链接工单；8）更新工单并向用户简要报告。
适用场景：修复由 arc-bug-finder 归档的真实缺陷、处理 bug backlog、在编排器下以只读探路与隔离工作树方式委派修复阶段。
限制与约束：每个工单先复核再修；不得无回归测试和绿色套件就发布；只做最小改动、不夹带无关重构；一工单一 PR；除非用户明确要求，否则不合并、不部署，仅从已合并的 main 部署；不得提交或暴露 API token（LINEAR_API_KEY、GITLAB_TOKEN），从环境变量读取并删除含密钥或截图的临时文件。已修复或无法复现的工单不写代码，附证据关闭；非缺陷工单回退打 wontfix/invalid 标签。
其他说明：在 arc-orchestrator 下由父级保留工单判断与审批权，仅委派有界阶段（codex-explore、composer-implement、codex-implement、codex-check、opus-review 等），worker 不提交、推送、评论、合并、部署或改动无关文件。相关技能：arc-bug-finder、arc-planning-work、arc-conventional-commits、arc-git-pr-check、arc-gitlab-glab、arc-parallel-implement、sf-2gp-pipeline、dogfood/agent-browser。收费、价格与平台信息暂未提供。