Conductor Setup 命令深度解析用交互式问答初始化 Claude Code 的上下文驱动开发项目【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agentsConductor 是 Claude Code 生态中的“上下文驱动开发”Context-Driven Development插件核心流程为Context → Spec Plan → Implement。本篇聚焦其中最关键的第一步setup命令即本仓库 plugins/conductor/commands/setup.md 定义的 conductor:setup它通过一套高度可中断、可恢复的交互式问答把“产品愿景、产品准则、技术栈、工作流、代码风格指南”沉淀为项目根目录conductor/下的结构化文档为后续 new-track、implement、revert 等命令奠定一致的上下文基础。读完本篇你将掌握 setup 命令的完整执行协议预检、五段式问答、产物生成、状态管理、续跑与容错并能将它与仓库内templates/模板一一对应用于实际项目初始化。一、Setup 在整个 Conductor 工作流中的定位先看全景本仓库的 conductor/README.md 将 Conductor 定义为一套把 Claude Code “变成项目管理工具”的机制其核心哲学是把上下文当作和代码并列的一等管理资产Product vision产品愿景作为活的文档Technical decisions技术决策作为结构化产物Work units / tracks工作单元携带 spec 与分阶段 planTDD workflow 带验证检查点/conductor:setup处于流水线最前端——在创建任何 track功能/缺陷/chore/重构之前必须先完成它。仓库命令家族的关系如下表命令职责是否依赖 setup 产物/conductor:setup初始化项目上下文文档无自身创建/conductor:new-track创建 track 的 spec.md 与 plan.md是需先校验 product.md / tech-stack.md / workflow.md 存在见 new-track.md 的 Pre-flight Checks/conductor:implement按 plan 执行任务是/conductor:status展示项目进度是/conductor:revert按 track/phase/task 做 Git 语义回滚是/conductor:managetrack 生命周期管理是new-track.md里的 Pre-flight 校验逻辑可以反向印证 setup 的产出标准它检查conductor/product.md、conductor/tech-stack.md、conductor/workflow.md是否存在任一缺失就提示先运行 setup。因此 setup 生成的三份“上下文文档”是整条 Conductor 工作链的事实前提。二、Setup 生成的目录结构与产物全览完成 setup 后会在项目根目录生成conductor/文件夹。README 中的产物树给出了最终目标形态conductor/ ├── index.md # 导航中心 ├── product.md # 产品愿景与目标 ├── product-guidelines.md # 准则与信息传达 ├── tech-stack.md # 技术偏好 ├── workflow.md # 开发实践TDD、提交规范 ├── tracks.md # track 总注册表 ├── setup_state.json # 可续跑的状态文件 ├── code_styleguides/ # 各语言约定 └── tracks/ ├── _archive/ # 已归档 track └── track-id/ ├── spec.md ├── plan.md ├── metadata.json └── index.md其中tracks/及其子文件由后续的new-track创建setup 本身聚焦于上层七类产物的生成具体见下文“产物生成”一节。三、Pre-flight Checks进入问答前的三次判定setup.md 明确要求在任何提问之前完成三项预检其顺序与语义如下1. 检测 conductor/ 是否已存在决定 reinitialize 还是 resume若conductor/product.md已存在询问用户是恢复resume还是重新初始化reinitialize若conductor/setup_state.json存在且状态为 incomplete主动提议从上次步骤继续。这套逻辑与文档中 Resume Handling 一节相互呼应setup命令天然支持--resume参数见文件头部 frontmatter 的argument-hint: [--resume]允许用户在多次会话之间分段完成初始化。2. 探测项目类型决定问答策略通过检查以下任一“项目已存在”的信号区分两种模式Greenfield全新项目当前目录没有.git、package.json、requirements.txt、go.mod、src/等任何痕迹Brownfield已有项目上述任一信号存在。该判定会直接影响 Tech Stack 问答环节brownfield 项目会先用Glob扫描并解析包清单文件预填技术栈后请用户确认而 greenfield 则从零开始选择。3. 加载或创建 setup_state.json这是 setup 可续跑能力的落点。文件的标准形态为{ status: in_progress, project_type: greenfield|brownfield, current_section: product|guidelines|tech_stack|workflow|styleguides, current_question: 1, completed_sections: [], answers: {}, files_created: [], started_at: ISO_TIMESTAMP, last_updated: ISO_TIMESTAMP }字段职责可概括为status标记整体进度in_progress / completeproject_type固化预检结果current_sectioncurrent_question精确记录中断位置completed_sections、files_created分别用于跳过已完成段落与校验产物是否落盘answers暂存原始回答供模板填充时回读。四、交互式问答协议每节一个话题、逐问推进setup.md 强调五条CRITICAL RULES是整套问答的纪律红线每轮只问一个问题等待用户回答后再继续每个问题提供23 个建议答案外加“Type your own”自定义选项每个 Section 最多 5 个问题每成功一步就更新setup_state.json只有确认文件写入成功后才继续下一步。问答被划分为五个 Section覆盖从“做什么”到“怎么做”的完整决策链。各节的规模上限和关注点汇总如下。Section名称问题上限覆盖主题1Product Definition5项目名、一句话描述、要解决的问题、目标用户、关键目标可选2Product Guidelines3语气/口吻、设计原则3Tech Stack5主语言、前端框架、后端框架、数据库、基础设施4Workflow Preferences4TDD 严格度、提交策略、代码评审、人工验证检查点5Code Style Guides2需要生成哪些语言指南、是否吸收既有 lint/format 配置Section 1Product Definition产品定义最多 5 问Q1 项目名建议从目录名推断greenfield或从package.json/go.mod推断brownfieldQ2 项目描述一句话说清项目是什么Q3 问题陈述项目要解决什么问题、用户的痛点Q4 目标用户谁是最主要的使用者Q5 关键目标可选写下 23 个关键目标允许直接回车跳过。该节回答将直接填充product.md模板详见 templates/product.md中的产品名、标签行、详细描述、问题陈述、目标用户、核心价值主张等占位符。Section 2Product Guidelines产品准则最多 3 问Q1 语气与口吻建议项包括 Professional and technical / Friendly and approachable / Concise and directQ2 设计原则建议项包括 Simplicity over features / Performance first / Developer experience focused / User safety and reliability自定义可逗号分隔多选。对应模板 templates/product-guidelines.md 里不止有 Brand Voice 与 Design Principles还预置了各上下文的语气变化表、可访问性标准WCAG 2.1 AA 及四大原则清单与错误处理哲学。Setup 问答取得的高层偏好正是这些章节的锚点。Section 3Tech Stack技术栈最多 5 问Brownfield 分支先执行Glob找出package.json、requirements.txt、go.mod、Cargo.toml等清单文件解析后预填技术栈再用类似 “I detected: Python 3.11, JavaScript. Is this correct?” 的方式请用户确认或增补。随后五问依次为Q1 主语言建议 TypeScript / Python / Go / Rust可逗号分隔多选Q2 前端框架React / Vue / Next.js / None·CLI onlyQ3 后端框架Express·Fastify / Django·FastAPI / Go 标准库 / None·Frontend onlyQ4 数据库PostgreSQL / MongoDB / SQLite / None·StatelessQ5 基础设施AWS Lambda·ECS / Vercel·Netlify / Self-hosted·Docker / Not decided yet。生成目标模板 templates/tech-stack.md 是一个相当完整的《Technology Stack》文档除语言/框架/数据库/托管外还包括状态管理、样式方案、CI/CD 流水线阶段、监控三件套APM/Logging/Alerting、开发工具包管理器、测试、lint/format、Decision Log 决策日志与版本兼容矩阵适合长期演进时持续维护。Section 4Workflow Preferences工作流偏好最多 4 问Q1 TDD 严格度Strict实现前必须写测试/ Moderate鼓励不阻塞/ Flexible仅复杂逻辑建议测试Q2 提交策略Conventional Commitsfeat:/fix: 等/ 自由描述式 / 每任务 squashQ3 代码评审所有变更必须评审 / 非平凡变更需评审 / 可选·允许自审Q4 人工验证检查点每个 phase 完成后 / 每个 task 完成后 / 仅在 track 完成时。这些回答决定 templates/workflow.md 中“任务生命周期”的执行方式——该模板把 TDD 拆成 Red先写失败测试→ Green最小实现通过→ Refactor 三步并定义了[ ] → [~] → [x]的状态标记、80% 覆盖率阈值、checkpoint 提交格式[track-id] checkpoint: phase N complete以及 8 项质量门禁Tests / Coverage / Style / Docs / Types / Linting / Mobile / Security。Workflow 问答应答得越具体模板中被{{TEST_COMMAND}}、{{COVERAGE_COMMAND}}这类占位符预留的命令位就越容易被真实填充。Section 5Code Style Guides代码风格最多 2 问Q1 生成哪些语言的指南根据已探测语言预选选项含 TypeScript/JavaScript、Python、Go、Rust、All detected languages、Skip style guidesQ2 是否吸收既有配置brownfield 场景如检测到.eslintrc、.prettierrc会询问 “I found .eslintrc, .prettierrc. Should I incorporate these?”可选 Yes·use existing configs / No·generate fresh guides / Skip。五、产物生成一份模板、七个文件的落地清单QA 全部完成后进入产物生成阶段。setup.md 明确了七个目标conductor/index.md— 导航中心。setup.md 给出了最简结构Quick Links 指向 product / product-guidelines / tech-stack / workflow / tracksActive Tracks 区域由/conductor:new-track自动填充并有“运行/conductor:new-track创建第一条 track”的引导而仓库中的真实母版 templates/index.md 更为丰富包含核心文档状态表、风格指南入口general/typescript/javascript/python/go/csharp/dart/html-css、Active Tracks 表、Recent Activity、Milestone Tracker 与 Commands Reference。conductor/product.md— 用模板填充 Q1Q5 的答案。注意 templates/product.md 不仅覆盖“名称/描述/问题/用户/目标”还预留了现有方案与差距分析、核心价值主张、成功指标KPI 表、北极星指标、先行/滞后指标、Out of Scope明确不做、未来考虑、非目标等更深的章节setup 可据回答深度决定填充多少。conductor/product-guidelines.md— 填充语气口吻与设计原则见上文 Section 2。conductor/tech-stack.md— 填充语言带探测到的版本、前后端框架、数据库、基础设施brownfield 还会纳入从包清单解析出的关键依赖。conductor/workflow.md— 填充 TDD 政策、提交约定、评审要求、验证检查点与任务生命周期定义。conductor/tracks.md— track 注册总表setup.md 提供的骨架是四列表Status / Track ID / Title / Created / Updated行数据由 new-track 追加真实模板 templates/tracks.md 还包含状态图例[ ]Pending、[~]In Progress、[x]Completed、Active/Completed/Archived 分区与 Track Creation Checklist。conductor/code_styleguides/— 从模板目录复制所选语言的风格指南。风格指南模板的来源setup.md 指出风格指南来源于$CLAUDE_PLUGIN_ROOT/templates/code_styleguides/。就本仓库而言对应目录是 plugins/conductor/templates/code_styleguides/内含八个指南文件general.md通用原则、typescript.md、javascript.md、python.md、go.md、csharp.md、dart.mdDart/Flutter、html-css.md与 index.md 模板中的风格指南链接一一对应。Setup 只复制与项目语言匹配的子集。六、状态管理与“每步落盘”的可靠性设计setup.md 要求“每次成功创建文件后”执行三件事更新setup_state.json把文件名追加进files_created、刷新last_updated时间戳、若整节完成则加入completed_sections用 Read 工具复核文件确实存在确认成功后才继续下一问题/下一节。这意味着 setup 是“写完即校验、校验过才记账”的流程而不是一口气批量写盘后再汇报为任意时刻的用户取消、会话中断做好了恢复铺垫。这正对应 README Features 中State Persistence: Resume setup across multiple sessions的设计承诺。七、Completion正常收尾的确认清单与摘要当全部文件创建完成要求将setup_state.json的status置为complete向用户展示完成摘要包括产物清单Conductor setup complete! Created artifacts: - conductor/index.md - conductor/product.md - conductor/product-guidelines.md - conductor/tech-stack.md - conductor/workflow.md - conductor/tracks.md - conductor/code_styleguides/[languages] Next steps: 1. Review generated files and customize as needed 2. Run /conductor:new-track to create your first track注意摘要把“运行new-track创建第一条 track”作为下一步动作与 Pre-flight 校验形成闭环——setup 之后的第一件事永远是建 track。new-track 命令详解可继续阅读仓库中的 new-track.md。八、Resume 与 Error Handling中断续跑与异常兜底Resume Handling支持--resume参数或状态触发加载setup_state.json跳过已完成的completed_sections从current_section与current_question精确续问校验先前已创建的files_created文件是否仍存在若发现文件缺失主动提议重新生成。值得注意Resume 的“文件存在性复核”与正常流程中的“写后 Read 复核”用的是同一套校验手段说明 Conductor 把“文档即状态”与“状态文件即指针”两种视图做了对账避免状态文件声称完成、磁盘文件却丢失的不一致。Error Handling文件写入失败立即中止并上报错误不更新状态——防止files_created记录到不存在的文件用户取消保存当前状态以便未来 resume——这是对“允许半途退出”的显式背书状态文件损坏询问用户“从头开始”还是“尝试从损坏状态中恢复”。从源码结构看这些分支与前面setup_state.json的完整字段设计是一体两面status、current_section/current_question、files_created、last_updated四个字段分别服务于错误定位、断点续问、文件对账与状态新鲜度判断共同把“交互式初始化”从一次性脚本升级为可长期维护的项目引导流程。九、最小实操指南在 Claude Code 中运行 setup结合仓库 README 的安装方式与 setup 命令语义实际使用路径如下# 1. 安装 Conductor 插件 /plugin install conductor # 2. 在项目根目录启动交互式初始化 /conductor:setup # 3. 若初始化中途被中断在任意新会话中续跑 /conductor:setup --resume # 4. 初始化完成后创建第一条功能 track /conductor:new-track使用约束与前提setup 面向“项目根目录”产物默认落在根目录的conductor/Greenfield 项目建议先执行git init再运行便于后续revert的 Git 语义Brownfield 项目会依赖仓库已有的包清单文件做技术栈预探测。文中提到的status、current_section等字段的实际行为均以当前仓库 setup.md 与配套 templates 为唯一依据。十、小结Setup 解决的问题与后续延伸conductor:setup的实质是在每次 AI 协作会话都要重新理解项目的世界里用一次结构化的问答把“产品为何存在、按什么准则说话、用什么技术、按什么流程写代码”固化成机器可复读、人可审阅的上下文文档。它带来的直接收益有三上下文一致后续 new-track、implement、status 不再需要用户重复交代背景可中断可恢复setup_state.json让初始化可跨会话完成--resume与文件对账机制保证断点续跑的可靠性模板即资产从 index.md 到 workflow.md 的占位符模板既是生成依据也是后续人工迭代的起点。读完本文后你可以顺藤摸瓜继续阅读仓库内 conductor 命令族 中new-track.md如何把 setup 产出的上下文转化为 spec 与 plan与implement.md如何按 workflow.md 的纪律执行任务完整掌握 Conductor 的 Context → Spec Plan → Implement 全链路。【免费下载链接】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），仅供参考 Conductor Setup 命令深度解析：用交互式问答初始化 Claude Code 的上下文驱动开发项目
Conductor Setup 命令深度解析用交互式问答初始化 Claude Code 的上下文驱动开发项目【免费下载链接】agentsMulti-harness agentic plugin marketplace for Claude Code, Codex, Cursor, OpenCode, GitHub Copilot, and Google Antigravity项目地址: https://gitcode.com/GitHub_Trending/agents24/agentsConductor 是 Claude Code 生态中的“上下文驱动开发”Context-Driven Development插件核心流程为Context → Spec Plan → Implement。本篇聚焦其中最关键的第一步setup命令即本仓库 plugins/conductor/commands/setup.md 定义的 conductor:setup它通过一套高度可中断、可恢复的交互式问答把“产品愿景、产品准则、技术栈、工作流、代码风格指南”沉淀为项目根目录conductor/下的结构化文档为后续 new-track、implement、revert 等命令奠定一致的上下文基础。读完本篇你将掌握 setup 命令的完整执行协议预检、五段式问答、产物生成、状态管理、续跑与容错并能将它与仓库内templates/模板一一对应用于实际项目初始化。一、Setup 在整个 Conductor 工作流中的定位先看全景本仓库的 conductor/README.md 将 Conductor 定义为一套把 Claude Code “变成项目管理工具”的机制其核心哲学是把上下文当作和代码并列的一等管理资产Product vision产品愿景作为活的文档Technical decisions技术决策作为结构化产物Work units / tracks工作单元携带 spec 与分阶段 planTDD workflow 带验证检查点/conductor:setup处于流水线最前端——在创建任何 track功能/缺陷/chore/重构之前必须先完成它。仓库命令家族的关系如下表命令职责是否依赖 setup 产物/conductor:setup初始化项目上下文文档无自身创建/conductor:new-track创建 track 的 spec.md 与 plan.md是需先校验 product.md / tech-stack.md / workflow.md 存在见 new-track.md 的 Pre-flight Checks/conductor:implement按 plan 执行任务是/conductor:status展示项目进度是/conductor:revert按 track/phase/task 做 Git 语义回滚是/conductor:managetrack 生命周期管理是new-track.md里的 Pre-flight 校验逻辑可以反向印证 setup 的产出标准它检查conductor/product.md、conductor/tech-stack.md、conductor/workflow.md是否存在任一缺失就提示先运行 setup。因此 setup 生成的三份“上下文文档”是整条 Conductor 工作链的事实前提。二、Setup 生成的目录结构与产物全览完成 setup 后会在项目根目录生成conductor/文件夹。README 中的产物树给出了最终目标形态conductor/ ├── index.md # 导航中心 ├── product.md # 产品愿景与目标 ├── product-guidelines.md # 准则与信息传达 ├── tech-stack.md # 技术偏好 ├── workflow.md # 开发实践TDD、提交规范 ├── tracks.md # track 总注册表 ├── setup_state.json # 可续跑的状态文件 ├── code_styleguides/ # 各语言约定 └── tracks/ ├── _archive/ # 已归档 track └── track-id/ ├── spec.md ├── plan.md ├── metadata.json └── index.md其中tracks/及其子文件由后续的new-track创建setup 本身聚焦于上层七类产物的生成具体见下文“产物生成”一节。三、Pre-flight Checks进入问答前的三次判定setup.md 明确要求在任何提问之前完成三项预检其顺序与语义如下1. 检测 conductor/ 是否已存在决定 reinitialize 还是 resume若conductor/product.md已存在询问用户是恢复resume还是重新初始化reinitialize若conductor/setup_state.json存在且状态为 incomplete主动提议从上次步骤继续。这套逻辑与文档中 Resume Handling 一节相互呼应setup命令天然支持--resume参数见文件头部 frontmatter 的argument-hint: [--resume]允许用户在多次会话之间分段完成初始化。2. 探测项目类型决定问答策略通过检查以下任一“项目已存在”的信号区分两种模式Greenfield全新项目当前目录没有.git、package.json、requirements.txt、go.mod、src/等任何痕迹Brownfield已有项目上述任一信号存在。该判定会直接影响 Tech Stack 问答环节brownfield 项目会先用Glob扫描并解析包清单文件预填技术栈后请用户确认而 greenfield 则从零开始选择。3. 加载或创建 setup_state.json这是 setup 可续跑能力的落点。文件的标准形态为{ status: in_progress, project_type: greenfield|brownfield, current_section: product|guidelines|tech_stack|workflow|styleguides, current_question: 1, completed_sections: [], answers: {}, files_created: [], started_at: ISO_TIMESTAMP, last_updated: ISO_TIMESTAMP }字段职责可概括为status标记整体进度in_progress / completeproject_type固化预检结果current_sectioncurrent_question精确记录中断位置completed_sections、files_created分别用于跳过已完成段落与校验产物是否落盘answers暂存原始回答供模板填充时回读。四、交互式问答协议每节一个话题、逐问推进setup.md 强调五条CRITICAL RULES是整套问答的纪律红线每轮只问一个问题等待用户回答后再继续每个问题提供23 个建议答案外加“Type your own”自定义选项每个 Section 最多 5 个问题每成功一步就更新setup_state.json只有确认文件写入成功后才继续下一步。问答被划分为五个 Section覆盖从“做什么”到“怎么做”的完整决策链。各节的规模上限和关注点汇总如下。Section名称问题上限覆盖主题1Product Definition5项目名、一句话描述、要解决的问题、目标用户、关键目标可选2Product Guidelines3语气/口吻、设计原则3Tech Stack5主语言、前端框架、后端框架、数据库、基础设施4Workflow Preferences4TDD 严格度、提交策略、代码评审、人工验证检查点5Code Style Guides2需要生成哪些语言指南、是否吸收既有 lint/format 配置Section 1Product Definition产品定义最多 5 问Q1 项目名建议从目录名推断greenfield或从package.json/go.mod推断brownfieldQ2 项目描述一句话说清项目是什么Q3 问题陈述项目要解决什么问题、用户的痛点Q4 目标用户谁是最主要的使用者Q5 关键目标可选写下 23 个关键目标允许直接回车跳过。该节回答将直接填充product.md模板详见 templates/product.md中的产品名、标签行、详细描述、问题陈述、目标用户、核心价值主张等占位符。Section 2Product Guidelines产品准则最多 3 问Q1 语气与口吻建议项包括 Professional and technical / Friendly and approachable / Concise and directQ2 设计原则建议项包括 Simplicity over features / Performance first / Developer experience focused / User safety and reliability自定义可逗号分隔多选。对应模板 templates/product-guidelines.md 里不止有 Brand Voice 与 Design Principles还预置了各上下文的语气变化表、可访问性标准WCAG 2.1 AA 及四大原则清单与错误处理哲学。Setup 问答取得的高层偏好正是这些章节的锚点。Section 3Tech Stack技术栈最多 5 问Brownfield 分支先执行Glob找出package.json、requirements.txt、go.mod、Cargo.toml等清单文件解析后预填技术栈再用类似 “I detected: Python 3.11, JavaScript. Is this correct?” 的方式请用户确认或增补。随后五问依次为Q1 主语言建议 TypeScript / Python / Go / Rust可逗号分隔多选Q2 前端框架React / Vue / Next.js / None·CLI onlyQ3 后端框架Express·Fastify / Django·FastAPI / Go 标准库 / None·Frontend onlyQ4 数据库PostgreSQL / MongoDB / SQLite / None·StatelessQ5 基础设施AWS Lambda·ECS / Vercel·Netlify / Self-hosted·Docker / Not decided yet。生成目标模板 templates/tech-stack.md 是一个相当完整的《Technology Stack》文档除语言/框架/数据库/托管外还包括状态管理、样式方案、CI/CD 流水线阶段、监控三件套APM/Logging/Alerting、开发工具包管理器、测试、lint/format、Decision Log 决策日志与版本兼容矩阵适合长期演进时持续维护。Section 4Workflow Preferences工作流偏好最多 4 问Q1 TDD 严格度Strict实现前必须写测试/ Moderate鼓励不阻塞/ Flexible仅复杂逻辑建议测试Q2 提交策略Conventional Commitsfeat:/fix: 等/ 自由描述式 / 每任务 squashQ3 代码评审所有变更必须评审 / 非平凡变更需评审 / 可选·允许自审Q4 人工验证检查点每个 phase 完成后 / 每个 task 完成后 / 仅在 track 完成时。这些回答决定 templates/workflow.md 中“任务生命周期”的执行方式——该模板把 TDD 拆成 Red先写失败测试→ Green最小实现通过→ Refactor 三步并定义了[ ] → [~] → [x]的状态标记、80% 覆盖率阈值、checkpoint 提交格式[track-id] checkpoint: phase N complete以及 8 项质量门禁Tests / Coverage / Style / Docs / Types / Linting / Mobile / Security。Workflow 问答应答得越具体模板中被{{TEST_COMMAND}}、{{COVERAGE_COMMAND}}这类占位符预留的命令位就越容易被真实填充。Section 5Code Style Guides代码风格最多 2 问Q1 生成哪些语言的指南根据已探测语言预选选项含 TypeScript/JavaScript、Python、Go、Rust、All detected languages、Skip style guidesQ2 是否吸收既有配置brownfield 场景如检测到.eslintrc、.prettierrc会询问 “I found .eslintrc, .prettierrc. Should I incorporate these?”可选 Yes·use existing configs / No·generate fresh guides / Skip。五、产物生成一份模板、七个文件的落地清单QA 全部完成后进入产物生成阶段。setup.md 明确了七个目标conductor/index.md— 导航中心。setup.md 给出了最简结构Quick Links 指向 product / product-guidelines / tech-stack / workflow / tracksActive Tracks 区域由/conductor:new-track自动填充并有“运行/conductor:new-track创建第一条 track”的引导而仓库中的真实母版 templates/index.md 更为丰富包含核心文档状态表、风格指南入口general/typescript/javascript/python/go/csharp/dart/html-css、Active Tracks 表、Recent Activity、Milestone Tracker 与 Commands Reference。conductor/product.md— 用模板填充 Q1Q5 的答案。注意 templates/product.md 不仅覆盖“名称/描述/问题/用户/目标”还预留了现有方案与差距分析、核心价值主张、成功指标KPI 表、北极星指标、先行/滞后指标、Out of Scope明确不做、未来考虑、非目标等更深的章节setup 可据回答深度决定填充多少。conductor/product-guidelines.md— 填充语气口吻与设计原则见上文 Section 2。conductor/tech-stack.md— 填充语言带探测到的版本、前后端框架、数据库、基础设施brownfield 还会纳入从包清单解析出的关键依赖。conductor/workflow.md— 填充 TDD 政策、提交约定、评审要求、验证检查点与任务生命周期定义。conductor/tracks.md— track 注册总表setup.md 提供的骨架是四列表Status / Track ID / Title / Created / Updated行数据由 new-track 追加真实模板 templates/tracks.md 还包含状态图例[ ]Pending、[~]In Progress、[x]Completed、Active/Completed/Archived 分区与 Track Creation Checklist。conductor/code_styleguides/— 从模板目录复制所选语言的风格指南。风格指南模板的来源setup.md 指出风格指南来源于$CLAUDE_PLUGIN_ROOT/templates/code_styleguides/。就本仓库而言对应目录是 plugins/conductor/templates/code_styleguides/内含八个指南文件general.md通用原则、typescript.md、javascript.md、python.md、go.md、csharp.md、dart.mdDart/Flutter、html-css.md与 index.md 模板中的风格指南链接一一对应。Setup 只复制与项目语言匹配的子集。六、状态管理与“每步落盘”的可靠性设计setup.md 要求“每次成功创建文件后”执行三件事更新setup_state.json把文件名追加进files_created、刷新last_updated时间戳、若整节完成则加入completed_sections用 Read 工具复核文件确实存在确认成功后才继续下一问题/下一节。这意味着 setup 是“写完即校验、校验过才记账”的流程而不是一口气批量写盘后再汇报为任意时刻的用户取消、会话中断做好了恢复铺垫。这正对应 README Features 中State Persistence: Resume setup across multiple sessions的设计承诺。七、Completion正常收尾的确认清单与摘要当全部文件创建完成要求将setup_state.json的status置为complete向用户展示完成摘要包括产物清单Conductor setup complete! Created artifacts: - conductor/index.md - conductor/product.md - conductor/product-guidelines.md - conductor/tech-stack.md - conductor/workflow.md - conductor/tracks.md - conductor/code_styleguides/[languages] Next steps: 1. Review generated files and customize as needed 2. Run /conductor:new-track to create your first track注意摘要把“运行new-track创建第一条 track”作为下一步动作与 Pre-flight 校验形成闭环——setup 之后的第一件事永远是建 track。new-track 命令详解可继续阅读仓库中的 new-track.md。八、Resume 与 Error Handling中断续跑与异常兜底Resume Handling支持--resume参数或状态触发加载setup_state.json跳过已完成的completed_sections从current_section与current_question精确续问校验先前已创建的files_created文件是否仍存在若发现文件缺失主动提议重新生成。值得注意Resume 的“文件存在性复核”与正常流程中的“写后 Read 复核”用的是同一套校验手段说明 Conductor 把“文档即状态”与“状态文件即指针”两种视图做了对账避免状态文件声称完成、磁盘文件却丢失的不一致。Error Handling文件写入失败立即中止并上报错误不更新状态——防止files_created记录到不存在的文件用户取消保存当前状态以便未来 resume——这是对“允许半途退出”的显式背书状态文件损坏询问用户“从头开始”还是“尝试从损坏状态中恢复”。从源码结构看这些分支与前面setup_state.json的完整字段设计是一体两面status、current_section/current_question、files_created、last_updated四个字段分别服务于错误定位、断点续问、文件对账与状态新鲜度判断共同把“交互式初始化”从一次性脚本升级为可长期维护的项目引导流程。九、最小实操指南在 Claude Code 中运行 setup结合仓库 README 的安装方式与 setup 命令语义实际使用路径如下# 1. 安装 Conductor 插件 /plugin install conductor # 2. 在项目根目录启动交互式初始化 /conductor:setup # 3. 若初始化中途被中断在任意新会话中续跑 /conductor:setup --resume # 4. 初始化完成后创建第一条功能 track /conductor:new-track使用约束与前提setup 面向“项目根目录”产物默认落在根目录的conductor/Greenfield 项目建议先执行git init再运行便于后续revert的 Git 语义Brownfield 项目会依赖仓库已有的包清单文件做技术栈预探测。文中提到的status、current_section等字段的实际行为均以当前仓库 setup.md 与配套 templates 为唯一依据。十、小结Setup 解决的问题与后续延伸conductor:setup的实质是在每次 AI 协作会话都要重新理解项目的世界里用一次结构化的问答把“产品为何存在、按什么准则说话、用什么技术、按什么流程写代码”固化成机器可复读、人可审阅的上下文文档。它带来的直接收益有三上下文一致后续 new-track、implement、status 不再需要用户重复交代背景可中断可恢复setup_state.json让初始化可跨会话完成--resume与文件对账机制保证断点续跑的可靠性模板即资产从 index.md 到 workflow.md 的占位符模板既是生成依据也是后续人工迭代的起点。读完本文后你可以顺藤摸瓜继续阅读仓库内 conductor 命令族 中new-track.md如何把 setup 产出的上下文转化为 spec 与 plan与implement.md如何按 workflow.md 的纪律执行任务完整掌握 Conductor 的 Context → Spec Plan → Implement 全链路。【免费下载链接】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），仅供参考