agents24 Conductor 插件 workflow 模板解析：TDD 任务生命周期、阶段检查点与八道质量门禁

agents24 Conductor 插件 workflow 模板解析TDD 任务生命周期、阶段检查点与八道质量门禁【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents本文围绕 agents 插件市场Multi-harness agentic plugin marketplace中 Conductor 插件的开发工作流模板 workflow.md 展开完整解读其四条核心原则、11 步任务生命周期、阶段完成协议与八道质量门禁的设计细节并结合 setup 命令、implement 命令 等源码级证据说明该模板如何被生成、解析和强制执行帮助你理解一套可落地到 AI Agent 协作开发中的 TDD 工作流规范。workflow.md 模板在 Conductor 中的定位Conductor 是面向 Claude Code 的上下文驱动开发Context-Driven Development插件其核心理念是Context → Spec Plan → Implement把产品愿景、技术决策、工作单元track与工作流规则作为一等工件与代码一同管理。在 插件 README 列出的产物结构中conductor/workflow.md被明确标注为Development practices (TDD, commits)即项目级的开发实践契约。模板 plugins/conductor/templates/workflow.md 本身并不直接生效——它是模板。根据 setup 命令 的Artifact Generation部分/conductor:setup通过交互式问答收集产品定义、技术栈与工作流偏好后才将模板填充为项目根目录下的conductor/workflow.md填充内容包括TDD 策略与严格程度TDD policy and strictness level提交策略与提交规范Commit strategy and conventions代码审查要求Code review requirements验证检查点规则Verification checkpoint rules任务生命周期定义Task lifecycle definition模板中的{{TEST_COMMAND}}、{{COVERAGE_COMMAND}}、{{LINT_COMMAND}}等占位符Mustache 风格对应的正是 setup 命令 在 brownfield存量项目下解析package.json、requirements.txt等文件后得到的真实命令。而 implement 命令 在每次执行任务前会显式读取conductor/workflow.md解析其中的 TDD 严格度、提交策略与检查点规则并将其列为 Critical Rules 之一Follow workflow.md strictly - TDD, commit strategy, and verification rules are mandatory。也就是说这份模板最终演化为项目里一份被 Agent 逐字执行的流程规范。四条核心原则模板开篇即给出 Core Principles这是整个工作流的约束基调plan.md 是唯一事实来源source of truth——所有任务状态与进度都记录在计划的plan.md中而非聊天历史或口头约定测试驱动开发TDD——遵循 Red → Green → Refactor 循环并以 80% 测试覆盖率为目标CI/CD 兼容——所有变更必须通过自动化流水线才能合并增量式推进——每次提交都要小、可验证、目的明确。第四条原则与模板后文每次任务提交 每次计划提交分离的 Git 规范是一脉相承的而第二条中 80% 覆盖率这一阈值会在任务生命周期的第 6 步和质量门禁表中再次出现构成前后呼应。11 步任务生命周期模板的 Task Lifecycle 将单个任务从挑选到归档拆成 11 个步骤状态标记沿用 tracks.md 模板 中定义的图例[ ]表示 Pending、[~]表示 In Progress、[x]表示 Completed。步骤名称关键操作1Task Selection查看 plan.md 中下一个 pending 任务确认依赖已完成理解验收标准2Progress Marking将该任务在 plan.md 中由[ ]改为[~]如统计速度可记录开始时间3Red Phase编写定义预期行为的测试确认测试因正确的原因失败保持测试聚焦且最小4Green Phase写最少的代码让测试通过避免过早优化正确性优先于优雅5Refactor Phase在不改变行为的前提下改进结构应用风格指南约定消除重复、澄清意图6Coverage Verification运行覆盖率报告确保新代码达到 80% 阈值覆盖不足时补边界测试7Deviation Documentation实现偏离规格时记录原因若为永久性变更则更新 spec不确定时标记待评审8Code Commit只暂存相关变更提交信息引用任务格式为[track-id] task: description9Git Notes可选为复杂变更补充实现说明引用相关决策与权衡10Plan Update在 plan.md 中标记[x]更新受影响的下游任务记录阻塞项与后续项11Plan Commit单独提交 plan.md 变更格式为[track-id] plan: mark task X complete几个值得注意的设计点代码提交与计划提交分离Step 8 与 Step 11。代码变更和任务状态变更是两个独立 commit这使得 Git 历史中实现与进度记账可区分、可回溯。revert 命令 正是利用这种命名约定做语义级回滚它按git log --grep{trackId}以及mark task {X.Y} complete等模式检索 commit从而能按 track、phase 或单个 task 精确回退。提交信息格式的严格性因此是整个 revert 能力的前提。偏离必须留痕Step 7。这与 track-plan.md 模板 末尾的 Deviations Log 表格Date / Task / Deviation / Reason / Resolution对应实现偏离不是错误但必须以表格形式沉淀确保 spec 与实现之间的漂移可审计。Refactor 阶段有明确依据Step 5。模板要求应用相关风格指南约定而 Conductor 的风格指南正是由 setup 阶段从 templates/code_styleguides/ 目录生成——该目录提供 general、TypeScript、JavaScript、Python、Go、C#、Dart、HTML/CSS 八份指南。以 general 指南 为例它给出了函数尽量短于 20 行、单一抽象层级、提前返回减少嵌套等可执行规则Refactor 阶段因此不是空泛口号而是有具体条文可依。阶段完成协议Phase Completion Protocol任务级流程之上模板定义了 phase 级的收口机制包含三个部分。Checkpoint Commits每个 phase 结束时必须依次完成确认该 phase 所有任务均为[x]完成态运行完整测试套件确认覆盖率达标创建检查点提交[track-id] checkpoint: phase N complete。这条 checkpoint 提交格式与 track-plan.md 模板 中每个 Phase 的 Checkpoint 小节完全一致例如Commit: [track-id] checkpoint: phase 1 complete且 plan 模板的 Phase 4 检查点额外标注(track done)意味着最后一个 phase 的检查点即 track 的完成信号。Test Verification{{TEST_COMMAND}} {{COVERAGE_COMMAND}}这两条占位符命令即前文所述由 setup 阶段按项目技术栈填充的验证命令保证跑什么测试、用什么工具算覆盖率不需要每次临场决定。Manual Approval Gates以下四类 phase 在继续推进前必须获得人工批准架构变更Architecture changesAPI 契约修改API contract modifications数据库 schema 变更Database schema changes安全敏感实现Security-sensitive implementations这一设计与 implement 命令 中的执行逻辑互相印证每当一个 phase 的全部任务变为[x]实现流程会报告 Phase {N} Verification Results然后CRITICAL: Wait for explicit user approval before proceeding to next phase——即阶段检查点是硬性人工闸门Agent 不得自行跨过。八道质量保证门禁模板规定所有代码在合并前必须通过以下门禁Quality Assurance GatesGateRequirementCommand1. TestsAll tests passing{{TEST_COMMAND}}2. CoverageMinimum 80%{{COVERAGE_COMMAND}}3. StyleFollows style guide{{LINT_COMMAND}}4. DocsPublic APIs documentedManual review5. TypesNo type errors{{TYPE_CHECK_COMMAND}}6. LintingNo lint errors{{LINT_COMMAND}}7. MobileResponsive if applicableManual review8. SecurityNo known vulnerabilities{{SECURITY_COMMAND}}其中五道门禁Tests、Coverage、Style、Types、Linting和一道门禁Security由自动化命令把关两道门禁Docs、Mobile明确为人工审查且 Docs 与 Mobile 属于视适用情况的软性门禁——这与模板Mobile | Responsive if applicable的措辞一致。门禁命令全部走占位符使同一份 workflow 规范能适配不同技术栈填充后Python 项目得到pytest --cov类命令JavaScript 项目得到npm test类命令而门禁语义不变。值得对照的是track-plan.md 模板 的 Final Verification → Quality Gates 清单单测/集成/E2E 全通过、覆盖率 ≥ 80%、无关键 lint 错误、安全扫描通过、性能与可访问性达标基本是这八道门禁在 track 完成时的展开版说明 workflow 模板的通用门禁与 plan 模板的终验清单是同源的。开发命令区与占位符体系模板末尾的 Development Commands 小节定义了四组命令占位符# Environment Setup {{SETUP_COMMAND}} # Development Server {{DEV_COMMAND}} # Pre-Commit Checks {{PRE_COMMIT_COMMAND}} # Full Validation {{VALIDATE_COMMAND}}这四组命令分别覆盖环境初始化、本地开发服务器、提交前检查与全量验证使 Agent 在执行任务时无需猜测这个项目怎么跑起来。占位符填充的来源在 setup 命令 中有据可查Section 3Tech Stack收集主语言、前后端框架、数据库与基础设施对 brownfield 项目会先用Glob查找package.json、requirements.txt、go.mod、Cargo.toml等清单文件并解析预填Section 4Workflow Preferences以四道单选题确定工作流参数TDD 严格度Strict / Moderate / Flexible、提交策略Conventional Commits / 自由描述 / Squash、代码审查要求、验证检查点时机每 phase / 每 task / 仅 track 完成时。这四道题的答案直接决定填充后workflow.md的形态也决定 implement 命令 的行为分支当 TDD 严格度不是 Strict 时实现循环会走Non-TDD Workflow分支——直接实现任务、跑已有测试、按需人工验证而不强制执行 Red-Green-Refactor。因此这份模板实际上是一份可参数化的流程规范原则不变强度可调。工作流全景图模板附带的 ASCII 流程图给出了单任务的标准路径┌─────────────┐ │ Select Task │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ Mark [~] │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ RED: Write │ │ Failing Test│ └──────┬──────┘ │ ▼ ┌─────────────┐ │ GREEN: Make │ │ Test Pass │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ REFACTOR │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ Verify │ │ Coverage │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ Commit Code │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ Mark [x] │ └──────┬──────┘ │ ▼ ┌─────────────┐ │ Commit Plan │ └─────────────┘该图与 11 步生命周期一一对应且刻意把 Commit Code 与 Commit Plan 分成两个独立节点——代码状态与计划状态两次落盘。从 implement 命令 的实现可以看到这套节奏还叠加了第三层状态metadata.json中的tasks.completed、phases.completed与 commit 哈希列表用于支撑 revert 命令 的按 task/phase 精确回退以及暂停后可从current_task字段断点续跑。三份工件plan.md 标记、tracks.md 状态、metadata.json 计数保持同步是这套工作流可恢复性的基础。执行侧佐证workflow-patterns 技能的十二条最佳实践模板定义了应然而 workflow-patterns 技能 定义了执行时的必须。该技能声明在按 plan.md 实现任务、遵循 TDD 循环、完成 phase 检查点、管理 git 提交等场景下使用并给出十二条最佳实践Never skip RED——永远先写失败的测试Small commits——一个 commit 只含一个逻辑变更Immediate updates——任务完成后立刻更新 plan.mdWait for approval——绝不跳过检查点验证Rich git notes——提交说明要包含帮助未来理解的上下文对应生命周期 Step 9Coverage discipline——不接受低于目标值的覆盖率对应 Step 6 与门禁 2Quality gates——标记完成前逐项核对全部门禁Sequential phases——phase 必须按序完成Document deviations——任何偏离原计划的变更都要记录对应 Step 7Clean state——每个 commit 都应让代码处于可工作状态Fast feedback——开发过程中频繁运行相关测试Clear blockers——及时处理阻塞项而不是绕过它。这些实践逐条锚定在模板的具体步骤上可以确认模板并非孤立文档而是 Conductor 命令setup 生成、implement 执行、revert 回退、技能workflow-patterns 约束执行细节与模板plan/spec/metadata 承载状态共同组成的闭环中的一环。使用前提与注意事项模板不直接生效plugins/conductor/templates/workflow.md 是待填充模板{{TEST_COMMAND}}等占位符只有经过/conductor:setup生成项目级conductor/workflow.md后才具有实际意义依赖 track 体系模板中的[track-id]提交前缀、plan.md 状态标记都建立在 Conductor 的 track 产物spec.md / plan.md / metadata.json见 track-spec.md 与 track-plan.md之上脱离 track 使用时可保留 TDD 循环与门禁语义但[track-id]前缀约定需自行替换为项目实际的提交规范适用环境该模板随 Conductor 插件分发插件面向 Claude Code 提供/plugin install conductor插件本身源自 Gemini CLI 生态并适配了 Claude Code文中所有路径均为该插件仓库内的相对位置可在本仓库中直接查阅原文人机分工明确自动化门禁测试、覆盖率、类型、lint、安全由命令驱动而文档、移动端适配、四类高风险 phase 的审批以及 phase 检查点均保留人工决策点这与插件keeping humans in control的设计声明一致。综合来看这份 workflow 模板的价值在于把plan.md 是唯一事实来源TDD 80% 覆盖率代码与计划分离提交阶段人工审批四条纪律写成了 Agent 可逐条解析执行的契约并通过占位符机制保持对不同技术栈的适配能力——它是理解 Conductor 上下文驱动开发如何约束 AI 编码行为的关键文档。【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agents创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考