技能介绍

要解决的问题

写代码前先写规范（spec），多数团队都认同。但规范的实际命运通常是：被丢进文档目录，几天后没人再打开；或者在一次对话里口头约定，换一次会话就忘光。当代理（Agent）开始参与编码，这个问题更严重——代理没有共享记忆，每次运行都是全新的上下文，如果规范没有变成可传递的工件（artifact），它对代理来说等于不存在。

另一个问题是审查缺乏证据。PR 里一句“改好了”，评审者只能硬着头皮读 diff。没有结构化的审查记录，争议发生时谁也说不清当时判断的依据。

核心能力与关键步骤

这个技能用 Flow-Next 把“规范优先”变成一条可执行的流水线：

规范沉淀（Spec）：把粗略的编码意图整理成持久的规范文档，而不是口头约定。规范成为后续所有步骤的唯一输入源。
任务图分解（Task Graph）：把大目标拆成有依赖关系的子任务，形成任务图。每个节点是一次聚焦的工作单元，节点间的依赖让进度可追踪。
新鲜上下文运行（Fresh-Context Worker）：每个任务在全新的上下文里执行，而不是接着上一个任务继续。代价是上下文不连续，换来的是隔离与可复现——worker 只看到当前任务所需的规范片段。
对抗式审查（Adversarial Review）：产出不直接通过，而是进入一个专门挑毛病的审查环节，检查实现是否偏离规范。
回执与 PR 组装（Evidence & PR）：流程结束后产出结构化的证据回执（evidence receipts）和 PR 正文，审查者能直接看到每个决策的依据，而不是面对一个黑盒 diff。

整体思路是把“想清楚再写”变成工件驱动（artifact-driven）：规范、任务图、审查结论都是文件，可被检查、可被重放。

适用边界

依赖环境：需要一个兼容的代理宿主（如 Claude Code、Codex、Cursor、Factory Droid），以及 git；审查与 PR 流程还需要 jq 和 gh。
新鲜上下文意味着每个 worker 不携带历史记忆，规范和任务图必须自带足够的上下文，否则会出现重复工作或遗漏。
对抗式审查不是万能的：它检查的是实现与规范的一致性，无法判断规范本身是否合理——垃圾进，垃圾出。