SKILL.md
soia-dev-fix-loop
将 review、测试或运行中发现的问题当作可追溯工单处理。输入是一份或多份 findings；输出是逐项处理记录、经过回归验证的修复，以及不能修复项的明确理由和后续路径。
适用范围
适用于普通工程仓库中的结构化 findings、失败测试或可定位缺陷。若任务受某个组织的专属状态、审批或归档规则约束，先加载对应的绑定层；本技能不假设任何特定目录、项目或工具链。
单个显而易见的小修改也应保留最小记录：复现证据、修复、相关回归和回执。
客户可读说明
这个技能可以做什么
| 客户想要 | 执行闭环 | 客户能看到 |
|---|---|---|
| 按审查意见逐条修复 | 汇总、决策、修复和逐项验证 | 每条 finding 的状态与证据 |
| 确认是否可以收口 | 独立复核修复和回归结果 | 通过、需修改或受阻的结论 |
| 暂缓部分问题 | 给出可追踪的后续位置与原因 | 明确的延后边界 |
客户如何使用
提供 findings、目标工作区、相关测试或复现信息，以及允许的修改范围。若某项可能涉及删除、覆盖、远端状态、发布或扩大范围，先明确授权；信息不足时先整理输入清单，不开始修改。
依赖与安装
安装：
claude plugin marketplace add soia-team/soia-open-skillsclaude plugin install soia-dev@soia只要这一个技能时，可用 npx 路线。注意技能会落进共享真源 ~/.agents/skills；若同时装了插件，同一技能会出现两份索引且各自漂移，建议二选一：
npx skills add soia-team/soia-open-dev-skills -g -a '*' -s soia-dev-fix-loop -y本技能无需其他专用安装或私有配置。强依赖是可访问的 findings、目标工作区和与风险相称的验证入口；遵循目标仓库已有的贡献说明和检查约定。
WorkBuddy 的装载单位是角色化专家而不是插件，npx skills add -a '*' 覆盖不到它，需要单独安装，见 docs/install/workbuddy.md。
私密信息与中间数据
- Findings、失败日志和复现材料可能含源码、账号或客户数据；只保留决策所需的最小摘录，先脱敏再进入回执或可提交 fixture。
- 修复和测试产物留在目标工作区；本技能不建立自己的持久 state、cache 或完整 findings 副本。需要长期追踪的 defer 项写入客户明确指定的 issue、任务系统或文件。
- 临时复现数据放在目标仓库既有测试目录或操作系统临时目录；任务结束后只清理本技能创建且已确认可删除的临时内容。
- 凭据仅使用 Provider 官方登录态或系统凭据库，不写入普通配置、命令、日志、测试或提交。
- 完成回执按 finding ID 记录决策、最小证据和验证结果，不回显完整 prompt、响应正文或无关日志。
日志与完成回执
过程记录输入数量、逐项决策、验证状态和阻塞原因。最终回执必须覆盖每条 finding 的结论、实际运行的检查、未处理项和残余风险；不得输出凭据或本机私有信息。
五步修复循环
1. 复现并规范化输入
读取全部 findings，提取唯一标识、严重性、位置、问题描述和来源。合并重复项；同一问题有不同严重性时采用较高等级，同时保留来源。对每条关键问题运行最小复现，或记录为什么当前无法复现。
| Finding | 严重性 | 来源 | 位置 | 复现证据 |
|---|---|---|---|---|
| F-01 | high | review-a | <file:line> | <命令或步骤> |2. 修复前逐项决策
每条 finding 必须在实现前选择一个状态：
| 决策 | 含义 | 必需依据 |
|---|---|---|
| fix | 本轮修复 | 目标行为和验证计划 |
| reject | finding 不成立 | 可检验的反驳证据 |
| defer | 暂不修复 | 可追踪的后续位置、负责人或触发条件 |
不得静默漏掉问题；不得用“以后再看”替代 defer。高风险决策或会扩大范围的修复先向用户说明影响并取得必要授权。
3. 实施最小修复
只修改使该 finding 满足目标行为所需的部分。禁止以 TODO、注释、屏蔽异常、降低断言或删除测试来伪装修复。每项修复应能在 diff 中找到对应证据；若多项修复互相依赖，明确写出依赖关系。
修改后搜索同类模式，决定是否纳入本轮；若排除，记录范围理由，避免将未检查的相似问题误称为已解决。
4. 回归与独立复核
每个 fix 项至少运行一条直接验证，并运行与改动面相称的回归检查。每个 reject 项复核其反驳证据；每个 defer 项复核后续链路真实存在且足够具体。
除测试外，使用独立路径攻击结论，例如检查 diff、构造反例输入、核对调用方，或由未参与实现的人复查。出现回归、空 diff、TODO 伪修复、无效拒绝理由或失效后续链路时，循环回到第 2 或第 3 步。
5. 收口并回执
只有所有条目都有 fix、reject 或 defer 的证据时才能收口。结论使用以下之一：
| 结论 | 条件 |
|---|---|
| approved | 修复通过，拒绝理由成立，延后链路有效 |
| changes requested | 存在未验证修复、遗漏或不成立的决策 |
| blocked | 缺少必要权限、环境、输入或后续承接 |
修复回执：<approved / changes requested / blocked>。
处理清单：<每条 finding 的决策与结果>
验证：<复现、直接检查、回归和独立复核>
未处理项：<defer 或 blocked 的原因和承接路径>
风险：<仍未覆盖的情形；无则写“无”>防遗漏与假修复门禁
- 输入清单中的每条 finding 都有显式决策；
- 每项修复都有代码或配置行为的 diff 证据；
- 直接验证与回归检查均实际运行，失败不被隐藏；
- 拒绝和延后均有可复核依据；
- 未把无关文件或无关重构混入修复提交。
安全边界
对删除、覆盖、远端写入、发布和扩大修复范围保留用户确认。不要在记录或示例中放入本机绝对路径、账户、凭据或私有项目上下文。