关于 refit
Refit 检查 OMC 会话记录和仓库检查项，找出 Agent 工作环境中的阻碍，而非审查产出的代码。它基于证据提出针对检查、指导、工具或信息获取的改进，并在获批前不实施。
主要功能
- 01读取轨迹、日志和会话报告
- 02检查仓库脚本与 CI
- 03将发现归入四类改进面
- 04按严重程度列出证据支持的提案
- 05获批前不实施改动
- 06支持无人值守生成提案
适用场景
- 01诊断会话中的反复停滞或重试
- 02发现未接入或失效的现有检查
- 03准备环境改进提案供审阅
- 04定时调查但不直接应用改动
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/refit确认已加载。
详细介绍
Refit
Refit 审视 Agent 工作所处的环境——不是它产出的代码（审查和验证由它们自己负责），也不是某一次启动运行的经验教训（沉淀环节负责那部分）。每一种工作都会留下摩擦：一个 ralph 循环反复卡在同一个检查上，一次 autopilot 运行因等待某个信号而停滞，一次调试会话中决定性的输出从未被记录到任何地方。OMC 对所有这些都有检测手段。Refit 读取这些检测结果，将记录下来的摩擦转化为环境变更，让下一次运行从一个更好的起点开始。
证据优先
审视从 OMC 的检测手段出发，而不是从清单出发。在向用户询问任何内容之前，先阅读：
trace_timeline/trace_summary—— 轮次在何处停滞、重复或低效地发散omc session friction report—— 会话记录下的关于自身的摩擦.omc/logs/和会话状态 —— 错误、重试、被吞掉的失败- 计划记事本
.omc/notepads/*/issues.md和problems.md—— 跨计划累积的问题 - 仓库自身的检查面（
package.json脚本、CI 工作流）—— 在提出任何新检查之前先阅读，因为一个存在但未接入或悄然失效的检查本身就是发现，而不是需要重新发明的东西
发现来自数据所显示的内容。空审视是有效的结果，并且要如实说明；捏造的发现与跳过审视同属违规。一个没有接入任何自动化检查的仓库本身就是一项发现，而不是中性的默认状态。
四个修复归属面
每项发现都要指明拥有其修复的归属面。不属于任何归属面的发现会被拒绝，并明确说明理由。
- 确定性检查 —— 失败是机械性的：固定的语法模式、被禁用的 API、导入形态、文件位置规则。修复方式是 lint 规则、hook 或 CI 任务——以仓库现有护栏中最廉价者为准。默认优先构建检查，而非编写规则。
- 引导面 —— 失败是无法由任何护栏替代的判断性决策：跨文件一致性、与周围风格匹配。修复落在对应的
docs/standards/卷册中，或落在CLAUDE.md/AGENTS.md中，且不超过启动沉淀环节所定义的薄入口预算。导航指针优先于叙述性文字。 - 工具面 —— 阻碍来自工具本身：昂贵或 token 效率低下的 MCP 调用、缺失的自动化、慢到在关键时刻无法运行的检查。修复落在
.mcp.json、scripts/、hook 或 OMC 配置中。 - 信息面 —— Agent 需要一个它无法触及的信号：开发服务器日志、服务状态、第三方只读访问。修复方式是接入日志、暴露状态，或记录访问路径。
这一划分的依据是执行压力所在的位置：实现上下文承载的压力最多（探索、编写和调试同时进行）；审查上下文接收的是一个 diff，不承载任何这类压力。因此，标准属于审查者和检查——绝不意味着向实现者加载更多指令。
提案与落地
- 按严重程度排列呈现发现，每项以
发现 → 归属面 → 预期变更的形式给出，并附一行检测手段证据（哪个检测手段，显示了什么）。 - 停下来等待用户批准。每一行都可单独批准或否决。
- 将已批准的发现写入其归属面。在写入任何引导性文字之前，调用 Skill 工具并传入
agent-doc-discipline，通过其验证清单。新安装的确定性检查必须先证明其有效，才算落地：先干净地运行一次，然后在一个故意引入的违规上演示它失败，再还原该违规。无法展示失败的检查要退回提案阶段——没人见过它触发的护栏只是装饰，不是保护。 - 记录每项发现落在何处——每行一个文件位置——以便下一次 refit 从记录出发，而不是凭记忆。针对某次启动运行会话的 refit 从该次运行的沉淀清单出发；启动运行可以通过点名某条经验教训，将其推迟到之后的一次 refit。
无头重构（无人值守调用）
重构由用户发起，但其调研无需用户坐在键盘前即可运行——只需用户来处理结果。主机调度器（cron、CI 定时器、自动化工具）可以启动一个无头 Agent 会话，由其调用此技能；调研会在同一契约下运行至其自然边界：
- 调研读取相同的工具，且不在任何地方落地任何内容：无头重构只生成提案列表——
finding → surface → intended change，每项附带一行工具证据——写入.omc/refit/pending-proposals.md，并且当配置了通知渠道（configure-notifications）时，还会在该处进行摘要，以便用户得知有一项调研正在等待。 - 未经用户批准，任何内容都不会触及任何界面，与交互式重构完全一致：提案按优先级排队等待，每项均可独立否决，而下一次交互式重构将从待处理列表开始，而不是重新运行调研。
- 空调研会如实说明（“no findings”），绝不填充内容——编造发现与跳过调研同属违规。
输出
- 发现按严重程度排序，每项都带有证据、界面和预期变更——每一行均可独立决定
- 批准后：哪些内容已落地，以及落地位置
- 被拒绝的发现，附原因
评论
支持 Markdown