horde-templates

用途

Horde 模板是带版本号的 TOML，编译后形成依赖图，用来把一个目标拆解为多个相互依赖的步骤。Horde 会把模板的内容哈希和展开后的计划固定到每个使用它的任务上，因此任何结果都能追溯到产生它的确切工作流。

模板位置与内置模板

项目模板位于 .horde/templates/*.toml，可以增补或覆盖内置模板。内置模板包括：local-implementation（规划、实现、评审）、nextjs、github-actions 和 simulated。

校验

提交前务必校验，成本为零且能捕获所有结构性错误：

horde validate my-template --repo /path/to/repo horde validate my-template --repo /path/to/repo --objective "a realistic objective"

模板结构

以下示例取自资料：

name = "parallel-feature" version = "1.0.0" inputs = ["task"]

[outputs] result = "verify.result"

[[steps]] id = "api" role = "worker" scope = ["src/api"] tools = ["read_file", "search", "write_file", "apply_patch", "command"] instructions = "Implement the API for {{task}}. Coordinate interfaces with the UI worker, test and commit." acceptance = ["The API endpoint exists and its tests pass"]

[[steps]] id = "ui" role = "worker" scope = ["src/ui"] tools = ["read_file", "search", "write_file", "apply_patch", "command"] instructions = "Implement the UI for {{task}}. Coordinate interfaces with the API worker, test and commit."

[[steps]] id = "verify" kind = "command" needs = ["api", "ui"] command = ["npm", "test", "--", "--run"]

未知键在加载时是硬错误。缺失输入、重复步骤 id、指向不存在步骤的 needs、依赖环，以及模板包含自身，也都是硬错误。

步骤字段

id：必填，模板内唯一
kind：默认 agent，可选 agent、command、delivery、environment、simulated
role：默认 worker，执行者角色，必须存在于设置中的 [executors.<role>]
instructions：默认 ""，agent 步骤的提示词；{{input}} 和 ${step.output} 会被替换
acceptance：默认 []，判定步骤的验收标准，写法应使失败可被检测
needs：默认 []，依赖的步骤 id
scope：默认 []，写入范围；["."] 表示整个仓库
tools：默认 []，agent 步骤可用的原生工具白名单
artifacts：默认 []，预期产物名称
output_types：默认 {}，具名 JSON 输出及其类型，在完成时强制校验
command：默认 []，command 步骤的 argv
environment：默认 none，environment 步骤的受管应用环境块
template：默认 none，要调用的嵌套模板
inputs：默认 {}，传给嵌套模板的输入
when：默认 none，基于依赖终态的条件 { step = "...", status = "..." }
attempts：默认 1，有界重试；每次尝试保留独立证据

在 Tuara 执行器上，agent 步骤可用的原生工具为：read_file、search、write_file、apply_patch、command。

替换

{{name}} 替换模板输入。{{task}} 是提交的目标。

${step.field} 提供直接依赖的具名输出。引用不依赖的步骤会被拒绝。

嵌套模板会为其步骤建立命名空间，编译器生成的引用和输出别名会在校验前重写。

并发

依赖已满足的步骤在其写入范围允许时并发运行。写入范围前缀不重叠的两个 worker 会获得独立工作树并同时运行；前缀重叠则串行化。

范围不能替代声明（claims）。worker 若需要其范围外的共享文件，必须先获取声明，或请当前持有者转移。

循环

DAG 环会被拒绝。迭代来自两种明确机制：

attempts = N 将步骤最多重复 N 次。
when 失败分支先做修复，再进行另一次验证。

示例：

[[steps]] id = "check" kind = "command" command = ["cargo", "test"] attempts = 2

[[steps]] id = "repair" role = "worker" needs = ["check"] scope = ["."] tools = ["read_file", "search", "write_file", "command"] instructions = "Read the failed check evidence in context, fix the cause, test, and commit." [steps.when] step = "check" status = "failed"

[[steps]] id = "verify" kind = "command" needs = ["repair"] command = ["cargo", "test"]

如果 check 成功，repair 被跳过，其依赖者也一并跳过。如果失败，repair 和 verify 都必须成功。可由实现改动修复的验证步骤应始终配有显式的修复分支；Horde 不会替你构造无界修复循环。

角色回退

[fallbacks] worker = "reviewer"

当 attempts = 2 时，第一次尝试使用 worker，第二次使用 reviewer。回退是选择启用的、会做环检查的，并记录为升级事件。这是经配置的执行者变更，而非静默的模型别名。

运行时演进工作流

add_steps：从调用方追加一个已校验的修订，不重写先前的尝试。
propose_steps：让活跃的规划步骤提议并行或依赖的步骤；运行时校验图，并插入到该规划步骤的待处理后继之前。

用这些机制在查看证据后添加验证，而不是重放已完成的实现或交付工作。

references/examples.md 包含一个完整的应用测试模板、一个嵌套模板、一个交付模板，以及内置模板的假设。

技能介绍

用途