subagents-orchestration-guide

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Subagents 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

自动响应规则

TriggerAction
New taskInvoke requirement-analyzer
Flow in progressCheck scale determination table for next subagent
Phase completionDelegate to the appropriate subagent
Stop point reachedWait 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

  1. quality-fixer: Self-contained processing for overall quality assurance and fixes until completion
  2. task-decomposer: Appropriate task decomposition of work plans
  3. task-executor: Individual task execution and structured response
  4. integration-test-reviewer: Review integration/E2E tests for skeleton compliance and quality
  1. quality-fixer: 独立完成整体质量保障与修复工作直至任务结束
  2. task-decomposer: 对工作计划进行合理的任务拆分
  3. task-executor: 执行单个任务并返回结构化响应
  4. integration-test-reviewer: 评审集成/E2E测试是否符合框架规范与质量要求

Document Creation Agents

文档创建类Agent

  1. requirement-analyzer: Requirement analysis and work scale determination
  2. prd-creator: Product Requirements Document creation
  3. technical-designer: ADR/Design Doc creation
  4. work-planner: Work plan creation from Design Doc and test skeletons
  5. document-reviewer: Single document quality and rule compliance check
  6. design-sync: Design Doc consistency verification across multiple documents
  7. acceptance-test-generator: Generate integration and E2E test skeletons from Design Doc ACs
  1. requirement-analyzer: 需求分析与工作规模判定
  2. prd-creator: 产品需求文档(PRD)创建
  3. technical-designer: 架构决策记录(ADR)/设计文档创建
  4. work-planner: 根据设计文档与测试框架生成工作计划
  5. document-reviewer: 单文档质量与规则合规性检查
  6. design-sync: 多文档间设计文档一致性验证
  7. 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.
PhaseStop PointUser Action Required
RequirementsAfter requirement-analyzer completesConfirm requirements / Answer questions
PRDAfter document-reviewer completes PRD reviewApprove PRD
ADRAfter document-reviewer completes ADR review (if ADR created)Approve ADR
DesignAfter design-sync completes consistency verificationApprove Design Doc
Work PlanAfter work-planner creates planBatch 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

规模判定与文档要求

ScaleFile CountPRDADRDesign DocWork Plan
Small1-2Update※1Not neededNot neededSimplified
Medium3-5Update※1Conditional※2RequiredRequired
Large6+Required※3Conditional※2RequiredRequired
※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)
规模文件数量PRDADR设计文档工作计划
小型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
update
mode.
  • 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个步骤

  1. requirement-analyzer → Requirement analysis + Check existing PRD [Stop]
  2. prd-creator → PRD creation
  3. document-reviewer → PRD review [Stop: PRD Approval]
  4. technical-designer → ADR creation (if architecture/technology/data flow changes)
  5. document-reviewer → ADR review (if ADR created) [Stop: ADR Approval]
  6. technical-designer → Design Doc creation
  7. document-reviewer → Design Doc review
  8. design-sync → Consistency verification [Stop: Design Doc Approval]
  9. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
  10. work-planner → Work plan creation [Stop: Batch approval]
  11. task-decomposer → Autonomous execution → Completion report
  1. requirement-analyzer → 需求分析 + 检查现有PRD [停止]
  2. prd-creator → 生成PRD
  3. document-reviewer → PRD评审 [停止:PRD审批]
  4. technical-designer → 生成ADR(若存在架构/技术/数据流变更)
  5. document-reviewer → ADR评审(若生成了ADR) [停止:ADR审批]
  6. technical-designer → 生成设计文档
  7. document-reviewer → 设计文档评审
  8. design-sync → 一致性验证 [停止:设计文档审批]
  9. acceptance-test-generator → 生成测试框架,传递给work-planner (*1)
  10. work-planner → 生成工作计划 [停止:批量审批]
  11. task-decomposer → 自主执行 → 完成报告

Medium Scale (3-5 Files) - 7 Steps

中型规模(3-5个文件)- 7个步骤

  1. requirement-analyzer → Requirement analysis [Stop]
  2. technical-designer → Design Doc creation
  3. document-reviewer → Design Doc review
  4. design-sync → Consistency verification [Stop: Design Doc Approval]
  5. acceptance-test-generator → Test skeleton generation, pass to work-planner (*1)
  6. work-planner → Work plan creation [Stop: Batch approval]
  7. task-decomposer → Autonomous execution → Completion report
  1. requirement-analyzer → 需求分析 [停止]
  2. technical-designer → 生成设计文档
  3. document-reviewer → 设计文档评审
  4. design-sync → 一致性验证 [停止:设计文档审批]
  5. acceptance-test-generator → 生成测试框架,传递给work-planner (*1)
  6. work-planner → 生成工作计划 [停止:批量审批]
  7. task-decomposer → 自主执行 → 完成报告

Small Scale (1-2 Files) - 2 Steps

小型规模(1-2个文件)- 2个步骤

  1. Create simplified plan [Stop: Batch approval]
  2. Direct implementation → Completion report
  1. 生成简化版计划 [停止:批量审批]
  2. 直接执行实现 → 完成报告

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:
  1. Escalation from subagent
    • When receiving response with
      status: "escalation_needed"
    • When receiving response with
      status: "blocked"
  2. When requirement change detected
    • Any match in requirement change detection checklist
    • Stop autonomous execution and re-analyze with integrated requirements in requirement-analyzer
  3. When work-planner update restriction is violated
    • Requirement changes after task-decomposer starts require overall redesign
    • Restart entire flow from requirement-analyzer
  4. When user explicitly stops
    • Direct stop instruction or interruption
出现以下情况时,需停止自主执行并升级给用户处理:
  1. 子Agent发起升级请求
    • 收到
      status: "escalation_needed"
      响应
    • 收到
      status: "blocked"
      响应
  2. 检测到需求变更
    • 符合需求变更检测清单中的任意一项
    • 停止自主执行,整合需求后通过requirement-analyzer重新分析
  3. 违反work-planner更新限制
    • task-decomposer启动后发生需求变更,需要重新进行整体设计
    • 从requirement-analyzer重启整个流程
  4. 用户明确停止
    • 收到直接停止指令或中断请求

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:
  • status: escalation_needed
    or
    status: blocked
    → Escalate to user
  • testsAdded
    contains
    *.int.test.ts
    or
    *.e2e.test.ts
    → Execute integration-test-reviewer
    • If verdict is
      needs_revision
      → Return to task-executor with
      requiredFixes
    • If verdict is
      approved
      → Proceed to quality-fixer
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
    *.e2e.test.ts
    → 执行integration-test-reviewer
    • 若评审结果为
      needs_revision
      → 携带
      requiredFixes
      返回给task-executor
    • 若评审结果为
      approved
      → 进入quality-fixer环节
提交触发条件:quality-fixer返回
approved: true

2-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

编排器主要职责

  1. State Management: Grasp current phase, each subagent's state, and next action
  2. 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 plan
    Orchestrator 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
  3. Quality Assurance and Commit Execution: Execute git commit per the 4-step task cycle (see Task Management)
  4. Autonomous Execution Mode Management: Start/stop autonomous execution after approval, escalation decisions
  5. ADR Status Management: Update ADR status after user decision (Accepted/Rejected)
  1. 状态管理:掌握当前阶段、各子Agent状态与下一步操作
  2. 信息桥接:子Agent间的数据转换与传输
    • 将每个子Agent的输出转换为下一个子Agent的输入格式
    • 必须将上一流程的交付物传递给下一个Agent
    • 从结构化响应中提取必要信息
    • 根据changeSummary生成提交信息
    • 需求变更时明确整合初始需求与新增需求

    *1 acceptance-test-generator → work-planner

    目的:为work-planner准备可纳入工作计划的信息
    编排器验证项:
    • 验证集成测试文件路径的获取与存在性
    • 验证E2E测试文件路径的获取与存在性
    传递给work-planner的内容:
    • 集成测试文件:[路径](与各阶段实现同步创建与执行)
    • E2E测试文件:[路径](仅在最终阶段执行)
    错误处理:若未生成文件则升级给用户
  3. 质量保障与提交执行:按照4步任务循环执行git提交(见任务管理部分)
  4. 自主执行模式管理:审批后启动/停止自主执行、做出升级决策
  5. 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

参考资料

  • references/monorepo-flow.md
    : Fullstack (monorepo) orchestration flow
  • references/monorepo-flow.md
    : 全栈(monorepo)编排流程