用途：以普通 Go 代码编写 Gimble 工作流，让程序的目的、决策与证据在源码中可见，追求类似伪代码的清晰度。研究、对比、批评、重试、worktree 与交付都以内联 Go 战术搭配 Gimble 原语表达。
设计要点：区分 Program（角色、分支、并发、反馈与停止决策）、Inputs（本次调用的目标、项目、issue、计划或候选）与 Knowledge（智能体可检索的材料）。任务数据放入参数、作用域上下文与本地文件，避免把每个新任务编码进编排。
形态选择：单任务用一个智能体回合；依赖阶段用带显式结果的序列；独立调查用并发分支加 join；共享研究先研究再分叉；竞争实现用独立 worktree 加评审；批评改稿用显式轮次加停止条件；有限集合用遍历；下一步依赖新证据时用规划器驱动的循环。
角色与交接：研究员确定事实与来源；规划器选下一步任务；worker 执行；validator 检查结果与证据；supervisor 指导在跑的智能体。保持独立性，评审者须看原始证据与真实候选。每个并发分支需有归属并在结束前 join；并行编辑用独立 worktree。交接要给出确切任务、相关文件、观察结果、未决发现与决策。
规划与验证：自适应循环从目标、待办与观察结果选活；把 worker 结果与验证反馈回规划，保留未决发现。Check 记录命令、工作目录、退出码、两个输出流与执行错误，非零退出是证据而非 Check 错误。Service(ctx, name, workdir, command) 用于一个作用域内必须存活的前台依赖，如开发服务器，经 zsh -c 启动并立即继续，启动成功不等于就绪。声明作用域即生命周期边界。
编写与调用：在 Gimble 检出目录内 internal/workflows/ 下加 Go 包，参照 internal/workflows/review/，需要 context.Context、gimble.Env 及可选包内参数结构体，加 //go:generate 指令，结构化结果类型用 Polytype 生成，并把元数据加入 internal/builtin/workflows.go。go generate ./... 会用该选定项生成图、SKGO Form handler、CLI 命令与 Go 客户端绑定。从检出目录运行 just build，重启服务二进制，再对同一实例执行同一构建的 gimble run <name>。独立 gimble.Run(gimble.Project(ctx, dir), ...) 在调用者进程运行，写入 dir/runs，不附加到运行中的实例。运行 UI 需要与已记录工作流匹配的生成图。限制：新导出 API 名需明确请求；生成仅限检出目录内；不同或更旧的服务器二进制无法运行新编译的工作流；并发共享状态使用没有受支持契约；服务不提供重启与健康检查。CLI 帮助取入口函数文档摘要、包文档与参数字段注释。