软件工厂 (Software Factory)
先消除所有范围疑问。冻结义务。将每个繁重阶段委托给全新的子智能体。由未编写代码的独立验证器证明完成。
┌──────────┐ ┌──────┐ ┌────────┐ ┌───────┐ ┌────────┐
│ 发现阶段 │ → │ 规划阶段│ → │ 检查阶段│ → │ 构建阶段│ → │ 验证阶段│
└──────────┘ └──────┘ └────────┘ └───────┘ └────────┘
0 个疑问 确认 义务 批次 作者 != 验证者
五步动作，三个持久工件位于 .specs/features/<feature>/ 下，以及一个主聊天中薄编排器，永不让其上下文窗口膨胀。
- 发现 (DISCOVER)：一个只读的
scout子智能体扫描代码库，返回一个紧凑的（约30行）歧义简报。主聊天用具体选项和推荐默认值采访用户，直到零个未确认的假设（每行Confirmed? y）。参见 discovery.md。 - 规划 (PLAN)：一个
planner子智能体编写.specs/features/<feature>/plan.md（问题、流程、影响、关系、界面、落地、标准、范围外、假设、可观察项、来源）并运行validate_plan.py。用户在plan.md上快速签署。参见 plan.md。 - 检查 (CHECKS)：在
plan.md签署后，自主后规划循环开始。一个specifier子智能体生成.specs/features/<feature>/checks.md（声明+证明、覆盖率连接、测试策略、清扫范围、交接算术）并运行validate_checks.py。参见 checks.md。 - 构建 (BUILD)：每个切片/批次一个
builder子智能体严格按照检查编写测试，实现代码，运行证明，更新checks.md，并使用check_commit.py提交。参见 build.md。 - 验证（与修复循环）(VERIFY and FIX loop)：一个独立的
verifier子智能体（决不是构建者）审计<特性基准>..HEAD对每一项检查，编写.specs/features/<feature>/verification.md，并运行validate_verification.py。如果任何检查失败，一个fixer子智能体解决排名差距，然后一个新的verifier重新验证（最多3轮）。参见 verify.md 和 orchestration.md。
为何采用这种形式
编码智能体在复杂特性上因两个可预测的原因而失败：
- 上下文窗口膨胀：当单个聊天会话探索仓库、采访用户、编写计划、派生检查、编写测试和代码，并验证自身工作时，上下文窗口会填满并触发有损压缩。
- 未确认的需求与自我审查盲点：默默地猜测产品行为（
Confirmed? n）或让作者自我认证完成会传递作者自己的盲点。
software-factory 解决了这两个问题：
- 薄编排器（主聊天中<15k tokens）：主聊天严格担任协调者和用户采访者。所有代码库读取、工件创作、编码、测试和验证都在隔离的临时子智能体（
scout、planner、specifier、builder、verifier、fixer）中运行，这些子智能体仅通过磁盘上的.specs/features/<feature>/文件和 git 提交进行通信。完整调度协议：orchestration.md。 - 小且冻结的义务集 + 独立验证器：没有细粒度的任务清单或组件目录（每个类的
Purpose/Location/Interfaces）会过时。单向门在Landing中获得字面形状；可逆放置根据差异决定。
关键规则
固定集。这些规则在每个配置中都适用：
- 零未确认假设（
Confirmed? y）。永远不要默默地猜测产品或范围行为。DISCOVER期间出现的每个灰色区域都必须用具体选项和推荐默认值询问，或由用户明确委托（Confirmed? y）。validate_plan.py拒绝任何Confirmed?为n或空白的行。 - 薄编排器 & 严格的每阶段单子智能体边界（
scout!=planner!=specifier!=builder!=verifier）。保持主聊天在~15k tokens 以下。切勿将两个阶段合并到单个子智能体调用中：scout仅探索并返回约30行的歧义简报。planner仅编写plan.md+ 运行validate_plan.py，然后停止并退出。specifier仅编写checks.md+ 运行validate_checks.py，然后停止并退出（它绝不能编写测试文件或实现代码，或继续进入BUILD）。builder仅在specifier返回后运行。对于多切片特性（S1、S2、...），按顺序调度每个切片一个独立的builder子智能体，以便每个切片在一个新的上下文窗口中执行并向用户报告进度。verifier仅在最终builder提交后在一个全新的子智能体中运行。
- 每个检查是一个可观察的声明，具有具体值和证明——确切的测试选择器或命令，其退出代码解决了该检查。没有证明，就没有检查。
- 测试断言检查所说的内容，而不是代码恰好所做的。切勿通过读取实现来编写测试。
- 切勿削弱断言、删除测试或跳过测试以使测试套件通过。一个真正错误的检查是停下来询问，而不是编辑。
- 检查和
Test policy行一旦批准即固定。在plan.md中，Landing、Relations和Surface是加法性的——在构建时发现的门会在关闭它的代码之前获得一行，而用户批准的行永远不会被重写。Flow和Impact在改变路径的提交中保持真实。 - 验证器是一个全新的子智能体，绝不是作者，绝不是可选的，绝不需要等待被询问。编排器在特性的最后一个提交落地到
<特性基准>..HEAD且每个检查通过后立即调度它。 - 配置是底线，并由
validate_verification.py强制执行。 - 完成门控是脚本，而不是感觉：
validate_verification.py必须退出码为0。 - 爆炸半径： 已批准的规范授权本地编辑和本地提交。
git push、部署和生产数据更改需要对该操作的明确批准。
配置
项目在 AGENTS.md 或等效文件中声明运行多少内容。若无声明：light。
## software-factory
profile: light
budget: 150k
| 配置 | 增加内容 | 无法捕获 |
|---|---|---|
light (默认) | 证明在 HEAD 运行，每个命名测试显示存在并运行，每个检查一个定位断言，级别和采样差距，Swept existing 重新读取 | 没有证明的集合成员；在错误实现下会通过的测试 |
standard | 重新计算 Coverage 连接，Test policy 行带有各自的结论，每个断言表面一个故障 | 与绑定源矛盾的检查；没有人构建的屏幕 |
ui | 打开并比较绑定源，逐个屏幕枚举文案和布局 | 仅间距、颜色和类型粗细，逐个屏幕枚举 |
validate_verification.py 拒绝配置与批准 checks.md 时不同的报告，拒绝没有故障行或没有重新计算覆盖率的 standard 报告，拒绝没有绑定源部分的 ui 报告。
工件
.specs/
├── STATE.md # 决策日志 (AD-NNN) + 交接快照
├── LESSONS.md # 由 scripts/lessons.py 渲染 - 绝不手动编辑
├── lessons.json # 机器拥有
└── features/<feature>/
├── plan.md # 问题、流程、影响、关系、界面、落地、标准、假设（全部 y）、可观察项
├── checks.md # 声明+证明、覆盖率连接、测试策略、清扫范围、交接批次
└── verification.md # 独立验证器的报告
在其阶段产生内容时创建每个文件。对于大约三个文件以下且没有单向门且零范围歧义的更改，仅编写带有 ## Intent 段落的 checks.md 并跳过 plan.md。
plan.md 中的五个有界设计部分
| 部分 | 审查内容 | 排除内容 |
|---|---|---|
Flow | 路径，每跳一行 | 任何既不存在也未由门创建的模块——那是放置 |
Impact | 底层变化：术语和现有数据 | 风险登记册 |
Relations | 实体、基数、单向约束 | 列和类型 |
Surface | 路由、输入、输出、状态 | 请求体规范和检查 ID——那些还不存在 |
Landing | 单向门，带有字面形状和被拒绝的替代方案 | 任何重构可以逆转的东西 |
流程
- 发现 (Discover) — 调度只读的
scout子智能体检查仓库、.specs/STATE.md和.specs/LESSONS.md，并返回约30行的歧义简报。引导用户解决真正的产品和范围灰色区域（每轮最多2个问题，具体选项和推荐默认值），涵盖Observable表面和9个隐含维度，直到0个疑问：discovery.md。 - 规划 (Plan) — 调度
planner子智能体，将确认的发现决策传递给编写.specs/features/<feature>/plan.md并通过validate_plan.py。向用户展示plan.md以快速签署：plan.md。 - 检查 (Checks) — 一旦
plan.md获批，自主运行。调度一个专门的specifier子智能体生成本节.specs/features/<feature>/checks.md（声明+证明、Coverage连接、Swept和## Handoff批次大小调整）并通过validate_checks.py，然后在编写任何代码或测试之前终止该子智能体：checks.md。 - 构建 (Build) — 在
specifier完成后，按顺序为每个切片（S1、S2、...）调度一个全新的builder子智能体。每个构建者从检查中为其分配的切片编写测试，实现，运行证明，在checks.md中记录Boundary，使用check_commit.py提交，然后退出：build.md。 - 验证与修复 (Verify & Fix) — 调度一个全新的
verifier子智能体覆盖<特性基准>..HEAD以编写verification.md并运行validate_verification.py。如果失败，调度一个fixer子智能体并重新验证（最多3轮）：verify.md。 - 编排与子智能体调度 (Orchestration & Subagent Dispatch) — 薄编排器规则、上下文窗口预算和多智能体映射（
antigravity、claude、codex）：orchestration.md。 - 持久记忆 (Durable Memory) — 项目决策 (
STATE.md)、会话交接和基于验证的经验教训 (lessons.py)：memory.md。
脚本
将 <skill-dir> 解析为包含此 SKILL.md 的目录，并调用 python3 <skill-dir>/scripts/<name>.py。当当前工作目录与项目根目录不同时，传递 --root。非零退出码表示停止并修复。
| 时机 | 命令 |
|---|---|
| 检查流水线阶段和下一个子智能体角色 | orchestrate.py status <feature> --root <dir> |
| 生成隔离子智能体提示 | `orchestrate.py prompt --role <scout |
| 通过编排器运行阶段门控 | `orchestrate.py gate --phase <plan |
通过 CLI 调度子智能体（或 --dry-run） | `orchestrate.py dispatch --role --agent <antigravity |
在展示 plan.md 之前 | validate_plan.py <feature> |
在开始 BUILD 之前 | validate_checks.py <feature> |
| 每次提交之前 | check_commit.py --message "<msg>" |
| 在声明完成之前 | validate_verification.py <feature> |
| 在提炼时 | lessons.py add ... |
| 在编辑了验证器、脚本或模板之后 | selftest.py |
子智能体与交接
每个阶段严格隔离在自己的子智能体调用中（scout -> planner -> specifier -> builder [S1] -> builder [S2] -> ... -> verifier -> fixer）。切勿在同一子智能体中组合 specifier（CHECKS）和 builder（BUILD）。在 BUILD 期间，当特性有多个切片（S1、S2、...）时，按顺序为每个切片调度一个独立的 builder 子智能体，以便每个构建者从一个干净的上下文窗口开始，快速完成，在其切片变绿时提交，并向薄编排器返回进度更新。
当最终的构建者切片返回绿色时，编排器立即在同一轮次中调度独立的 verifier 子智能体，无需询问用户。
知识链
严格按照顺序：现有代码和约定、项目文档、库文档（Context7 可用时）、网络搜索，然后标记为不确定。切勿发明 API、标志、命令或行为。
输出行为
生成工件；不要叙述阶段。以结论开头。果断陈述决策。去除填充和机械性犹豫。保持部分标题为英文（它们是门控验证的模式）。