ai-dlc

Turn a fuzzy natural-language requirement into a machine-verifiable acceptance contract. Drafts EARS-format requirements (five sentence types), runs a strict clarify loop (only three question types allowed: ambiguity / missing edge / undefined term; 2-3 rounds, 3-5 questions per round, max 5 rounds total) to remove every [?] marker, then writes five files: proposal.md, spec.md (EARS with stable REQ-IDs), tasks.md (decomposed work), done_when.yaml (the contract that test-suite-generator and acceptance-fleet will consume), and spec-robustness.md (S2.5 self-adversarial pass output — anti-gaming companion that /acceptance-fleet hands to /spec-gaming-detector). Covers Steps 1-3 of the done_when pipeline. Triggers: "spec this requirement" / "draft EARS" / "done_when for X" / "clarify this feature" / "acceptance criteria" / "write the contract" / "/acceptance-spec".

补引擎自己给不出的三个缺口：跨会话的生命周期状态（SKILL.state 式的充分统计量——脚本校验 迁移，引擎只提议，历史进只增不删的账本）、失败按层归因回流而不是"塞回实现层再试一次"的 路由表 + 分层预算 + 指纹终止（X2），以及三道只能人签的门（G1 世界裁决 / G2 判据冻结 / G3 例外复核）的不可跳过绑定。效果：一句需求或一个 issue → 双轨判定 → issue → 分支 → done_when 冻结 → 任务卡 → 按卡实现 + 提交 → PR → review 跟进 → 合入归档 → 逃逸缺陷登记， 每一步的产物要么能被机器检，要么被一道门挡住。Use when: "走一遍完整开发流程" / "从需求到 合入" / "aidlc" / "按流水线做这个需求" / "帮我把这个 issue 做完提 PR" / "resume AI-DLC" / "ship this feature end to end" / "run the lifecycle"。NOT for: 只想提交一次 commit（/commit）、 只想发 PR（/pr）、只想审别人的 PR（/pr-review）、只想盯一个已有 PR 的评论（/review-loop）—— 单点动作直接用对应 skill，进流水线反而慢。前置：git 仓库内、gh 已认证、python3。

补引擎自己给不出的缺口：一次提交什么时候算"原子且可审"（一个关注点、消息按 Conventional Commits、只暂存相关文件、不带调试代码与 secrets），以及 diff 落地前的三道机械闸——卡的可改 文件白名单（溢出即停）、G2 锁文件哈希（改契约必须附变更提案）、暂存 hunk 的 secret / 调试 代码扫描——全部编译在 verify_commit.py 里，不靠"记得检查"。Use when: "提交" / "commit 这些改动" / "帮我写 commit message" / "把这个 diff 提了" / "commit" / 引擎准备 `git add -A && git commit -m "update"` 时。NOT for: 推送与建 PR（/pr）、 合并分支、改写已推送的历史（本 skill 禁止）。前置：git 仓库内。

补引擎自己给不出的缺口：把"逐节点陪 Agent 对齐需求"（grill-me 的 BFS）和"让 Agent 自己 grill 到它 觉得对齐"（AFK 环）都换成一个停机不靠自评的对齐环——问题集来自形状（PSL 六层的承重槽 · DOS 词表 闭包 · AC 的 happy/unhappy 孪生），不是 Agent 临时想到的树；通过条件来自 N 个隔离读者的分歧率与一份 逐条有来路的待定清单，不是"我觉得清楚了"；每条槽只能以三种方式离开清单（物料来路可核对 / 人答 / 明确 留给人），默认值被脚本硬拒。效果：一句需求 → `/psl --afk` 无人值守建世界 → `/psl-derive --n 3` 分歧集 → `grill_loop.py pending` 抽清单 → 机器先回仓库找来路、找不到才 defer → 人只裁 needs_human 行 → 拿答案重推一轮 → converged 进 G1。Use when: "自动 grill" / "AFK 对齐需求" / "grill 这个需求但别一个个问我" / "先把能从代码里答的答了再来问我" / "align the requirement unattended" / "run the grill loop"。 NOT for: 交互式逐题逼问（用 grill-me 类技能）、确定性需求（PRD 够用，双轨判据在 /issue 入口拦）、 写 PSL 本身（/psl）、推导本身（/psl-derive）。前置：python3 + pyyaml；仓库里最好有 dos.yaml / decisions.md（没有时来路只能来自代码与文档，清单会长，这是诚实不是失败）。

补引擎自己给不出的缺口：按一张卡实现时的隔离与纪律——实现者只看到卡 + 状态摘要 + AC 子集 （不看评审判据、不看隐藏集、不看其他卡），改动落地前过白名单执行器与 G2 锁，复现测试先红后绿， 每张卡一个或多个原子 commit 并登记到状态机；单卡预算 3、同指纹失败立即升级到方案层而不是原地重试。 效果：卡进、diff + commit + 卡状态出。Use when: "按卡实现" / "做 CARD-03" / "implement this card" / "开始写代码" 且已有卡与冻结契约时。NOT for: 拆卡（/plan-cards）、修 review 评论（/review-loop 的 comment-fixer）、跑到达标为止的优化循环（/ratchet）、整体验收（/acceptance-fleet）。

Use when a Territory's □-class resident invariants are MISSING — when "what this block must always hold, on every Run" lives only in people's heads or in scars from past failures, not as written, traceable, verifiable rules. invariant-extract recovers them by ABDUCTION from the Territory's failure memory (the load-bearing channel — a violation is the most reliable signal an invariant exists) and by DEDUCTION from its code execution points. It is the symmetric counterpart of dos-extract (which deductively reverse-engineers a system's constitution + ontology from a static repo); this one abductively recovers ONE Territory's resident invariants from the failures it paid for. Triggers: "抽不变量" / "提取不变量" / "责任级不变量" / "□ 不变量" / "从失败里总结规则" / "把失败变成不变量" / "为这块领地立常驻法" / "invariant-extract" / "harden this territory's invariants". Do NOT use for: binding / claim-resolution (orthogonal, human-set), ontology / boundary (that is dos-extract), or task-level done_when (that is acceptance-spec).

补引擎自己给不出的缺口：一条 issue 什么时候算"可证伪的 TASK 雏形"而不是一段愿望（形容词 换成阈值、每条 happy 路径带 unhappy 孪生、验收写观察边界不写文件路径、范围四项非空、假设进 台账）；一个需求该走 PSL 轨还是 TASK 轨的双轨判据（含 DOS 词表闭包这个客观触发）；以及 "先给人看再 gh 建"的确认门。效果：一句需求 / 一个 bug / 一条逃逸缺陷 → 结构化 GitHub issue， 经 verify_issue.py 机械预门后创建。Use when: "建个 issue" / "把这个需求写成 issue" / "开个 bug" / "登记逃逸缺陷" / "create an issue for" / "file a bug" / "write this up as an issue" / 引擎准备直接 `gh issue create --body "<一句话>"` 时。NOT for: 写完整 done_when.yaml 契约（/acceptance-spec）、写产品世界（/psl）、只想看 issue 列表（gh issue list 即可）。 前置：gh 已认证、在目标仓库内。

补引擎自己给不出的缺口：把一份冻结的判据契约拆成"单独丢给一个没有任何上下文的 agent 也能干完"的 任务卡——每张卡带 REQ 归属、AC 子集、DOS 切片、可改/禁改文件白名单、上下文预估与预算；以及三项 机器校验（REQ 全覆盖且无重复归属 · 卡间无文件写冲突含共享文件归属 · 名词能被 DOS 切片解析）、 上下文 ≤ 40k 必拆的 lint、以及"投影与其数据源同卡"（渲染/报告脚本必须声明 reads_from，跨卡要 depends_on + 接缝说明），全部编译在 lint_cards.py。Use when: "拆任务卡" / "PLAN" / "拆成能并行做的卡" / "split into cards" / "task cards" / 契约已 G2 冻结、准备实现之前。NOT for: 写契约（/donewhen-extract）、 写测试（/test-suite-generator）、实现卡（/implement）。前置：`.done_when.lock` 存在（G2 已签）。

补引擎自己给不出的缺口：PR 描述必须呈现的产物序（范围声明 → Closes #N → 变更 → 验证证据 → AC→证据映射 → 风险与回滚 → 审阅焦点），它是 review 阶段判"越界"的基准、是 A 档验收的输入； PR 体量分级与"XL 必拆"的判据；push 前的预检（不在 base 上、与 base 同步、自检绿、提交都合规）—— 全部编译在 verify_pr.py 里。效果：`gh pr create --fill` 变成一个能被机器检、能被 reviewer 按图索骥的 PR。Use when: "发 PR" / "开个 pull request" / "把分支提上去 review" / "create a PR" / "open a pull request" / 引擎准备 `gh pr create --fill` 时。NOT for: 单次 commit （/commit）、跟进 PR 评论（/review-loop）、审别人的 PR（/pr-review）、直接合并（人类动作）。 前置：gh 已认证、在目标仓库内、分支已有至少一个 commit。

补引擎自己给不出的缺口：审 PR 时什么算一条"能落地的发现"（P0/P1 必带复现场景、自我反驳一遍 再发、上限 5 条不凑数、空结果也要给走过的路径）、发现按 A 机械 / B 结构 / C 判断三档归位 （只有 A 档一票否决，B 有界可进，C 请求人工）、以及 Detective Loop（自己决定下一步读什么， 不按清单走）。效果：PR# / ref 范围 / diff 文件 → findings.yaml → 可选发成 GitHub review （行内评论；永不 approve）。Use when: "审一下这个 PR" / "review PR #12" / "看看这个 diff 有 没有 bug" / "code review" / "帮我找问题" / 引擎准备只回"看起来不错"时。NOT for: 需求合规 （/pm-reviewer）、真跑测试（/qa-reviewer）、契约作弊检测（/spec-gaming-detector）、 你是 PR 作者要处理评论（/review-loop）。借鉴 done-when-pipeline `/code-reviewer` v1.0.0。

把一个需求背后的「产品世界」写成完整 PSL（Product Specification Language），并在世界填不满时主动向用户提问， 最终必产出一份完整 PSL。PSL 写「这个世界为什么这样运转」（生成规则），不是「应该造什么」（功能规格）。 Use this skill whenever a requirement is experiential / semantically fuzzy（记忆、人格、关系、内容组织、推荐、 搜索意图、社交动态…），或当你预感 Agent 照字面实现会用默认值把世界填错（典型症状：交出一个「技术正确、产品错误」 的东西，如「按时间搜索」被做成日历筛选器）。也用于判断一个 PRD 该不该改写为 PSL。 触发词：PSL、产品世界、世界建模、把需求写成世界、"这需求 Agent 会不会做偏"、体验说不清、生成规则 vs 功能规格。 NOT for deterministic requirements（支付校验 / 合规字段 / 报表列宽）——那里 PRD 的精确恰好够用，套世界模型是过填。

补引擎自己给不出的缺口：读完一份 PSL 之后，先产三样东西再产代码（DOS 提案 / Workflow / 形态草案）， 且每条形态决策必须引用它从哪条 PSL 规律推出来（PSL-ID 格式硬约束，否则 G1 里"推错了 vs 规律错了" 全靠口头）；以及把"推导不可复现"从残余风险变成信号——N 次独立推导取分歧集，一致的部分是 PSL 真正 约束住的，分歧集就是 G1 的议程。效果：功能级 PSL → derived/{dos-proposal.yaml, workflow.md, form-draft.md, divergence.md}，经 verify_derived.py 机械预门后交 G1 人裁决。Use when: "从 PSL 推 形态" / "推导产物" / "先出形态草案再写代码" / "psl-derive" / "derive the form from the PSL" / "G1 要审什么" / 写完 PSL 之后、建 issue 之前。NOT for: 写 PSL 本身（/psl）、从代码抽本体 （/dos-extract）、写验收契约（/donewhen-extract）、直接实现（那正是本 skill 要拦的）。

目标驱动的多智能体持久化优化系统。融合 Goal-Driven 的 master/subagent 分离架构 与 AutoResearch 的信号设计方法论,实现"独立评估 + 杀死重启 + 棘轮式进步"的 自主迭代循环。 当用户描述一个想要优化/改进/实现的目标时触发此 skill。 触发词包括但不限于：ratchet、棘轮优化、目标驱动、goal-driven、 "帮我持续优化 X 直到达标"、"我想让 X 达到 Y 标准"、 "帮我实现一个 X 并且要通过 Y 验证"、"自动跑到达标为止"。 也适用于：长时间自主编程任务、需要可验证产出的复杂工程任务、 任何需要 agent 持续迭代直到满足明确验收标准的场景。 即使用户只是模糊地说"我想把这个做好"或"帮我优化这个",也应触发此 skill。 与 autoresearch 的区别：ratchet 有独立评估者、自动杀死重启、明确的终止条件, 适合更大规模、更长时间的自主任务。autoresearch 更适合单文件的轻量迭代。

补引擎自己给不出的缺口：把一份还带着未决项的制品（不变量卡、契约、签字版形态草案）从草稿变成**被冻结的法** 的那段仪式——未决项逐条从文件里读出来呈给人（不是凭记忆挑几条）、一条一条当场裁、裁决带姓名与日期写回制品、 再跑一次判据、最后才签；签字要么人自己来，要么以**受委托签署**落地并把人的授权原话写进锁文件。效果：人只回答 「这条怎么办」，不需要记得还剩什么没定，也不需要敲命令。Use when: "冻结这张卡" / "签了吧" / "批准" / "立法" / "ratify" / "freeze the invariant card" / "把不变量定下来" / 抽完不变量或写完契约准备签字时。NOT for: 起草不变量（/invariant-extract）、写契约（/donewhen-extract）、一次交付运行里的 G2（那是 `aidlc_state.py gate g2`， 有 slug 与状态机）。前置：有一份可锁的制品文件、python3 + pyyaml。

补引擎自己给不出的缺口：合入之后到"交付完成"之间的产物序与不可逆动作的门——版本号按 SemVer 从 Conventional Commits 推导、CHANGELOG 条目与 tag 一致、发布说明必须带回滚方案与验证清单、部署后 验证先于宣布完成、逃逸缺陷登记入口在发布说明里可达——由 verify_release.py 检产物。效果：merge sha 进， tag + changelog + release notes + 部署验证记录出。Use when: "发版" / "打 tag" / "写 changelog" / "部署" / "release" / "ship it" / 合入之后。NOT for: 建 PR（/pr）、合并（人类动作）、登记线上缺陷 （/issue --escape，本 skill 只放入口）。前置：merge 已完成，在目标仓库内。

补引擎自己给不出的缺口：把归档目录、账本、逃逸缺陷、发布记录读成"流程病在哪一层"的证据（回流分布、 G1 拦截率、human AC 占比、返工轮次、逃逸缺陷率、豁免数），并把每条发现路由到能改的那一层——PSL 规律 / DOS 修订 / 不变量候选 / AC 收紧 / 路由预算 / skill 的 fix_list——而不是写一篇感想。产物：带日期的基线 + 提案清单，每条提案有去向与验收方式。Use when: "复盘" / "retro" / "这次为什么返工这么多" / "看看流程哪里 出问题" / "度量" / 一个或多个 feature 归档之后。NOT for: 单次 bug 的根因（/adversarial-debugging 类）、 改 skill 本身（skill-evolve 邻居）。前置：`specs/*/` 至少一个归档。

补引擎自身给不出的三个缺口：零 token 的阻塞等待（模型层轮询每次都烧 token）、把 reviewer 评论当"待验证主张"而非指令的裁决判据、以及编译态的循环终止绑定（无终止绑定的自动回帖会与 bot reviewer 无限对喷）。效果：PR 发出后自动跟进 review——逐条评估评论，成立就修复、提交、 回帖并 resolve 该线程，不成立就有理有据回帖、把线程留给 reviewer 定夺——直到 PR 合并/关闭、 获得批准、或预算耗尽。Use when: "盯着这个 PR 的评论" / "自动处理 review comments" / "跟进 review" / "address review feedback automatically" / "PR autopilot" / "review loop" / "把这个改动发个 PR，评论你自己看着处理"。NOT for: GitLab / Gitea（依赖 gh CLI）、只想看或 总结评论（gh pr view 即可）、你是 reviewer 一侧（/pr-review）、只回一条评论（gh api 即可）。 前置：gh 已认证、jq 可用、当前目录是目标 git 仓库。改编自 vana-builder 的 pr-review-loop v0.4.0。

补引擎自己给不出的缺口：把六个环留下的 trace（归档的 state / ledger / trace.jsonl、review-loop 的证据日志与 计数器、ratchet 的 results.tsv）读成"每个环的预算用了几成、哪条路由规则最常升级、review 的 verdict 分布是不是 一边倒"，并把每条发现变成一条**只改 harness 参数**的提案——routing 预算 / 指纹阈值 / MAX_ROUNDS / 隔离等级 / 某 skill 的 fix_list——带证据、预期指标变化、验收方式，产出 diff 或 patch 由人开 PR。它是 LangChain 四层里的 Hill-Climbing Loop："返回箭头伸进去改 agent loop 本身"，但改动先过人审。效果：归档目录进， `tune/harness-proposals-<date>.yaml` + 可 `git apply` 的 patch 出；归档 < 2 个只出基线。Use when: "调一下预算" / "review 是不是太顺了" / "tune" / "这些环的参数该改吗" / "harness 调参" / 每周 cron / retro 之后。NOT for: 改契约或世界（/retro 的提案去向）、改代码（/implement）、改 skill 正文（skill-evolve 邻居）、单次 bug 根因。 前置：`specs/*/` ≥ 2 个归档（少于 2 个只记基线）。