genesis

genesis：Agent 原语架构（设计规范）

架构师角色

此技能规定了设计 Agent 原语模块的规范流程。用于引导大模型的 Markdown 就是代码；设计未经完成，不应编写生产代码。此技能的输出是设计工件，而非完成的模块。后续的独立编码步骤会根据这些工件生成自然语言模块。

何时启用

• 编写新技能、角色范围界定文件、附加范围规则文件或编排器工作流。
• 重构违反 SoC、组合或线程规则的现有模块（例如适合扇出的场景却采用顺序单循环）。
• 跨多个原语模块的横切式重新设计。
• 评审中需要讨论结构（而非领域内容）时。

硬性规则

• 先绘制图表，再编写任何自然语言模块正文。
• 角色推理或此 SKILL.md 中不得出现任何特定于运行框架的语法。运行框架语法仅存在于 assets/runtime-affordances/per-harness/<harness>.md 中，且只在步骤 7 加载。
• 针对多个运行框架的原语，必须先根据 assets/runtime-affordances/common.md 进行设计；如需使用特定运行框架适配器，必须按照 assets/runtime-affordances/portability-rules.md 作出合理声明。
• 步骤 6 的交接包是唯一向后续传递的工件。不得依赖未明确记录的上下文。

流程

   1 intent + scope (+ cost stance, optional cap)
        v
   2 component diagram   <-- load assets/mermaid-conventions.md
        v                    load assets/primitives.md
        v                    load assets/design-patterns.md
        v                    load assets/architectural-patterns.md
        v                    load assets/refactor-patterns.md
   3 thread / sequence diagram
        v
 3.1 tradeoff check       <-- load assets/pattern-tradeoffs.md
        v                    (only if two patterns fit one slot)
 3.2 cost check           <-- load assets/token-economics.md
        v                    load assets/runtime-affordances/model-catalog.md
        v                    (mandatory; mirrors 3.1)
 3.5 composition decision  <-- load assets/composition-substrate.md
        v                    (per-box: inline | sibling | external module)
   4 SoC pass against existing modules
        v
   5 classic + PROSE + LLM-physics compliance check
        v
   6 handoff packet (diagrams + interface sketch + declared targets
                     + module composition table + cost projection
                     + todos)
        v             [PERSIST PACKET to plan store; truth #5]
        v                                      [DESIGN ENDS HERE]
   ----- caller / coder thread takes over -----
   7a portability check
        v                  load runtime-affordances/common.md (always)
   7b draft natural-       load runtime-affordances/per-harness/<x>.md
      language module      ONLY if step 7a flagged a per-harness need
        v                  load module-system-adapters/<tool>.md
        v                  ONLY if step 3.5 declared external modules
        v                  RELOAD plan before each module / spawn
   8 validate against diagrams + lint (PROSE 5-axis, size budget,
     ASCII, coherent unit, portability honored, declared external
     modules wired correctly, cost projection honored)

步骤 1 - 意图 + 范围

用一段话写明面向用户的能力、触发条件和边界（即不做什么）。遵循单一职责原则：如果段落中用“并且”连接了两项不同的能力，就将其拆分为两个设计。

同时起草调度描述，作为此模块 frontmatter 中的 description：注明触发名词和动词、边界，以及预期的调用模式（FORCED | DISCOVERY | BOTH）。这是调度器大模型进行匹配时所依据的函数签名；参见角色的“技能调度”部分。

描述须遵循 MODULE ENTRYPOINT 原语规范中的四条规则（参见 assets/primitives.md——agentskills.io 的优化描述页面是关键依据；请对照实时 URL 核实）：

• 使用祈使表达。将内容写成给 Agent 的指令：“在……时使用此技能”，而非陈述性表达“此技能会……”。
• 优先描述用户意图，而非实现机制。说明用户想要达成什么，而不是技能的内部流程。
• 明确列出间接触发条件。列出此技能适用的场景，即使用户没有直接提及相关领域。描述应积极明确。
• 长度上限为 ≤ 1024 个字符（assets/primitives.md 中 MODULE ENTRYPOINT 的规范硬性限制；超出后会被静默拒绝）。

同时读取运营方的成本立场（frugal / 默认 balanced / quality / unbounded）以及可选的成本预算上限（一次典型运行的美元、令牌或 premium-requests）。立场会影响所选模式；只有设置上限时，genesis 才会因成本原因拒绝（在步骤 6 强制执行）。声明方式参见 references/cost-economics-process.md。

步骤 2 - 组件图（mermaid）

加载：

• assets/primitives.md
• assets/design-patterns.md
• assets/architectural-patterns.md
• assets/refactor-patterns.md
• assets/mermaid-conventions.md

输出一张 flowchart，展示设计使用的所有原语模块，以及这些模块通过链接依赖的其他模块。标明哪些模块已存在、哪些是新增的。为每个模块标注以下类型之一： PERSONA、SKILL、RULE、ORCHESTRATOR、ASSET。

第 3 步 - 线程 / 时序图（mermaid）

生成一个 sequenceDiagram，展示：

• 哪个线程会生成哪些线程（子 Agent 扇出）。
• 父线程在哪里等待（扇入 / 综合）。
• 对共享接收端的任何互锁（单写入者规则）。

模式选择始终按层级顺序执行：

1. 在现有模块图中运行重构模式触发条件（assets/refactor-patterns.md）。 缺少 R1 SPLIT 或 R3 EXTRACT 会扭曲所有下游模式决策。
2. 从 assets/architectural-patterns.md 中选择一个 TIER 3 架构模式。 如果设计形态符合 PANEL、PIPELINE、ORCHESTRATOR-SAGA、STAFFED PLAN、WAVE EXECUTION、 EVENT-DRIVEN 或 RECONCILIATION LOOP，则写明该模式，并逐字继承其反模式。 当意图描述的是一个队列，其中每个项目都在非确定性条件下被推进至终态时， RECONCILIATION LOOP 是正确选择（触发短语：“queue of items”、“for each issue/PR/file”、“drive to terminal state”、 “until green”、“drift correction”、“reconcile”、“sweep the backlog”）；它只需要子 Agent 分派 + 持久状态 + 来自底层机制的完成信号， 无需供应商特有的附加功能。
3. 沿 GoF 轴分解为 TIER 2 设计模式 （assets/design-patterns.md）。ATTENTION ANCHOR（B8）和 PLAN MEMENTO（B4） 对任何非平凡工作都是必需的。
4. TIER 1 习语（assets/runtime-affordances/per-harness/<x>.md） 仅在代码生成时加载（第 7b 步），现在不要加载。

如果设计中有 >=3 个相互独立且无共享状态的视角，但图中显示的是单线程循环，则重新设计：这是扇出机会。 这种形态的默认模式是 FAN-OUT + SYNTHESIZER（B1），实现 PANEL（A1）。

第 3.1 步 - 权衡检查（仅在备选方案存在冲突时）

如果第 3 步发现有两个或更多模式适用于同一位置，则加载 assets/pattern-tradeoffs.md。找到能决定选择的矩阵（幻觉应对措施；门控类型；依据原则； 线程拓扑；综合风格；角色组合；计划持久化；重构触发条件）。选择与要防范的故障模式相符的单元格， 而不是第一个适用的模式。在第 6 步交接包中引用矩阵和对应行， 以便评审者重现这一选择。

如果第 3 步得出了明确无歧义的模式选择，则跳过此步骤。

第 3.2 步 - 成本检查（必需，与 3.1 对应）

加载 assets/token-economics.md 和 assets/runtime-affordances/model-catalog.md。针对每个模块，选择：角色类别（满足能力要求的最低成本选项）； 前缀形态（审查缓存失效因素，应用 B13）；输出量级（扇出中的 L = R5 触发条件）；工具范围（目录 > 20 时使用 B15 或 S7）； 工作流形态（阶段异构 = A12）。

应用第 1 步读取的立场。如果两个成本模式适用于同一位置，则引用 assets/pattern-tradeoffs.md 第 10 节中的成本形态矩阵行。完整流程见 references/cost-economics-process.md。仅当立场为 unbounded 且操作人员拒绝记录成本时， 才跳过第 3.2 步。

对于计划中的每个 task() 生成操作，根据 references/audience-boundary.md 填写 PER-SPAWN DECLARATION TABLE（受众 / 层级 / 简报模式 / 回执模式 / 理由）。默认 INTERNAL = caveman （依据 B14b/B14c）。

第 3.5 步 — 组合决策

加载 assets/composition-substrate.md。对于组件图中的每个框，确定其组合模式并记录理由：

• INLINE 资产，位于此原语内部（内容仅供此模块使用时的默认选择）。
• LOCAL SIBLING 原语，位于同一源代码树中（内容仅在本项目内复用时的默认选择）。放置前请先询问：面向 USER 的包在 RUNTIME 时是否需要此内容？如果不需要（评估场景、贡献者脚本、开发测试夹具），则属于维护者范围——将其放在面向用户模块的分发边界之外（仅供贡献者使用的目录）。否则，模块会产生 BUNDLE LEAKAGE（参见 composition-substrate.md 中的反模式）。
• 通过项目模块系统引入的 EXTERNAL MODULE（当内容至少满足以下一项时的默认选择：三项目规则——在 3 个或更多项目中需要；发布节奏独立；由不同团队负责；受益于在多个使用方之间固定版本）。

然后绘制一个 flowchart LR 依赖图，展示此模块及其声明的外部模块，以及所有能指出的传递闭包边。为每条边标注组合模式。

对于每个输出的产物，按照 composition-substrate §7 AUDIENCE BOUNDARY 指明受众。INTERNAL → 简略表达（B14b/B14c）；EXTERNAL → 普通行文；合成器在边界处展开内容。

如果声明了任何外部模块，则需要满足以下两点。(1) 交接包 MUST 在“external modules required”项下列出该模块，以便编码步骤（7b）加载模块系统适配器。(2) 依赖该模块的输出模块 MUST 在其自身的分发界面声明此依赖——否则模块会产生 PHANTOM DEPENDENCY，下游加载器无法提供适配器。所选的声明机制记录在交接包（第 6 步）中，可采用以下方式之一：

• 清单中的依赖项；当输出模块通过支持依赖项的模块系统分发时使用；
• 在 SKILL.md / README 正文中推荐配套模块，且在使用位置进行工具调用探测（与此技能在自身的 7b 步骤中针对模块系统适配器采用的 A9 SUPERVISED EXECUTION 流程相同）；
• 两者兼用；当模块系统支持清单依赖，且输出模块也会独立分发给不使用该模块系统的用户时。

步骤 4 - SoC 检查

检查组件图中的每个模块（现已标注步骤 3.5 中的组合模式）：

• 是否已有模块可以完成此工作？如果有，通过链接依赖它；不要重复实现。如果现有模块位于本项目之外，将其标记为 EXTERNAL MODULE，并重新检查步骤 3.5。
• 此模块与同级模块的触发条件是否重叠？如果重叠，重新划分边界。
• 此模块的分发描述是否与已安装的同级模块的描述冲突？如果冲突，缩小其中一个模块的范围，或将其合并。（DISPATCH COLLISION；严重性：HIGH。）
• 此模块的正文是否触发任何 R1 SPLIT 条件（描述包含多个合取项、调用方分散、正文超出预算、多视角正文、变更节奏不同）？如果触发，按 R1 重新设计。如果没有触发任何条件却仍然拆分，则标记为 PREMATURE SPLIT。
• 此模块是否始终与同级模块一起加载，且其存在仅体现为一段简短正文？应用 R2 FUSE。
• 正文是否内联了应放在独立 persona / 规则 / 资源文件中的内容？应用 R3 EXTRACT。
• 是否存在只有一个调用方和一个引用的薄代理原语？应用 R4 INLINE。
• 正文是否提及 CONSEQUENTIAL SIDE EFFECT（应用、更改、发布、部署、迁移、修改状态）或 FACT THAT MUST BE TRUE（当前状态、版本、哈希、文件内容），并将其留作由 LLM 断言的文字？如果是，该步骤 MUST 经过 S7 DETERMINISTIC TOOL BRIDGE；根据 S7 的选择规则选择 EXTENSION PATH（预加载的终端、自定义 CLI/脚本/API，或 MCP 服务）。如果已安装的 CLI 能完成工作，默认使用预加载的终端。如果工作涉及计划 + 执行 + 验证，则使用 A9 SUPERVISED EXECUTION 封装。 完整触发条件集见 assets/refactor-patterns.md。

步骤 5 - 合规性检查

逐条应用 persona 的经典原则表；为违规项标记严重性（BLOCKER / HIGH / MEDIUM / LOW）。然后应用 PROSE 约束（渐进式披露、缩小范围、编排式组合、安全边界、明确层级）以及七条持久有效的大模型事实。任何 BLOCKER 都会阻止设计；返回步骤 2。

同时确保符合 MODULE ENTRYPOINT 规范中的合规性条目（任何不符合项均为 BLOCKER；请对照 assets/primitives.md 中链接的实时规范进行核验）：

• name 字段长度为 1-64 个字符，仅包含小写 [a-z0-9-]，不得以连字符开头或结尾，也不得包含连续连字符，且必须与父目录名称相同。不匹配 = harness 拒绝该模块。
• SKILL.md 正文不超过 500 行且不超过 5000 个 token。超出内容不得保留在正文中；应移至 references/<topic>.md，并在正文中通过明确的 LOAD TRIGGER 条件链接到该文件（例如：“如果 API 返回非 200 状态码，请阅读 references/api-errors.md”），而不是使用笼统的“参见 references/”。

Step 6 - 交接包（这就是计划；请持久化）

生成一个包含以下内容的单一制品：

• 组件图（步骤 2）。
• 线程／时序图（步骤 3）。
• 依赖关系图（步骤 3.5）。
• 每个模块的简短接口草图：名称、触发说明、输入、输出、依赖项（使用相对链接）。
• 模块组成表：逐个方框标明 INLINE | LOCAL SIBLING | EXTERNAL MODULE，并说明理由。
• 所需外部模块列表（用于决定步骤 7b 是否加载模块系统适配器）。对于每个外部模块，还要记录在步骤 3.5 中选定的 DECLARATION MECHANISM（manifest dep | companion-module recommendation + tool-call probe | both）。 用于步骤 8 验证生成的模块是否带有 PHANTOM DEPENDENCY。
• 声明的目标集：common-only | <list of harnesses>。
• 每个模块的预期调用模式：FORCED | DISCOVERY | BOTH。（用于决定描述冲突审查需要多严格。）
• 仍未解决的合规性问题（含严重程度）。
• 待办事项列表（每个待起草模块一项，另加验证），并注明各项之间的依赖关系（如有）。
• 按照 references/audience-boundary.md 模板提供 PER-SPAWN DECLARATION TABLE、SPAWN_BRIEFS、RECEIPT_SCHEMAS 和 EXTERNAL_ARTIFACT_SPEC。
• HUMAN_RATIONALE 部分，包含完整说明性文字；标记为 NEVER copied into any SPAWN_BRIEF。
• EVALS PLAN（MODULE ENTRYPOINT 基元 evaluating-skills + optimizing-descriptions 的规范；参见 assets/primitives.md）。至少包括：
  • 2-3 项 CONTENT EVALS：提示词 + 预期输出，分别在加载技能和未加载技能时各运行两次，以便清晰呈现价值差异。如果 with_skill 和 without_skill 产生的输出无法区分，说明该技能没有带来价值；应重新设计或删除。
  • 约 20 项针对分派描述的 TRIGGER EVALS：8-10 个应触发的查询，以及 8-10 个不应触发的近似查询，按 60/40 划分训练集／验证集。验证集是发布门槛。
• COST PROJECTION（除非选择 unbounded + opt-out，否则必须提供）。 包含：各模块的定性区间（角色类别、前缀／输出区间、轮次／缓存比）；工作流层面的定量范围（输入／输出 token 数、每次代表性运行的美元范围），数据来源为各 harness 适配器的定价脚注；三种工作负载场景（S 简单／M 已知模块／L 全仓库）；引用的成本形态矩阵行；声明的立场；上限检查（如果 L 场景超出上限，则停止）。区间是 CONTRACT（步骤 8 会验证）；范围是 PREDICTION（由操作者查阅）。 完整模板见 references/cost-economics-process.md。

持久化此交接包。根据 truth #5（先计划后执行）和 substrate concept 6（计划持久化），交接包 MUST 在步骤 7b 开始之前写入运行时的计划存储区。 具体位置因 harness 而异（参见 runtime-affordances/per-harness/<x>.md -> 第 6 节）；substrate 保证每个受支持的 harness 都有一个存储位置。如不确定，请将其写入会话工作区中名为 plan.md 的 Markdown 文件；此方式可移植。

设计到此结束。停止。不要起草自然语言内容。

Step 7a - 可移植性检查（调用方）

调用方加载 assets/runtime-affordances/common.md。对交接包中的每个模块，检查其所需的所有能力是否都包含在通用 substrate 中。

如果是 -> 声明目标 = common-only；继续步骤 7b，仅加载 common.md。

如果否 -> 查阅 assets/runtime-affordances/portability-rules.md。 要么论证为何要调用特定 harness 适配器（并在模块头部声明该限制），要么重新设计以适配通用 substrate（返回步骤 2）。

Step 7b - 起草自然语言模块（调用方侧）

使用已加载的底层结构（以及在有依据时使用各执行环境适配器）， 输出每个模块的正文。这是唯一会接触 当前语法的步骤。

在起草每个模块之前、每次启动之前， 以及每次启动返回之后，重新加载计划。第 6 步中保存计划， 正是为了让执行者能重新建立依据，而不依赖 已经退化的记忆（真理 #1、底层结构概念 6、模式 B4 PLAN MEMENTO + B8 ATTENTION ANCHOR）。 每个模块完成后更新待办列表。

如果交接包在“所需外部模块”下声明了任何 EXTERNAL MODULE， 则必须先加载 MODULE-SYSTEM ADAPTER，才能输出清单、CLI 或锁文件内容。 该适配器负责这些语法；架构师角色对此一无所知。当前 规范适配器是 apm-usage（microsoft/apm-guide）；以后也可能 出现或编写其他适配器。

在此处应用 A9 SUPERVISED EXECUTION ——适配器可用是一个必须为真的事实 （真理 #2 CONTEXT EXPLICIT + 真理 #6 HARNESSES BRIDGE）。不要跳过探测； 否则就会出现 PHANTOM DEPENDENCY 故障模式。

1. 通过工具调用进行探测：列出已安装的技能 / 检查 配套技能注册表 / 检查项目根目录中是否存在 清单。不要仅凭文字描述就假设适配器已加载。
2. 探测命中 -> 加载适配器，然后起草模块正文，将清单 / CLI / 锁文件 相关词汇交由适配器处理。
3. 探测未命中 -> 在输出任何模块正文之前询问操作人员。 提供以下三个选项：
   • 安装规范适配器： apm install microsoft/apm/packages/apm-guide （然后重新探测）。
   • 原始文件备用方案：仅输出基础文件夹，不输出清单； 显示明确的“你必须手动将这些文件接入模块 系统”提示，避免让操作人员措手不及。
   • 指定要加载的其他适配器句柄。
4. 绝不根据 LLM 记忆输出 apm.yml、package.json 或任何具体清单字段。 要么由适配器提供相关词汇（探测命中），要么由操作人员选择 原始文件备用方案。否则，故障链将是 TOOLLESS ASSERTION -> HAND-ROLLED HALLUCINATION -> silent drift。

任何捆绑内容都使用规范目录布局（assets/primitives.md 中链接的 MODULE ENTRYPOINT 规范是事实来源；请核实其内容是否有变更）：

• scripts/ - 由技能正文通过 相对路径调用的可执行程序。必须为 NON-INTERACTIVE（Agent 在 没有 TTY 的 shell 中运行；任何提示都会无限期阻塞）。为一次性命令固定 工具版本（例如 npx [email protected]）。使用 --help 编写文档。 在 stdout 上输出 STRUCTURED data（JSON / CSV），在 stderr 上输出诊断信息。 在 SKILL.md 正文中列出捆绑的脚本，方便 Agent 查找。
• references/ - 按需加载的文档。正文中的每个链接都必须 说明触发加载该文档的条件（见第 5 步）。
• assets/ - 技能输出或据以组合内容的模板和数据。

按各部分调整指令的严格程度：对脆弱或有先后顺序的操作给出明确指令； 对需要判断的事项保留自由度。全文都采用明确指令会过度限制； 全文都不作限制则会缺乏依据。优先采用流程（如何处理一类问题）， 而非声明（针对单个实例要产出什么）。 对于技能必须生成的任何结构化输出，都要内嵌一个模板—— 相比文字说明，Agent 更容易依据具体结构进行模式匹配。

步骤 8 - 验证（调用方侧）

• 每个生成的模块都符合交接包中的接口草图。
• 遵守基底指定的令牌数 / 行数预算（SKILL.md 正文 <= 500 行且 <= 5000 个令牌；溢出内容移至 references/）。
• name 字段符合正则表达式，且与父目录匹配。
• description <= 1024 个字符，以祈使句表达、意图优先，并命名间接触发条件。
• 仅限 ASCII。
• 单一职责，构成连贯的单元。
• 遵守声明的目标：common-only 模块不得泄漏任何特定运行环境的语法。
• 对于交接包中列出的每个外部模块，生成的模块都必须通过步骤 6 记录的机制，在其分发层面声明依赖（清单条目 / 配套模块建议 + 使用位置的工具调用探测 / 两者兼有）。仅在文字中提及依赖句柄不算声明——这是虚假依赖（见架构师反模式）。
• 随附脚本必须是非交互式的、版本固定的、有 --help 文档，并且 stdout/stderr 分流。
• 评估门槛（来自步骤 6 的评估计划）：
  • evals/evals.json（或等效文件）必须存在，并已针对 with_skill 与 without_skill 进行测试。如果没有可衡量的差异，则重新设计或删除——不要发布。
  • 触发评估验证拆分必须通过：应触发查询的比率 >= 0.5，且不应触发的近似查询的比率 < 0.5。
• 成本检查清单（来自步骤 6；由人工执行，不是 lint 脚本）： 每个生成模块的角色类别都符合投影区间；没有引入缓存失效因素；每种引用的成本模式都在某个模块中落地；存在立场要求的模式（frugal -> B12 / B15 / B16；quality -> 规划器类别晋升）；仍符合上限。失败项属于高严重性，但不会阻止发布——它们会显现出来，供操作员接受或重新设计。完整流程见 references/cost-economics-process.md。
• 受众边界：必须存在逐次生成声明表；内部行使用简短直接的表述，或给出合理例外；SPAWN_BRIEF 必须与 RECEIPT_SCHEMA 配对；外部规格必须使用普通文本声明。
• 真实任务迭代：结构 lint 通过后，至少在一个真实任务上运行该技能，捕获执行轨迹，并根据实际发生的情况（而非预期）进行修订。未经实际执行的一次性草稿还不算完成。

默认模式选择

如有疑问，选择能最大限度减少单个线程中上下文退化的模式：

• 1 个视角、1 个流程 -> 单循环顺序模式。

• =3 个相互独立的视角、无共享状态 -> 扇出 + 综合器。

• 2 个存在顺序依赖的视角 -> 单循环顺序模式，并在两者之间设置验证门槛。
• 跨会话的长时间运行工作 -> 使用在各阶段之间持久化产物的编排器。

设计模式目录（GoF 轴）见 assets/design-patterns.md，架构模式（系统拓扑形态）见 assets/architectural-patterns.md。

如果设计包含 ≥1 个 task() 生成任务，请在起草交接包步骤 6 前加载 references/audience-boundary.md。

实例

实例文件与此 SKILL.md 文件一起存放在 examples/ 中，而不在 assets/ 中。它们是惰性加载的：仅当操作人员明确要求查看实例，或设计步骤需要参考样例时才加载。适用于资源的渐进式披露规则不适用于实例；不要提前加载。

• examples/01-readme-iteration.md -- 适用于任何注重冷流量转化且目标偏移风险确实存在的创意型多轮产物工作的规范样例（README、落地页、PR 描述、公告帖）。组合了 A8 ALIGNMENT LOOP + A1 PANEL + A7 ADVERSARIAL REVIEW + COLD READER SIMULATION + B9 GOAL STEWARD + B10 HUMAN CHECKPOINT。
• examples/02-review-panel-architecture.md -- 适用于任何多视角模块（评审面板、审计、多视角批评）的规范架构重构教程。演示了一个真实评审面板如何从单循环反模式改造成扇出 + 父级综合器。
• examples/03-release-notes-single-skill.md -- 最小输出参考：A1 PANEL 不适用时（未触发视角数量门槛）。A9 SUPERVISED EXECUTION + S7 + S4，单线程。
• examples/04-pr-review-advisory.md -- 多原语评审面板参考：A6 EVENT + A1 PANEL + DISSENT-WEIGHTED 仲裁器；除发布评论外，不对记录系统产生副作用。
• examples/05-pr-review-verdict.md -- 影响重大的写入参考：在 04 的同一评审面板基础上增加裁决输出。展示了 S7 + S4 + A9 验证器加固，并明确依据 WHEN 子句拒绝 A8 / B5 / R1——当利害压力诱使你添加新的编排层时，请阅读此例。
• examples/06-cost-aware-panel.md -- 成本结构参考：在实例 02 的评审面板上加入 A12 GRADIENT WORKFLOW + B12 MODEL ROUTER + B13 CACHE-AWARE PREFIX + R5 COST PRUNE 流程。当立场为 frugal，或扇出宽度 >= 4 且按日运行时，请阅读此例。

输出

设计会话会产出：

• 交接包（“第 6 步”），与其设计的模块一同提交，或作为引入这些模块的 PR 评论发布。
• 自然语言模块正文（在第 7b 步起草）。

交接包是未来任何重构的事实依据：重新运行此技能时，应从交接包开始，而不是从已生成的自然语言开始。