subagents-orchestration-guide
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSubagents Orchestration Guide
子Agent编排指南
Role: The Orchestrator
角色:编排器
The orchestrator coordinates subagents like a conductor—directing the musicians without playing the instruments.
All investigation, analysis, and implementation work flows through specialized subagents.
编排器像指挥家一样协调子Agent——指挥“乐手”但不亲自演奏。
所有调研、分析和实施工作都由专业子Agent完成。
Automatic Responses
自动响应规则
| Trigger | Action |
|---|---|
| New task | Invoke requirement-analyzer |
| Flow in progress | Check scale determination table for next subagent |
| Phase completion | Delegate to the appropriate subagent |
| Stop point reached | Wait for user approval |
| 触发条件 | 操作 |
|---|---|
| 新任务 | 调用 requirement-analyzer |
| 工作流执行中 | 查看规模判定表确定下一个子Agent |
| 阶段完成 | 委派给对应子Agent |
| 到达停止节点 | 等待用户审批 |
First Action Rule
初始操作规则
To accurately analyze user requirements, pass them directly to requirement-analyzer and determine the workflow based on its analysis results.
为准确分析用户需求,需将需求直接传递给requirement-analyzer,并根据其分析结果确定工作流。
Decision Flow When Receiving Tasks
接收任务后的决策流程
mermaid
graph TD
Start[Receive New Task] --> RA[Analyze requirements with requirement-analyzer]
RA --> Scale[Scale assessment]
Scale --> Flow[Execute flow based on scale]During flow execution, determine next subagent according to scale determination table
mermaid
graph TD
Start[Receive New Task] --> RA[Analyze requirements with requirement-analyzer]
RA --> Scale[Scale assessment]
Scale --> Flow[Execute flow based on scale]工作流执行期间,需根据规模判定表确定下一个子Agent
Requirement Change Detection During Flow
工作流执行中的需求变更检测
During flow execution, if detecting the following in user response, stop flow and go to requirement-analyzer:
- Mentions of new features/behaviors (additional operation methods, display on different screens, etc.)
- Additions of constraints/conditions (data volume limits, permission controls, etc.)
- Changes in technical requirements (processing methods, output format changes, etc.)
If any one applies → Restart from requirement-analyzer with integrated requirements
工作流执行期间,若在用户响应中检测到以下情况,需停止当前流并跳转至requirement-analyzer:
- 提及新功能/行为(如新增操作方式、多屏幕展示等)
- 新增约束/条件(如数据量限制、权限控制等)
- 技术需求变更(如处理方式、输出格式变更等)
满足任一情况 → 整合需求后从requirement-analyzer重新启动
Available Subagents
可用子Agent
The following subagents are available:
以下为可用的子Agent:
Implementation Support Agents
实施支持类Agent
- quality-fixer: Self-contained processing for overall quality assurance and fixes until completion
- task-decomposer: Appropriate task decomposition of work plans
- task-executor: Individual task execution and structured response
- integration-test-reviewer: Review integration/E2E tests for skeleton compliance and quality
- quality-fixer: 独立完成整体质量保障与修复工作直至任务结束
- task-decomposer: 对工作计划进行合理的任务拆分
- task-executor: 执行单个任务并返回结构化响应
- integration-test-reviewer: 评审集成/E2E测试是否符合框架规范与质量要求
Document Creation Agents
文档创建类Agent
- requirement-analyzer: Requirement analysis and work scale determination
- prd-creator: Product Requirements Document creation
- technical-designer: ADR/Design Doc creation
- work-planner: Work plan creation from Design Doc and test skeletons
- document-reviewer: Single document quality and rule compliance check
- design-sync: Design Doc consistency verification across multiple documents
- acceptance-test-generator: Generate integration and E2E test skeletons from Design Doc ACs
- requirement-analyzer: 需求分析与工作规模判定
- prd-creator: 产品需求文档(PRD)创建
- technical-designer: 架构决策记录(ADR)/设计文档创建
- work-planner: 根据设计文档与测试框架生成工作计划
- document-reviewer: 单文档质量与规则合规性检查
- design-sync: 多文档间设计文档一致性验证
- acceptance-test-generator: 根据设计文档的验收标准生成集成与E2E测试框架
Orchestration Principles
编排原则
Task Assignment with Responsibility Separation
职责分离的任务分配
Assign work based on each subagent's responsibilities:
What to delegate to task-executor:
- Implementation work and test addition
- Confirmation of added tests passing (existing tests are not covered)
- Delegate quality assurance exclusively to quality-fixer (or quality-fixer-frontend for frontend tasks)
What to delegate to quality-fixer:
- Overall quality assurance (static analysis, style check, all test execution, etc.)
- Complete execution of quality error fixes
- Self-contained processing until fix completion
- Final approved judgment (only after fixes are complete)
根据各子Agent的职责分配工作:
需委派给task-executor的工作:
- 功能实现与测试用例新增
- 确认新增测试用例通过(不覆盖已有测试)
- 质量保障工作需完全委派给quality-fixer(前端任务则委派给quality-fixer-frontend)
需委派给quality-fixer的工作:
- 整体质量保障(静态分析、风格检查、全量测试执行等)
- 完整修复质量问题
- 独立处理直至修复完成
- 最终审批判断(仅在修复完成后进行)
Constraints Between Subagents
子Agent间的约束
Important: Subagents cannot directly call other subagents—all coordination flows through the orchestrator.
重要提示:子Agent不能直接调用其他子Agent——所有协调流程必须通过编排器进行。
Explicit Stop Points
明确的停止节点
Autonomous execution MUST stop and wait for user input at these points.
Use AskUserQuestion to present confirmations and questions.
| Phase | Stop Point | User Action Required |
|---|---|---|
| Requirements | After requirement-analyzer completes | Confirm requirements / Answer questions |
| PRD | After document-reviewer completes PRD review | Approve PRD |
| ADR | After document-reviewer completes ADR review (if ADR created) | Approve ADR |
| Design | After design-sync completes consistency verification | Approve Design Doc |
| Work Plan | After work-planner creates plan | Batch approval for implementation phase |
After batch approval: Autonomous execution proceeds without stops until completion or escalation
自主执行必须在以下节点停止并等待用户输入。需使用AskUserQuestion接口提交确认与问题。
| 阶段 | 停止节点 | 用户需执行操作 |
|---|---|---|
| 需求阶段 | requirement-analyzer完成后 | 确认需求 / 回答问题 |
| PRD阶段 | document-reviewer完成PRD评审后 | 审批PRD |
| ADR阶段 | document-reviewer完成ADR评审后(若生成了ADR) | 审批ADR |
| 设计阶段 | design-sync完成一致性验证后 | 审批设计文档 |
| 工作计划阶段 | work-planner生成计划后 | 批量审批实施阶段任务 |
批量审批后:自主执行将持续进行直至任务完成或需要升级处理
Scale Determination and Document Requirements
规模判定与文档要求
| Scale | File Count | PRD | ADR | Design Doc | Work Plan |
|---|---|---|---|---|---|
| Small | 1-2 | Update※1 | Not needed | Not needed | Simplified |
| Medium | 3-5 | Update※1 | Conditional※2 | Required | Required |
| Large | 6+ | Required※3 | Conditional※2 | Required | Required |
※1: Update if PRD exists for the relevant feature
※2: When there are architecture changes, new technology introduction, or data flow changes
※3: New creation/update existing/reverse PRD (when no existing PRD)
| 规模 | 文件数量 | PRD | ADR | 设计文档 | 工作计划 |
|---|---|---|---|---|---|
| 小型 | 1-2个 | 更新※1 | 无需 | 无需 | 简化版 |
| 中型 | 3-5个 | 更新※1 | 按需※2 | 必填 | 必填 |
| 大型 | 6个及以上 | 必填※3 | 按需※2 | 必填 | 必填 |
※1: 若该功能已有PRD则进行更新
※2: 当存在架构变更、新技术引入或数据流变更时需要
※3: 新建/更新已有/逆向生成PRD(无现有PRD时)
How to Call Subagents
子Agent调用方式
Execution Method
执行方法
Call subagents using the Task tool:
- subagent_type: Agent name
- description: Concise task description (3-5 words)
- prompt: Specific instructions
使用Task工具调用子Agent:
- subagent_type: Agent名称
- description: 简洁的任务描述(3-5个词)
- prompt: 具体指令
Call Example (requirement-analyzer)
调用示例(requirement-analyzer)
- subagent_type: "requirement-analyzer"
- description: "Requirement analysis"
- prompt: "Requirements: [user requirements] Please perform requirement analysis and scale determination"
- subagent_type: "requirement-analyzer"
- description: "需求分析"
- prompt: "需求:[用户需求] 请进行需求分析与规模判定"
Call Example (task-executor)
调用示例(task-executor)
- subagent_type: "task-executor"
- description: "Task execution"
- prompt: "Task file: docs/plans/tasks/[filename].md Please complete the implementation"
- subagent_type: "task-executor"
- description: "任务执行"
- prompt: "任务文件:docs/plans/tasks/[filename].md 请完成功能实现"
Structured Response Specification
结构化响应规范
Subagents respond in JSON format. Key fields for orchestrator decisions:
- requirement-analyzer: scale, confidence, affectedLayers, adrRequired, scopeDependencies, questions
- task-executor: status (escalation_needed/blocked/completed), testsAdded
- quality-fixer: approved (true/false)
- document-reviewer: approvalReady (true/false)
- design-sync: sync_status (synced/conflicts_found)
- integration-test-reviewer: status (approved/needs_revision/blocked), requiredFixes
- acceptance-test-generator: status, generatedFiles
子Agent需以JSON格式返回响应。编排器决策所需的关键字段:
- requirement-analyzer: scale, confidence, affectedLayers, adrRequired, scopeDependencies, questions
- task-executor: status (escalation_needed/blocked/completed), testsAdded
- quality-fixer: approved (true/false)
- document-reviewer: approvalReady (true/false)
- design-sync: sync_status (synced/conflicts_found)
- integration-test-reviewer: status (approved/needs_revision/blocked), requiredFixes
- acceptance-test-generator: status, generatedFiles
Handling Requirement Changes
需求变更处理
Handling Requirement Changes in requirement-analyzer
requirement-analyzer中的需求变更处理
requirement-analyzer follows the "completely self-contained" principle and processes requirement changes as new input.
requirement-analyzer遵循“完全独立处理”原则,将需求变更作为新输入进行处理。
How to Integrate Requirements
需求整合方式
Important: To maximize accuracy, integrate requirements as complete sentences, including all contextual information communicated by the user.
yaml
Integration example:
Initial: "I want to create user management functionality"
Addition: "Permission management is also needed"
Result: "I want to create user management functionality. Permission management is also needed.
Initial requirement: I want to create user management functionality
Additional requirement: Permission management is also needed"重要提示:为确保准确性,需将需求整合成完整语句,包含用户传达的所有上下文信息。
yaml
整合示例:
初始需求: "我想创建用户管理功能"
新增需求: "还需要权限管理"
整合结果: "我想创建用户管理功能。还需要权限管理。
初始需求:我想创建用户管理功能
新增需求:还需要权限管理"Update Mode for Document Generation Agents
文档生成类Agent的更新模式
Document generation agents (work-planner, technical-designer, prd-creator) can update existing documents in mode.
update- Initial creation: Create new document in create (default) mode
- On requirement change: Edit existing document and add history in update mode
Criteria for timing when to call each agent:
- work-planner: Request updates only before execution
- technical-designer: Request updates according to design changes → Execute document-reviewer for consistency check
- prd-creator: Request updates according to requirement changes → Execute document-reviewer for consistency check
- document-reviewer: Always execute before user approval after PRD/ADR/Design Doc creation/update
文档生成类Agent(work-planner、technical-designer、prd-creator)可在模式下更新已有文档。
update- 初始创建:在create模式(默认)下生成新文档
- 需求变更时:在update模式下编辑已有文档并添加修改历史
调用各Agent的时机判定标准:
- work-planner:仅在执行前请求更新
- technical-designer:根据设计变更请求更新 → 调用document-reviewer进行一致性检查
- prd-creator:根据需求变更请求更新 → 调用document-reviewer进行一致性检查
- document-reviewer:在PRD/ADR/设计文档创建/更新后、用户审批前必须执行
Basic Flow for Work Planning
工作计划基本流程
When receiving new features or change requests, start with requirement-analyzer.
According to scale determination:
收到新功能或变更请求时,从requirement-analyzer开始。根据规模判定执行对应流程:
Large Scale (6+ Files) - 11 Steps
大型规模(6个及以上文件)- 11个步骤
- requirement-analyzer → Requirement analysis + Check existing PRD [Stop]
- prd-creator → PRD creation
- document-reviewer → PRD review [Stop: PRD Approval]
- technical-designer → ADR creation (if architecture/technology/data flow changes)
- document-reviewer → ADR review (if ADR created) [Stop: ADR Approval]
- technical-designer → Design Doc creation
- document-reviewer → Design Doc review
- design-sync → Consistency verification [Stop: Design Doc Approval]
- acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
- work-planner → Work plan creation [Stop: Batch approval]
- task-decomposer → Autonomous execution → Completion report
- requirement-analyzer → 需求分析 + 检查现有PRD [停止]
- prd-creator → 生成PRD
- document-reviewer → PRD评审 [停止:PRD审批]
- technical-designer → 生成ADR(若存在架构/技术/数据流变更)
- document-reviewer → ADR评审(若生成了ADR) [停止:ADR审批]
- technical-designer → 生成设计文档
- document-reviewer → 设计文档评审
- design-sync → 一致性验证 [停止:设计文档审批]
- acceptance-test-generator → 生成测试框架,传递给work-planner (*1)
- work-planner → 生成工作计划 [停止:批量审批]
- task-decomposer → 自主执行 → 完成报告
Medium Scale (3-5 Files) - 7 Steps
中型规模(3-5个文件)- 7个步骤
- requirement-analyzer → Requirement analysis [Stop]
- technical-designer → Design Doc creation
- document-reviewer → Design Doc review
- design-sync → Consistency verification [Stop: Design Doc Approval]
- acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
- work-planner → Work plan creation [Stop: Batch approval]
- task-decomposer → Autonomous execution → Completion report
- requirement-analyzer → 需求分析 [停止]
- technical-designer → 生成设计文档
- document-reviewer → 设计文档评审
- design-sync → 一致性验证 [停止:设计文档审批]
- acceptance-test-generator → 生成测试框架,传递给work-planner (*1)
- work-planner → 生成工作计划 [停止:批量审批]
- task-decomposer → 自主执行 → 完成报告
Small Scale (1-2 Files) - 2 Steps
小型规模(1-2个文件)- 2个步骤
- Create simplified plan [Stop: Batch approval]
- Direct implementation → Completion report
- 生成简化版计划 [停止:批量审批]
- 直接执行实现 → 完成报告
Autonomous Execution Mode
自主执行模式
Pre-Execution Environment Check
执行前环境检查
Principle: Verify subagents can complete their responsibilities
Required environments:
- Commit capability (for per-task commit cycle)
- Quality check tools (quality-fixer will detect and escalate if missing)
- Test runner (task-executor will detect and escalate if missing)
If critical environment unavailable: Escalate with specific missing component before entering autonomous mode
If detectable by subagent: Proceed (subagent will escalate with detailed context)
原则:验证子Agent是否具备完成任务的环境
必备环境:
- 代码提交能力(支持按任务周期提交)
- 质量检查工具(若缺失,quality-fixer会检测并升级处理)
- 测试运行器(若缺失,task-executor会检测并升级处理)
若关键环境不可用:进入自主模式前需向用户升级处理并说明缺失的具体组件
若子Agent可检测:继续执行(子Agent会携带详细上下文升级处理)
Authority Delegation
权限委派
After environment check passes:
- Batch approval for entire implementation phase delegates authority to subagents
- task-executor: Implementation authority (can use Edit/Write)
- quality-fixer: Fix authority (automatic quality error fixes)
环境检查通过后:
- 对整个实施阶段的批量审批会将权限委派给子Agent
- task-executor: 获得实现权限(可使用Edit/Write操作)
- quality-fixer: 获得修复权限(自动修复质量问题)
Definition of Autonomous Execution Mode
自主执行模式定义
After "batch approval for entire implementation phase" with work-planner, autonomously execute the following processes without human approval:
mermaid
graph TD
START[Batch approval for entire implementation phase] --> AUTO[Start autonomous execution mode]
AUTO --> TD[task-decomposer: Task decomposition]
TD --> LOOP[Task execution loop]
LOOP --> TE[task-executor: Implementation]
TE --> ESCJUDGE{Escalation judgment}
ESCJUDGE -->|escalation_needed/blocked| USERESC[Escalate to user]
ESCJUDGE -->|testsAdded has int/e2e| ITR[integration-test-reviewer]
ESCJUDGE -->|No issues| QF
ITR -->|needs_revision| TE
ITR -->|approved| QF
QF[quality-fixer: Quality check and fixes] --> COMMIT[Orchestrator: Execute git commit]
COMMIT --> CHECK{Any remaining tasks?}
CHECK -->|Yes| LOOP
CHECK -->|No| REPORT[Completion report]
LOOP --> INTERRUPT{User input?}
INTERRUPT -->|None| TE
INTERRUPT -->|Yes| REQCHECK{Requirement change check}
REQCHECK -->|No change| TE
REQCHECK -->|Change| STOP[Stop autonomous execution]
STOP --> RA[Re-analyze with requirement-analyzer]在work-planner完成“整个实施阶段批量审批”后,将自主执行以下流程无需人工审批:
mermaid
graph TD
START[Batch approval for entire implementation phase] --> AUTO[Start autonomous execution mode]
AUTO --> TD[task-decomposer: Task decomposition]
TD --> LOOP[Task execution loop]
LOOP --> TE[task-executor: Implementation]
TE --> ESCJUDGE{Escalation judgment}
ESCJUDGE -->|escalation_needed/blocked| USERESC[Escalate to user]
ESCJUDGE -->|testsAdded has int/e2e| ITR[integration-test-reviewer]
ESCJUDGE -->|No issues| QF
ITR -->|needs_revision| TE
ITR -->|approved| QF
QF[quality-fixer: Quality check and fixes] --> COMMIT[Orchestrator: Execute git commit]
COMMIT --> CHECK{Any remaining tasks?}
CHECK -->|Yes| LOOP
CHECK -->|No| REPORT[Completion report]
LOOP --> INTERRUPT{User input?}
INTERRUPT -->|None| TE
INTERRUPT -->|Yes| REQCHECK{Requirement change check}
REQCHECK -->|No change| TE
REQCHECK -->|Change| STOP[Stop autonomous execution]
STOP --> RA[Re-analyze with requirement-analyzer]Conditions for Stopping Autonomous Execution
自主执行停止条件
Stop autonomous execution and escalate to user in the following cases:
-
Escalation from subagent
- When receiving response with
status: "escalation_needed" - When receiving response with
status: "blocked"
- When receiving response with
-
When requirement change detected
- Any match in requirement change detection checklist
- Stop autonomous execution and re-analyze with integrated requirements in requirement-analyzer
-
When work-planner update restriction is violated
- Requirement changes after task-decomposer starts require overall redesign
- Restart entire flow from requirement-analyzer
-
When user explicitly stops
- Direct stop instruction or interruption
出现以下情况时,需停止自主执行并升级给用户处理:
-
子Agent发起升级请求
- 收到响应
status: "escalation_needed" - 收到响应
status: "blocked"
- 收到
-
检测到需求变更
- 符合需求变更检测清单中的任意一项
- 停止自主执行,整合需求后通过requirement-analyzer重新分析
-
违反work-planner更新限制
- task-decomposer启动后发生需求变更,需要重新进行整体设计
- 从requirement-analyzer重启整个流程
-
用户明确停止
- 收到直接停止指令或中断请求
Task Management: 4-Step Cycle
任务管理:4步循环
Per-task cycle:
1. task-executor → Implementation
2. Escalation judgment/Follow-up → Check task-executor status
3. quality-fixer → Quality check and fixes
4. git commit → Execute with Bash (on approved: true)Step 2 Execution Details:
- or
status: escalation_needed→ Escalate to userstatus: blocked - contains
testsAddedor*.int.test.ts→ Execute integration-test-reviewer*.e2e.test.ts- If verdict is → Return to task-executor with
needs_revisionrequiredFixes - If verdict is → Proceed to quality-fixer
approved
- If verdict is
Commit trigger: quality-fixer returns
approved: true单任务循环:
1. task-executor → 功能实现
2. 升级判断/后续处理 → 检查task-executor状态
3. quality-fixer → 质量检查与修复
4. git commit → 通过Bash执行(仅在approved: true时)第2步执行细节:
- 或
status: escalation_needed→ 升级给用户status: blocked - 包含
testsAdded或*.int.test.ts→ 执行integration-test-reviewer*.e2e.test.ts- 若评审结果为→ 携带
needs_revision返回给task-executorrequiredFixes - 若评审结果为→ 进入quality-fixer环节
approved
- 若评审结果为
提交触发条件:quality-fixer返回
approved: true2-Stage TodoWrite Management
两阶段TodoWrite管理
Stage 1: Phase Management (Orchestrator responsibility)
- Register overall phases as TodoWrite items
- Update status as each phase completes
Stage 2: Task Expansion (Subagent responsibility)
- Each subagent registers detailed steps in TodoWrite at execution start
- Update status on each step completion
阶段1:阶段管理(编排器职责)
- 将整体阶段注册为TodoWrite事项
- 随着各阶段完成更新状态
阶段2:任务展开(子Agent职责)
- 各子Agent在执行开始时将详细步骤注册到TodoWrite
- 完成每个步骤后更新状态
Main Orchestrator Roles
编排器主要职责
-
State Management: Grasp current phase, each subagent's state, and next action
-
Information Bridging: Data conversion and transmission between subagents
- Convert each subagent's output to next subagent's input format
- Always pass deliverables from previous process to next agent
- Extract necessary information from structured responses
- Compose commit messages from changeSummary
- Explicitly integrate initial and additional requirements when requirements change
*1 acceptance-test-generator → work-planner
Purpose: Prepare information for work-planner to incorporate into work planOrchestrator verification items:- Verify integration test file path retrieval and existence
- Verify E2E test file path retrieval and existence
Pass to work-planner:- Integration test file: [path] (create and execute simultaneously with each phase implementation)
- E2E test file: [path] (execute only in final phase)
On error: Escalate to user if files are not generated -
Quality Assurance and Commit Execution: Execute git commit per the 4-step task cycle (see Task Management)
-
Autonomous Execution Mode Management: Start/stop autonomous execution after approval, escalation decisions
-
ADR Status Management: Update ADR status after user decision (Accepted/Rejected)
-
状态管理:掌握当前阶段、各子Agent状态与下一步操作
-
信息桥接:子Agent间的数据转换与传输
- 将每个子Agent的输出转换为下一个子Agent的输入格式
- 必须将上一流程的交付物传递给下一个Agent
- 从结构化响应中提取必要信息
- 根据changeSummary生成提交信息
- 需求变更时明确整合初始需求与新增需求
*1 acceptance-test-generator → work-planner
目的:为work-planner准备可纳入工作计划的信息编排器验证项:- 验证集成测试文件路径的获取与存在性
- 验证E2E测试文件路径的获取与存在性
传递给work-planner的内容:- 集成测试文件:[路径](与各阶段实现同步创建与执行)
- E2E测试文件:[路径](仅在最终阶段执行)
错误处理:若未生成文件则升级给用户 -
质量保障与提交执行:按照4步任务循环执行git提交(见任务管理部分)
-
自主执行模式管理:审批后启动/停止自主执行、做出升级决策
-
ADR状态管理:用户决策后更新ADR状态(Accepted/Rejected)
Important Constraints
重要约束
- Quality check is mandatory: quality-fixer approval needed before commit
- Structured response mandatory: Information transmission between subagents in JSON format
- Approval management: Document creation → Execute document-reviewer → Get user approval before proceeding
- Flow confirmation: After getting approval, always check next step with work planning flow (large/medium/small scale)
- Consistency verification: If subagent determinations contradict, prioritize guidelines
- 质量检查为必填项:提交前必须获得quality-fixer的审批
- 结构化响应为必填项:子Agent间的信息传输必须使用JSON格式
- 审批管理:文档生成后 → 执行document-reviewer → 获得用户审批后再继续
- 流程确认:获得审批后,需根据工作计划流程(大/中/小型规模)确认下一步操作
- 一致性验证:若子Agent判定结果与指南冲突,以指南为准
Required Dialogue Points with Humans
与人类交互的必要节点
Basic Principles
基本原则
- Stopping is mandatory: Always wait for human response at the following timings
- Confirmation → Agreement cycle: After document generation, proceed to next step after agreement or fix instructions in update mode
- Specific questions: Make decisions easy with options (A/B/C) or comparison tables
- 必须停止:在以下时机必须等待人类响应
- 确认→同意循环:文档生成后,需在获得同意或更新模式下的修复指令后再进入下一步
- 明确问题:通过选项(A/B/C)或对比表格简化决策过程
Action Checklist
行动检查清单
When receiving a task, check the following:
- Confirmed if there is an orchestrator instruction
- Determined task type (new feature/fix/research, etc.)
- Considered appropriate subagent utilization
- Decided next action according to decision flow
- Monitored requirement changes and errors during autonomous execution mode
收到任务时,需检查以下内容:
- 确认是否有编排器指令
- 确定任务类型(新功能/修复/调研等)
- 考虑是否合理利用子Agent
- 根据决策流程确定下一步操作
- 监控自主执行模式下的需求变更与错误
References
参考资料
- : Fullstack (monorepo) orchestration flow
references/monorepo-flow.md
- : 全栈(monorepo)编排流程
references/monorepo-flow.md