Forward Implementation First 的作用
Forward Implementation First 是一项智能体技能，旨在防止编码智能体陷入流水线记录维护。它让智能体专注于构建用户要求的产品、验证受影响的行为并持续向前推进，而不是反复修复哈希、回执、锁、仪表板或进度标记。
该项目主要由一个约 150 行、带 YAML frontmatter 的 Markdown 技能文件组成。它遵循 Agent Skills 规范，不依赖特定模型、工具或领域。
这项技能尤其适用于由编排器记录有序阶段元数据的长时间运行工作流。当这些元数据过期时，智能体可能会误以为不匹配意味着先前有效的输出有误。Forward Implementation First 提供了一项决策规则，用于区分真正的正确性工作与行政性维护。
核心分类
在执行操作之前，智能体会将其归入以下三类之一。
- 语义实现：构建或连接生产者、消费者、适配器、运行时路径、模式、夹具或最终输出的工作。
- 聚焦验证：通过行为、模式、数量、有序样本、守恒性、一致性、非截断性，以及测得的时间或内存来检查变更后的依赖锥。
- 行政性记录维护：生成或修复哈希、锁、回执、仪表板、认证标记、进度元数据或仅表示存在的记录。
操作规则很简单：执行语义实现和聚焦验证。除非用户明确要求，或相关产物本身就是产品的一部分，否则跳过行政性记录维护。如果一个仅用于记录维护的依赖阻碍了有效工作，却不能保障正确性，就移除该依赖。
为什么流水线记录维护会成为问题
假设在一条流水线中，阶段 40 为阶段 41 创建文件。编排器还会写入一条 JSON 记录，其中包含完成标记和输入哈希。如果生产者发生变化，即使现有阶段输出仍然正确，哈希也可能不再匹配。
如果没有明确的策略，智能体可能会使许多早期阶段失效、拒绝手动运行阶段 41、重新生成无关标记，并将修复后的元数据报告为工作进展。每个局部决定看起来或许都很谨慎，但综合结果只是消耗时间，并未改善用户要求的输出。
行政性元数据不能替代证明输出正确的证据。
这项技能要求智能体验证实际结果，而不是把元数据是否存在或是否最新视为证明，从而避免这种失败。
这项技能不会放宽哪些要求
Forward Implementation First 并不是让智能体忽视正确性。它会区分可丢弃的编排记录，以及真正保护产品的完整性机制和证据。
- 仍然必须保证产品完整性。由用户验证的校验和、必需的签名，以及输出契约定义的哈希都是产品功能，而不是文书工作。
- 仍然必须确认输入和修订版本的身份。智能体必须知道自己正在修改哪个版本或目标。
- 仍然必须执行以结果为导向的测试。基准测试、复现、测试和端到端运行仍能提供必要证据。
- 覆盖不等于结果正确。执行过某条路径，并不能证明该路径生成了正确答案。
包含命令、输入、结果和已检查预期的执行记录，可以成为真正的证据。如果缺少该记录，智能体就不能作出本应由该记录支持的声明。然而，缺少它并不会自动使流水线中更早的无关阶段失效。
安装
安装到检测到的智能体技能目录
克隆代码仓库并运行随附的安装脚本：
git clone https://github.com/Vuk97/forward-implementation-first
cd forward-implementation-first
./install.sh该脚本会将 SKILL.md 复制到检测到的所有受支持智能体技能目录。文档列出的目标目录如下：
- Claude Code：
~/.claude/skills/forward-implementation-first/ - Codex：
~/.codex/skills/forward-implementation-first/ - 共享规范：
~/.agents/skills/forward-implementation-first/
为单个项目安装
如需项目级行为，请将技能目录复制到仓库内的 .claude/skills/ 或 .agents/skills/。这样，该策略只会与该项目关联，而不会安装到每个工作区。
安装后请重启智能体。现有会话不会自动重新加载技能。
技能只是一项建议，是否加载由模型决定。如果智能体支持始终启用的规则或钩子，也应将核心决策规则放入其中。
基本用法
第 1 步：确定下一个与产品相关的操作
从当前流水线游标或下一个未完成的依赖开始。判断拟议操作是在修改实现、验证变更带来的结果，还是仅仅修复编排元数据。
拟议操作：将阶段 41 连接到阶段 40 生成的输出。
分类：语义实现。
决定：执行该操作。第 2 步：验证发生变化的依赖锥
实现完成后，测试可能受到影响的最小范围。适当的检查可以包括模式、行数或项目数、有序样本、守恒属性、一致性、截断检测、端到端行为，以及测得的资源使用情况。
拟议操作：更改阶段 41 的生产者后，验证该阶段的模式、输出数量、
有序样本和非截断性。
分类：聚焦验证。
决定：执行检查并记录证据。第 3 步：默认不将记录维护作为目标
如果拟议操作只是重新生成过期的回执或完成标记，请跳过该操作，除非用户要求提供该产物，或它本身就是交付物的一部分。
拟议操作：为未发生变化的阶段 12 至 40 重新生成完成回执。
分类：行政性记录维护。
决定：跳过，除非用户明确要求或产品需要。第 4 步：移除仅用于行政管理的门槛
如果过期标记阻止下一个有效阶段运行，却无法保障正确性，请手动运行该阶段、验证其输出、发布结果，并从游标位置继续。随后移除这个仅用于行政管理的依赖，避免同样的阻碍再次出现。
应用前向游标规则
只有存在实质性理由时，才应重放或回滚已完成的阶段。这项技能认可以下理由：
- 阶段输入的含义发生了变化。
- 目标或固定的修订版本发生了变化。
- 输出格式错误、被截断、不守恒、不一致，或与其消费者不兼容。
- 实际运行结果推翻了先前的静态结果。
- 发生变化的生产者所声明的依赖锥包含该阶段。
仅仅缺少元数据或元数据过期并不构成充分理由。应重放受影响的最小依赖锥，而不是重新执行全部历史阶段。
恢复决策示例
观察：阶段 40 的回执哈希已过期。
输出检查：阶段 40 的产物格式正确，并且与阶段 41 兼容。
依赖检查：发生变化的生产者不会影响阶段 40 的语义。
操作：不要重放阶段 40。继续执行阶段 41 并验证其结果。如果验证发现输出格式错误或不兼容，则有理由进行重放，因为此时的原因属于语义问题，而不是行政性问题。
使用工作器池时避免产生相互竞争的事实来源
这项技能还定义了一套规范的并行工作方法。
- 同一时间只运行一个重型进程，例如编译器、完整测试套件、大型数据作业、基准测试或长时间扫描。
- 使用并行通道处理互不重叠文件上的轻量工作。
- 获准使用包含
N个工作器的池时，应在各通道完成后立即补充任务，而不是等待整个批次全部完成。 - 不要仅仅为了让每个工作器保持忙碌而虚构低价值任务。
- 将重型执行、发布、游标移动和最终结论保留在根通道中。
- 并行工作器可以进行准备和检查，但在使用其输出之前必须验证。
- 不要为了等待每个通道而阻塞后续进展。当执行到某个通道对应的依赖时，再使用该通道的结果。
这种结构既能实现有效并发，又能避免多个工作器成为相互竞争的事实来源。
高级技巧
将决策规则移入始终启用的配置
由于模型可能选择不加载某项技能，因此具有持久规则或钩子的环境也应在其中重复核心策略：对每项操作进行分类，执行实现和聚焦验证，并避免进行未经请求或与产品无关的行政性工作。
明确定义产品完整性
记录哪些哈希、签名、清单或审计记录属于输出契约的一部分。这样既能防止智能体错误丢弃真正的产品功能，又允许其忽略可丢弃的编排标记。
声明依赖锥
在可能的情况下，明确生产者与消费者之间的关系。清晰的依赖锥有助于智能体只重放受影响的阶段，避免因不确定性而大范围判定失效。
记录证据，而不只是存在状态
应优先采用能够标明命令、输入、结果和预期条件的记录。仅表示存在的标记只能说明某项操作运行过；包含证据的记录则有助于证明它是否正确完成。
将准备工作与决策权分开
使用并行工作器检查文件、准备补丁或收集信息，但将执行权和结论保留在根通道中。合并或发布工作器输出之前，必须先进行验证。
何时使用这项技能
Forward Implementation First 适合以下场景：
- 包含有序阶段和持久化游标的流水线。
- 由后续阶段使用的生成产物。
- 包含编排器生成的清单、锁文件或回执的工作流。
- 在没有持续人工监督的情况下继续进行的运行任务。
- 由多个智能体或会话操作的代码仓库。
- ETL 流水线、分阶段数据处理、大规模代码迁移、构建和发布工作流、文档生成、批量分析，以及持续多天的路线图。
对于一次性任务、短暂的交互式会话，或审计轨迹本身就是交付物的工作流，请勿使用这项技能。如果用户或审查者需要查看回执，这些记录就是产品的一部分，而不是行政性开销。
总结
Forward Implementation First 为编码智能体提供了一套范围明确且实用的准则：构建产品、验证受影响的行为，不要将流水线文书工作误认为正确性。它的前向游标规则可以减少不必要的重放，而工作器池指南则支持安全的并行处理。安装该技能并重启智能体；如果环境支持，还可通过始终启用的配置强化其决策规则。