当代理根据规范工作时有什么变化。这就是 Agent Smith 每天的构建方式，涵盖一千多个规范。核实 新的审查者在构建之前检查规范与代码是否一致。一个门在提交之前运行检查。并行 每个规范一个分支和工作树。唯一标识符来自时钟，因此两个代理从不获取相同的标识符。不中断 一个经过审核的规范已经回答了所有未解的问题，因此代理根据完成标准构建，而不是回来询问。结构化 一个规范，一个分支，一个提交。拉取请求携带一个规范或整个系列，且每个更改具有相同的结构。可恢复 状态保存在 context.yaml 中。重新启动机器或代理，工作从停止的地方继续。解释，作为副作用 每个选择都记录了其胜过的情况和原因，因此推理与代码并肩存在。一个完整的系列，肩并肩 将较大更改拆分为一系列规范。/spec-first:deliver-series 同时审核所有规范，构建没有共享文件的组，验证合并的树并打开一个拉取请求。deliver-series 2026-10-27-8a3f 5 个规范 · 3 个组构建 tickets-provider-contract 不需要任何 1 b tickets-github-provider 需要一个 1 c tickets-jira-provider 需要一个 1 d settings-provider-page 不需要任何 2 e ci-restore-cache 不需要任何 3 3 个工作树并行构建 · 每个规范通过门的提交 PR #42 /spec-first:deliver-series 的示例运行。没有共享文件的规范同时构建；彼此依赖的规范共享一个组。从想法到拉取请求的一个规范 四项技能通过其自己的分支和工作树完成一项工作。每个技能为下一步和以后阅读历史的人留下一个文件。create-spec 目标、步骤、文件和行的事实，完成的定义。尚无代码。specs/planned/{id}.yaml review-spec 每个引用都已解决，然后一位从未看到聊天的审查者对其进行攻击。构建 · 切割 · 拒绝 apply-spec 合同、代码、布线、测试，遵循项目自己的规则。decisions/{id}.yaml deliver-spec 通过门的一个提交，推送，拉取请求已打开。feat: … ({id}) 每个规范的记录随着每个步骤而增长，在每一步之前阅读规范/specs/ 从计划到完成的每个规范，包含其事实和完成标准。decisions/ 每个规范的选择、相比之下的选择及原因。memory/ 你告诉代理一次的事情，以便你不再说第二次。/spec-first:bootstrap-project 从你的代码中写入上下文：栈、规则和提交必须通过的检查。之后，每个规范添加一行状态。审查之前，规范不会被任何人构建 一次拒绝让你损失一个规范。如果没有审查，同样的错误将让你损失整个分支。规范 2026-10-27-8a3f 适用于服务器 分支 spec/8a3f 目标 票务提供者，以便管道可以从 GitHub 和 Jira 拉取工作。读取代码的事实 管道今天仅从 CLI 中获取工作 Program.cs:40-58 配置已经携带跟踪器部分 AppConfig.cs:12-19 决策 适配器通过存储库：只读数据，无需工作单元。完成的条件是 GitHub 提供者端到端返回票据。Jira 提供者通过相同接口验证：阶段为绿色 审查通过 · 新审查者构建 · 27 OCT review-spec · 2026-10-27-8a3f 2 切割 ✓ src/Host/Program.cs:40-58 解决 ✓ src/Config/AppConfig.cs:12-19 解决 证据解决：1 规范 构建与切割 该规范在一旦两个步骤发生更改时保持 CUT 1 步 jira 需要第二种身份验证模式，而配置尚不能容纳。AppConfig.cs:15 移动到其自己的规范。CUT 2 缓存缺失：GitHub 每页返回 30 个问题。GitHubClient.cs:88 添加完成标准。每个引用都被检查一个脚本打开每个文件和规范引用的行。一个没有人检查过的声明必须列为假设。审查者重新开始 一位没有对话历史的新代理读取代码的原样，而不是规范所说的样子。一个判决，带有名为构建、构建与切割或拒绝的切割，每个发现都指定一个文件和一行。推理随之而来 没有人必须在之后写文档。在构建过程中，代理记录每个不明显的选择：它选择了什么，超越了什么，原因是什么。每个规范一个文件，紧挨代码。decisions/2026-10-27-8a3f.yaml 规范：2026-10-27-8a3f 决策：- 类别：权衡 选择：