Gas Town workflow 是一个基于角色的多智能体协作技能，运行于 Claude Code 的任务与消息体系之上。它把戏剧化的角色名称映射为 Claude Code 的智能体类型，并用 convoy 模式将工作拆分为原子、可追踪的单元，指导智能体如何按 Gas Town 约定进行协调。
核心原则
GUPP（Gas Town 通用推进原则）：如果任务挂到你的钩子上，就必须执行。智能体自主推进可用工作，不等待外部输入；对应 Claude Code 即「任务分配给你就立即开始」。
MEOW（工作的分子化表达）：把大目标拆成详细、原子的指令，每项工作都应成为智能体可自主执行的可追踪单元；对应使用 TaskCreate 拆成单一职责、含明确完成标准的任务。
NDI（非确定性幂等）：面向可能不可靠的流程编排出有用结果，依靠持久任务与监督型智能体（monitor、scheduler）保证工作流最终完成；失败时重试与升级，而不是静默丢弃。
角色映射
每个角色有明确的权限边界与升级对象：Crew 对应 coder（生产代码、小幅文档更新）；Refinery 对应 integrator（合并、rebase、冲突解决）；Witness 对应 monitor（观察进展、发现停滞、上报）；Deacon 对应 scheduler（触发工作流、重试受阻或停滞任务）；Dogs 对应 maintainer（清理、lint、索引重建）。另有 reviewer（只读代码审查与计划审计）、tester（测试、覆盖率、验证）、architect（跨领域设计审批）、planner（仅计划与文档，不写生产代码）、orchestrator（并行任务协调）。完整权限表与升级路径见 references/role-map.md。
Convoy 模式
convoy 将相关任务组成一个逻辑工作单元，从头到尾追踪批量工作。创建方式：先建描述 convoy 目标的父任务；为每个步骤建子任务，并在主题行标注目标角色；用 addBlockedBy 设置依赖以保证顺序；把任务分配给匹配角色的智能体。
主题行标记示例：[CODER] Implement token refresh flow、[TESTER] Write tests for token refresh、[REVIEWER] Audit refresh flow changes、[INTEGRATOR] Merge token refresh branch。
每个任务描述必须包含：Role、Convoy 名称，以及 Done when 下的客观完成标准。现成 convoy 模板见 references/convoy-templates.md。
任务路由与认领
认领任务时检查 TaskList 中与自身角色匹配且未被阻塞的任务，认领优先级最高者（优先级相同时以任务 ID 顺序为准），开始前用 TaskUpdate 标记 in_progress，绝不做分配给其他智能体的任务。路由规则：生产代码改到 coder，测试创建与覆盖到 tester，代码审查或计划审计到 reviewer，合并与冲突解决到 integrator，设计决策到 architect，计划与纯文档到 planner，lint/清理/索引重建到 maintainer，工作流触发与重试到 scheduler，进展监控与停滞检测到 monitor，并行任务协调到 orchestrator。
升级规则
超出权限边界时必须升级而非硬做：通过 SendMessage 通知目标智能体，或用 TaskCreate 登记问题。例如 coder 遇设计冲突升级给 architect、任务含糊升级给 planner、执行依赖受阻升级给 orchestrator；integrator 重试后合并失败升级给人类；monitor 发现卡住的 worker 升级给 orchestrator、系统性故障升级给人类；tester 发现生产缺陷升级给 coder；reviewer 发现计划漂移升级给 planner；planner 遇架构决策升级给 architect；maintainer 与 scheduler 不做架构决策或诊断。
沟通模式
SendMessage 用于升级、协调、完成信号和关闭请求；TaskUpdate 用于标记状态、设置依赖、分配归属；TaskCreate 用于登记任务范围外的新工作、拆分大任务、记录需要其他角色关注的阻塞。日常沟通不得使用广播消息，应定向发送给需要该信息的特定智能体。
完成纪律
智能体必须显式表达状态，有任务却静默空闲属于严重失败模式（idle polecat heresy）。任务完成：用 TaskUpdate 标记完成并向团队负责人发送完成消息；任务受阻：在描述中记录阻塞、用 TaskCreate 建阻塞任务并通知阻塞方；需要升级：发送升级消息并记录；无更多工作：检查 TaskList，若无可用任务则通知团队负责人并等待分配。完成检查清单：核对 done-when 标准、运行相关测试或检查、标记完成、查找下一个匹配角色的可用任务、无任务则通知团队负责人。
子智能体调度与边界
每个原子任务应派发全新子智能体，跨任务复用会带来陈旧上下文、漂移和判断力下降；SendMessage 仅用于状态同步，不得用它把后续编辑工作串接到已完成任务的队友上（见 docs/REPO_STYLE.md）。
本技能与 delegate-manager-to-subagents 都协调多智能体工作，但词汇与意图不同。执行已批准计划时默认用 delegate-manager-to-subagents（普通 manager/coder/reviewer/tester/docs 角色、受控委派、每原子任务一个新子智能体、显式审查关卡）。仅当用户明确要求 Gas Town 约定（convoy 式拆解、戏剧化角色名 Crew/Refinery/Witness/Dogs/Deacon 及本仓库角色目录）时才使用本技能。两者不可互换：不得把 Gas Town 词汇静默替换进 delegate-manager-to-subagents 流程，也不得从 Gas Town 流程中去掉这些词汇。
术语对照
Bead 对应 Claude Task；Hook 对应按角色过滤的任务队列；Slinging 对应任务创建与分配（TaskCreate + 带 owner 的 TaskUpdate）；Convoy 对应分组的相关任务集合；Nudging 对应智能体间的 SendMessage；Patrol 对应周期性健康检查。完整术语表见 references/glossary.md。
快速开始
若环境支持团队，用 TeamCreate 创建团队（仅 orchestrator 或 parallelizer）；用 TaskCreate 按主题行标记和任务描述格式创建 convoy 任务；用 TaskUpdate addBlockedBy 设置依赖；按标注角色生成智能体；用 TaskUpdate owner 分配任务；智能体遵循 GUPP：认领、执行、发出完成信号、认领下一个任务；monitor 用 TaskList 检测停滞并升级；所有 convoy 任务完成后关闭队友。