task-orchestration

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Resources

资源

scripts/
  validate-orchestration.sh
references/
  agent-assignment-guide.md

scripts/
  validate-orchestration.sh
references/
  agent-assignment-guide.md

Task Orchestration Protocol

任务编排协议

The task orchestration protocol defines how the GoodVibes orchestrator decomposes feature requests into agent tasks, assigns agents and skills, manages parallel execution, and coordinates WRFC loops. This is the orchestrator's primary workflow for multi-agent feature delivery.

本任务编排协议定义了GoodVibes编排器如何将功能请求分解为Agent任务、分配Agent与技能、管理并行执行以及协调WRFC循环。这是编排器用于多Agent功能交付的核心工作流。

When to Use This Skill

何时使用该技能

Use this skill when:

User provides a feature request requiring multiple work streams
Request involves multiple domains (backend, frontend, database, etc.)
Request can be parallelized into independent subtasks
Request requires coordination across multiple agents

Do NOT use this skill for:

Simple single-file edits (handle directly)
Pure analysis tasks without code changes
Tasks already decomposed by the user

在以下场景使用本技能：

用户提出的功能请求需要多个工作流并行处理
请求涉及多个领域（后端、前端、数据库等）
请求可拆分为独立的子任务并行执行
请求需要多个Agent之间的协调

请勿在以下场景使用本技能：

简单的单文件编辑（直接处理即可）
无需修改代码的纯分析任务
用户已完成分解的任务

Decomposition Process

分解流程

Step 1: Classify the Request

步骤1：对请求进行分类

Before decomposing, classify the request into one of these categories:

Feature Implementation - Add new functionality

Identify: "Add X feature", "Implement Y", "Create Z capability"
Decomposition strategy: Split by domain (API, UI, DB, types)
Parallelism: High (most work streams independent)

Bug Fix - Resolve existing issue

Identify: "Fix X not working", "Resolve Y error", "Correct Z behavior"
Decomposition strategy: Root cause first, then fix propagation
Parallelism: Low (diagnosis must precede fixes)

Refactoring - Improve code structure without changing behavior

Identify: "Refactor X", "Restructure Y", "Extract Z"
Decomposition strategy: Analysis first, then file-by-file changes
Parallelism: Medium (analysis sequential, changes parallel)

Integration - Connect existing systems

Identify: "Integrate X with Y", "Connect A to B"
Decomposition strategy: Understand both sides, then adapter layer
Parallelism: Medium (research parallel, integration sequential)

Enhancement - Improve existing feature

Identify: "Improve X", "Add Y to existing Z"
Decomposition strategy: Understand current state, plan incremental additions
Parallelism: Medium (discovery sequential, additions parallel)

在分解之前，将请求归类为以下类别之一：

功能实现 - 添加新功能

识别关键词：“添加X功能”“实现Y”“创建Z能力”
分解策略：按领域拆分（API、UI、数据库、类型定义等）
并行度：高（大多数工作流相互独立）

Bug修复 - 解决现有问题

识别关键词：“修复X无法正常工作的问题”“解决Y错误”“修正Z行为”
分解策略：先定位根本原因，再进行修复
并行度：低（诊断必须先于修复）

代码重构 - 优化代码结构但不改变功能

识别关键词：“重构X”“调整Y的结构”“提取Z”
分解策略：先分析，再按文件逐一修改
并行度：中等（分析阶段为串行，修改阶段可并行）

系统集成 - 连接现有系统

识别关键词：“将X与Y集成”“连接A和B”
分解策略：先了解双方系统，再构建适配层
并行度：中等（调研阶段可并行，集成阶段为串行）

功能增强 - 优化现有功能

识别关键词：“改进X”“为现有Z添加Y”
分解策略：先了解当前状态，再规划增量式添加
并行度：中等（探索阶段为串行，添加阶段可并行）

Step 2: Identify Parallel Opportunities

步骤2：识别并行机会

After classifying, identify work that can run in parallel:

Independent domains:

API route + React component (if contract is defined upfront)
Type definitions + database schema
Multiple UI components with shared types
Multiple API endpoints with shared middleware

Independent files:

Creating new files in different directories
Editing files with no import relationships
Writing tests for different modules

Independent research:

Checking multiple documentation sources
Analyzing multiple files for patterns
Discovering patterns in different directories

When NOT to parallelize:

Type definitions must exist before implementation uses them
Database schema must exist before API queries it
Parent component must exist before child imports it
Discovery must complete before planning

分类完成后，识别可并行处理的工作：

独立领域：

API路由 + React组件（如果契约已预先定义）
TypeScript类型定义 + 数据库模式
共享类型的多个UI组件
共享中间件的多个API端点

独立文件：

在不同目录中创建新文件
修改无导入依赖关系的文件
为不同模块编写测试

独立调研：

查阅多个文档来源
分析多个文件的模式
探索不同目录中的模式

不可并行的场景：

类型定义必须先于实现代码存在
数据库模式必须先于API查询存在
父组件必须先于子组件导入存在
探索阶段必须先于规划阶段完成

Step 3: Define Agent Tasks

步骤3：定义Agent任务

For each parallelizable work stream, define a task with:

Task structure:

yaml

task_id: unique-task-identifier
agent: engineer | reviewer | tester | architect | deployer | integrator-ai | integrator-services | integrator-state | planner
skills: [skill-1, skill-2]
description: Brief description of what this task accomplishes
scope:
  files: [list of files to create/modify]
  directories: [directories to work within]
constraints:
  - Must use TypeScript
  - Follow existing patterns in src/features/
blocking: [list of task_ids this task blocks]
blocked_by: [list of task_ids blocking this task]
expected_outcome: What success looks like

Example:

yaml

task_id: create-user-types
agent: engineer
skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory]
description: Create TypeScript type definitions for User domain
scope:
  files: [src/types/user.ts, src/types/auth.ts]
  directories: [src/types]
constraints:
  - Use Zod for runtime validation
  - Export all types from src/types/index.ts
blocking: [create-user-api, create-user-components]
blocked_by: []
expected_outcome: Type files exist, export User, AuthContext, and validation schemas

针对每个可并行的工作流，定义包含以下内容的任务：

任务结构：

yaml

task_id: 唯一任务标识符
agent: engineer | reviewer | tester | architect | deployer | integrator-ai | integrator-services | integrator-state | planner
skills: [skill-1, skill-2]
description: 任务目标的简要描述
scope:
  files: [需要创建/修改的文件列表]
  directories: [工作目录列表]
constraints:
  - 必须使用TypeScript
  - 遵循src/features/中的现有模式
blocking: [当前任务所阻塞的task_id列表]
blocked_by: [阻塞当前任务的task_id列表]
expected_outcome: 成功的判定标准

示例：

yaml

task_id: create-user-types
agent: engineer
skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory]
description: 为用户领域创建TypeScript类型定义
scope:
  files: [src/types/user.ts, src/types/auth.ts]
  directories: [src/types]
constraints:
  - 使用Zod进行运行时验证
  - 从src/types/index.ts导出所有类型
blocking: [create-user-api, create-user-components]
blocked_by: []
expected_outcome: 类型文件已创建，导出User、AuthContext和验证模式

Step 4: Assign Agent and Skills

步骤4：分配Agent与技能

For each task, assign the appropriate agent type and skills using this decision table:

Agent Type Selection:

Work Type	Agent Type	Rationale
Implement API, components, features	engineer	Code creation and implementation
Review code quality, standards	reviewer	Code quality and standards enforcement
Write tests, test coverage	tester	Testing and validation
Plan architecture, design decisions	architect	High-level design and planning
Deploy applications, infrastructure	deployer	Deployment and infrastructure
Integrate AI/ML services	integrator-ai	AI/ML integration
Integrate external services	integrator-services	External service integration
Manage state and data flow	integrator-state	State management
Coordinate complex workflows	planner	High-level orchestration

Skills Assignment:

All agents receive protocol skills by default:

discover-plan-batch (DPB loop)
precision-mastery (tool usage)
error-recovery (error handling)
goodvibes-memory (memory integration)

Additional skills by work type:

Work Type	Additional Skills
API implementation	trpc, prisma, nextauth, rest-api-design
Frontend components	react, nextjs, tailwindcss, shadcn-ui
Database schema	prisma, postgresql, drizzle
Authentication	clerk, nextauth, lucia
Type definitions	(none - protocol skills sufficient)
Code review	review-scoring + domain-specific review skills

See

references/agent-assignment-guide.md

for complete assignment table.

使用以下决策表为每个任务分配合适的Agent类型和技能：

Agent类型选择：

工作类型	Agent类型	理由
实现API、组件、功能	engineer	代码创建与实现
代码质量、标准审核	reviewer	代码质量与标准执行
编写测试、测试覆盖	tester	测试与验证
架构规划、设计决策	architect	高层设计与规划
应用部署、基础设施	deployer	部署与基础设施管理
集成AI/ML服务	integrator-ai	AI/ML集成
集成外部服务	integrator-services	外部服务集成
状态与数据流管理	integrator-state	状态管理
复杂工作流协调	planner	高层编排

技能分配：

所有Agent默认具备以下协议技能：

discover-plan-batch（发现-规划-批量处理）
precision-mastery（精准操作）
error-recovery（错误恢复）
goodvibes-memory（GoodVibes记忆）

按工作类型添加额外技能：

工作类型	额外技能
API实现	trpc, prisma, nextauth, rest-api-design
前端组件	react, nextjs, tailwindcss, shadcn-ui
数据库模式	prisma, postgresql, drizzle
身份验证	clerk, nextauth, lucia
类型定义	（无 - 协议技能已足够）
代码审核	review-scoring + 领域特定审核技能

完整的分配表格请参考

references/agent-assignment-guide.md

。

Agent Prompt Template

Agent提示模板

When spawning agents, ALWAYS include these elements in the agent prompt:

markdown

undefined

在生成Agent时，必须在提示中包含以下元素：

markdown

undefined

Task

任务

[Specific, actionable description of what to accomplish]

[具体、可执行的任务描述]

Scope

范围

Files to create:

path/to/file.ts - Brief description

Files to modify:

path/to/existing.ts - What changes to make

Directories in scope:

src/features/auth/ - Work within this directory

需要创建的文件：

path/to/file.ts - 简要描述

需要修改的文件：

path/to/existing.ts - 具体修改内容

工作目录：

src/features/auth/ - 在此目录内工作

Constraints

约束

[Technical constraint 1]
[Pattern to follow]
[Dependency requirement]

[技术约束1]
[需遵循的模式]
[依赖要求]

Skills Available

可用技能

skill-name - When to use it
skill-name - When to use it

skill-name - 使用场景
skill-name - 使用场景

Expected Outcome

预期结果

[Concrete definition of success]

[具体的成功标准]

Blocking/Blocked By

阻塞/被阻塞关系

This task blocks: [list of downstream tasks waiting for this] This task is blocked by: [list of upstream tasks this waits for]

当前任务阻塞： [等待当前任务完成的下游任务列表] 当前任务被阻塞： [当前任务等待完成的上游任务列表]

WRFC Participation

WRFC循环参与

You are participating in a WRFC loop coordinated by the orchestrator:

WRITE: Complete your assigned task
REPORT: Use the structured output format below
The orchestrator will handle FIX and CONTINUE based on your report

你将参与由编排器协调的WRFC循环：

WRITE：完成分配的任务
REPORT：使用以下结构化输出格式
编排器将根据你的报告处理FIX和CONTINUE环节

Output Format

输出格式

Use this format when reporting completion:

报告任务完成时请使用以下格式：

Summary

摘要

[1-2 sentences on what was accomplished]

[1-2句话说明已完成的工作]

Changes Made

已做修改

path/to/file.ts - [what was done]

path/to/file.ts - [具体操作]

Decisions Made

决策说明

Chose X over Y: [rationale]

选择X而非Y：[理由]

Issues Encountered

遇到的问题

[Issue] -> [resolution or "unresolved"]

[问题] -> [解决方案或“未解决”]

Uncertainties

不确定事项

[Items for orchestrator to verify with user]

[需要编排器与用户确认的内容]

Next Steps

后续步骤

[Recommended follow-up actions]


**Critical elements:**
1. Scope is explicit (file paths, not vague descriptions)
2. Skills are listed with usage guidance
3. WRFC role is clear (agent does WRITE+REPORT, orchestrator does FIX+CONTINUE)
4. Output format is structured for orchestrator consumption

[建议的后续操作]


**关键要素：**
1. 范围明确（文件路径，而非模糊描述）
2. 列出技能及使用指导
3. WRFC角色清晰（Agent负责WRITE+REPORT，编排器负责FIX+CONTINUE）
4. 输出格式结构化，便于编排器处理

Monitoring and Coordination

监控与协调

Track Active Agents

跟踪活跃Agent

Maintain a task tracking structure:

yaml

active_tasks:
  task-1:
    agent_id: agent_abc123
    status: running | completed | blocked | failed
    started_at: ISO-8601 timestamp
    last_update: ISO-8601 timestamp
    blocking: [task-2, task-3]
    blocked_by: []
  task-2:
    agent_id: agent_def456
    status: waiting
    blocked_by: [task-1]

维护以下任务跟踪结构：

yaml

active_tasks:
  task-1:
    agent_id: agent_abc123
    status: running | completed | blocked | failed
    started_at: ISO-8601时间戳
    last_update: ISO-8601时间戳
    blocking: [task-2, task-3]
    blocked_by: []
  task-2:
    agent_id: agent_def456
    status: waiting
    blocked_by: [task-1]

Agent Concurrency Limits

Agent并发限制

Hard limit: 6 concurrent agent chains

When you have more than 6 tasks:

Prioritize by dependency order (unblock downstream tasks first)
Queue remaining tasks
Spawn new agents as slots free up

Task priority formula:

priority = (number of tasks it blocks) - (number of tasks blocking it)

Higher priority = spawn first

硬限制：6个并发Agent链

当任务数量超过6个时：

按依赖顺序优先处理（先解除下游任务的阻塞）
将剩余任务加入队列
当有空闲资源时生成新的Agent

任务优先级公式：

priority = (当前任务阻塞的任务数) - (阻塞当前任务的任务数)

优先级越高，越先生成Agent

WRFC Loop Coordination

WRFC循环协调

The WRFC loop is the orchestrator's pattern:

WRITE Phase:

Orchestrator spawns agents with task prompts
Each agent executes their task (discover, plan, batch)
Agents run in parallel (up to 6 concurrent)

REPORT Phase:

Agents return structured results
Orchestrator collects all agent reports
Orchestrator aggregates changes, decisions, issues

FIX Phase:

Orchestrator analyzes reports for issues
If issues found: spawn fix tasks or escalate to user
If uncertainties exist: query user for clarification
If all clear: proceed to CONTINUE

CONTINUE Phase:

Orchestrator spawns next wave of tasks (unblocked by completed tasks)
Loop back to WRITE
Exit when all tasks complete successfully

WRFC Spawn Rules:

Spawn parallel tasks together in WRITE phase
Wait for all in-flight tasks to REPORT before FIX
Do NOT spawn dependent tasks until blockers complete
Do NOT spawn more than 6 concurrent agent chains
If agent fails 3 times, escalate to user (don't loop indefinitely)

WRFC循环是编排器的核心模式：

WRITE阶段：

编排器根据任务提示生成Agent
每个Agent执行任务（发现、规划、批量处理）
Agent并行运行（最多6个并发）

REPORT阶段：

Agent返回结构化结果
编排器收集所有Agent的报告
编排器汇总修改、决策和问题

FIX阶段：

编排器分析报告中的问题
若发现问题：生成修复任务或升级至用户处理
若存在不确定事项：向用户询问澄清
若一切正常：进入CONTINUE阶段

CONTINUE阶段：

编排器生成下一批任务（已完成任务解除阻塞的任务）
循环回到WRITE阶段
所有任务成功完成后退出

WRFC生成规则：

在WRITE阶段批量生成并行任务
等待所有在运行任务完成REPORT后再进入FIX阶段
依赖任务解除阻塞前不生成
并发Agent链不超过6个
若Agent失败3次，升级至用户处理（不无限循环）

Agent Communication

Agent通信

Agents do NOT communicate directly. All coordination flows through the orchestrator:

Inter-agent dependencies:

Task A produces types.ts
Task B needs types.ts
Orchestrator: waits for A to complete, then spawns B with reference to types.ts location

Shared state:

All agents read/write .goodvibes/memory/
Orchestrator checks memory for decisions, patterns, failures before spawning
Orchestrator logs orchestration decisions to .goodvibes/memory/decisions.json

Agent之间不直接通信，所有协调通过编排器进行：

Agent间依赖：

任务A生成types.ts
任务B需要types.ts
编排器：等待任务A完成，再为任务B提供types.ts的位置信息

共享状态：

所有Agent读写.goodvibes/memory/
编排器在生成Agent前，检查记忆中的决策、模式和失败记录
编排器将编排决策记录到.goodvibes/memory/decisions.json

Mode-Specific Behavior

模式特定行为

Vibecoding Mode (Default)

Vibecoding模式（默认）

In vibecoding mode, the orchestrator has more autonomy:

Auto-spawn on ambiguity:

If task decomposition has multiple valid approaches, pick the most common pattern from memory
If no pattern exists, make a decision and log it to decisions.json
Only escalate to user for architectural decisions (auth provider, database choice, etc.)

Checkpointing:

No automatic checkpoints
Let agents run to completion
Only checkpoint on user request or before risky operations

Error handling:

Agents retry up to 3 times with error-recovery protocol
If agent fails 3 times, orchestrator tries alternate approach
Only escalate after 2 alternate approaches fail

在Vibecoding模式下，编排器拥有更多自主权：

模糊场景自动生成：

若任务分解有多种有效方案，选择记忆中最常见的模式
若无现有模式，做出决策并记录到decisions.json
仅在架构决策（身份验证提供商、数据库选择等）时升级至用户处理

检查点：

无自动检查点
让Agent运行至完成
仅在用户请求或风险操作前设置检查点

错误处理：

Agent使用错误恢复协议最多重试3次
若Agent失败3次，编排器尝试替代方案
仅在2种替代方案均失败时升级至用户处理

Justvibes Mode (Strict)

Justvibes模式（严格）

In justvibes mode, the orchestrator asks before acting:

Confirm before spawn:

Show task decomposition plan to user
Wait for approval before spawning agents
Allow user to modify task breakdown

Checkpointing:

Checkpoint after each WRFC cycle
Allow user to review changes before continuing
Offer rollback if user rejects changes

Error handling:

Escalate to user immediately on first error
Do not retry without user approval
Show full error context and proposed fix

在Justvibes模式下，编排器操作前需询问用户：

生成前确认：

向用户展示任务分解计划
等待用户批准后再生成Agent
允许用户修改任务分解

检查点：

每个WRFC周期后设置检查点
允许用户在继续前审核修改内容
若用户拒绝修改，提供回滚选项

错误处理：

首次错误立即升级至用户处理
无用户批准不重试
展示完整错误上下文和建议修复方案

Decomposition Examples

分解示例

Example 1: Feature Implementation

示例1：功能实现

User request: "Add user profile page with edit capability"

Classification: Feature Implementation

Decomposition:

yaml

tasks:
  - task_id: create-profile-types
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory]
    description: Create Profile and ProfileUpdate types
    scope:
      files: [src/types/profile.ts]
    blocking: [create-profile-api, create-profile-ui]
    blocked_by: []
    
  - task_id: create-profile-api
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, trpc, prisma]
    description: Implement tRPC routes for profile CRUD
    scope:
      files: [src/server/routers/profile.ts]
    blocking: [create-profile-ui]
    blocked_by: [create-profile-types]
    
  - task_id: create-profile-ui
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, nextjs, react, tailwindcss, shadcn-ui]
    description: Build profile page with edit form
    scope:
      files: [src/app/profile/page.tsx, src/components/ProfileForm.tsx]
    blocking: [review-profile-implementation]
    blocked_by: [create-profile-types]
    
  - task_id: review-profile-implementation
    agent: reviewer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, review-scoring, type-safety, error-handling]
    description: Review all profile implementation for code quality
    scope:
      files: [src/types/profile.ts, src/server/routers/profile.ts, src/app/profile/page.tsx, src/components/ProfileForm.tsx]
    blocking: [test-profile-feature]
    blocked_by: [create-profile-api, create-profile-ui]
    
  - task_id: test-profile-feature
    agent: tester
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory]
    description: Create tests for profile feature
    scope:
      files: [src/server/routers/profile.test.ts, src/components/ProfileForm.test.tsx]
    blocking: []
    blocked_by: [review-profile-implementation]

Execution plan:

Spawn create-profile-types (no blockers)
Wait for types to complete
Spawn create-profile-api and create-profile-ui in parallel (both unblocked)
Wait for both to complete
Spawn review-profile-implementation (blocked by API + UI)
Wait for review to complete
Spawn test-profile-feature (blocked by review)
Wait for tests to complete
Aggregate results and return to user

Parallelism: 4 waves (types solo -> API + UI parallel -> review solo -> tests solo)

用户请求： “添加带编辑功能的用户资料页面”

分类： 功能实现

分解结果：

yaml

tasks:
  - task_id: create-profile-types
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory]
    description: 创建Profile和ProfileUpdate类型
    scope:
      files: [src/types/profile.ts]
    blocking: [create-profile-api, create-profile-ui]
    blocked_by: []
    
  - task_id: create-profile-api
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, trpc, prisma]
    description: 实现用户资料CRUD的tRPC路由
    scope:
      files: [src/server/routers/profile.ts]
    blocking: [create-profile-ui]
    blocked_by: [create-profile-types]
    
  - task_id: create-profile-ui
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, nextjs, react, tailwindcss, shadcn-ui]
    description: 构建带编辑表单的用户资料页面
    scope:
      files: [src/app/profile/page.tsx, src/components/ProfileForm.tsx]
    blocking: [review-profile-implementation]
    blocked_by: [create-profile-types]
    
  - task_id: review-profile-implementation
    agent: reviewer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, review-scoring, type-safety, error-handling]
    description: 审核所有用户资料实现的代码质量
    scope:
      files: [src/types/profile.ts, src/server/routers/profile.ts, src/app/profile/page.tsx, src/components/ProfileForm.tsx]
    blocking: [test-profile-feature]
    blocked_by: [create-profile-api, create-profile-ui]
    
  - task_id: test-profile-feature
    agent: tester
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory]
    description: 为用户资料功能创建测试
    scope:
      files: [src/server/routers/profile.test.ts, src/components/ProfileForm.test.tsx]
    blocking: []
    blocked_by: [review-profile-implementation]

执行计划：

生成create-profile-types（无阻塞）
等待类型定义完成
并行生成create-profile-api和create-profile-ui（均已解除阻塞）
等待两者完成
生成review-profile-implementation（被API和UI任务阻塞）
等待审核完成
生成test-profile-feature（被审核任务阻塞）
等待测试完成
汇总结果并返回给用户

并行度： 4个阶段（类型定义单独执行 -> API和UI并行 -> 审核单独执行 -> 测试单独执行）

Example 2: Bug Fix

示例2：Bug修复

User request: "Fix login redirect loop on /dashboard"

Classification: Bug Fix

Decomposition:

yaml

tasks:
  - task_id: diagnose-redirect-loop
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, nextjs, nextauth]
    description: Identify root cause of redirect loop
    scope:
      files: [src/middleware.ts, src/app/dashboard/page.tsx, src/lib/auth.ts]
    blocking: [fix-redirect-loop]
    blocked_by: []
    
  - task_id: fix-redirect-loop
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, nextjs, nextauth]
    description: Apply fix based on diagnosis
    scope:
      files: [determined by diagnosis]
    blocking: [verify-fix]
    blocked_by: [diagnose-redirect-loop]
    
  - task_id: verify-fix
    agent: reviewer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, review-scoring, async-patterns, error-handling]
    description: Verify the fix resolves the redirect loop and doesn't introduce regressions
    scope:
      files: [determined by fix task]
    blocking: []
    blocked_by: [fix-redirect-loop]

Execution plan:

Spawn diagnose-redirect-loop
Wait for diagnosis with root cause analysis
Spawn fix-redirect-loop with diagnosis context
Wait for fix to complete
Spawn verify-fix (blocked by fix)
Wait for verification to complete
Return to user

Parallelism: None (fully sequential: diagnose -> fix -> verify)

用户请求： “修复/dashboard页面的登录重定向循环问题”

分类： Bug修复

分解结果：

yaml

tasks:
  - task_id: diagnose-redirect-loop
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, nextjs, nextauth]
    description: 定位重定向循环的根本原因
    scope:
      files: [src/middleware.ts, src/app/dashboard/page.tsx, src/lib/auth.ts]
    blocking: [fix-redirect-loop]
    blocked_by: []
    
  - task_id: fix-redirect-loop
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, nextjs, nextauth]
    description: 根据诊断结果修复问题
    scope:
      files: [由诊断结果确定]
    blocking: [verify-fix]
    blocked_by: [diagnose-redirect-loop]
    
  - task_id: verify-fix
    agent: reviewer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, review-scoring, async-patterns, error-handling]
    description: 验证修复是否解决重定向循环且未引入回归问题
    scope:
      files: [由修复任务确定]
    blocking: []
    blocked_by: [fix-redirect-loop]

执行计划：

生成diagnose-redirect-loop
等待包含根本原因分析的诊断结果
结合诊断结果生成fix-redirect-loop
等待修复完成
生成verify-fix（被修复任务阻塞）
等待验证完成
返回给用户

并行度： 无（完全串行：诊断 -> 修复 -> 验证）

Example 3: Refactoring

示例3：代码重构

User request: "Extract shared auth logic into reusable hooks"

Classification: Refactoring

Decomposition:

yaml

tasks:
  - task_id: plan-refactoring-approach
    agent: architect
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory]
    description: Design the refactoring strategy and hook API
    scope:
      directories: [src/components, src/app]
    blocking: [analyze-auth-patterns]
    blocked_by: []
    
  - task_id: analyze-auth-patterns
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory]
    description: Discover all auth usage patterns in components
    scope:
      directories: [src/components, src/app]
    blocking: [create-auth-hooks]
    blocked_by: [plan-refactoring-approach]
    
  - task_id: create-auth-hooks
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, react]
    description: Create hooks based on discovered patterns
    scope:
      files: [src/hooks/useAuth.ts, src/hooks/useRequireAuth.ts]
    blocking: [refactor-components-1, refactor-components-2]
    blocked_by: [analyze-auth-patterns]
    
  - task_id: refactor-components-1
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, react]
    description: Refactor components in src/app to use hooks
    scope:
      directories: [src/app]
    blocking: []
    blocked_by: [create-auth-hooks]
    
  - task_id: refactor-components-2
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, react]
    description: Refactor components in src/components to use hooks
    scope:
      directories: [src/components]
    blocking: []
    blocked_by: [create-auth-hooks]

Execution plan:

Spawn plan-refactoring-approach (architect)
Wait for planning to complete
Spawn analyze-auth-patterns (blocked by planning)
Wait for pattern analysis
Spawn create-auth-hooks (blocked by analysis)
Wait for hooks to complete
Spawn refactor-components-1 and refactor-components-2 in parallel
Wait for both to complete
Return to user

Parallelism: 4 waves (planning -> analysis -> hooks -> 2 refactors parallel)

用户请求： “将共享身份验证逻辑提取为可复用Hook”

分类： 代码重构

分解结果：

yaml

tasks:
  - task_id: plan-refactoring-approach
    agent: architect
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory]
    description: 设计重构策略和Hook API
    scope:
      directories: [src/components, src/app]
    blocking: [analyze-auth-patterns]
    blocked_by: []
    
  - task_id: analyze-auth-patterns
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory]
    description: 发现组件中所有身份验证使用模式
    scope:
      directories: [src/components, src/app]
    blocking: [create-auth-hooks]
    blocked_by: [plan-refactoring-approach]
    
  - task_id: create-auth-hooks
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, react]
    description: 根据发现的模式创建Hook
    scope:
      files: [src/hooks/useAuth.ts, src/hooks/useRequireAuth.ts]
    blocking: [refactor-components-1, refactor-components-2]
    blocked_by: [analyze-auth-patterns]
    
  - task_id: refactor-components-1
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, react]
    description: 重构src/app中的组件以使用Hook
    scope:
      directories: [src/app]
    blocking: []
    blocked_by: [create-auth-hooks]
    
  - task_id: refactor-components-2
    agent: engineer
    skills: [discover-plan-batch, precision-mastery, error-recovery, goodvibes-memory, react]
    description: 重构src/components中的组件以使用Hook
    scope:
      directories: [src/components]
    blocking: []
    blocked_by: [create-auth-hooks]

执行计划：

生成plan-refactoring-approach（架构师）
等待规划完成
生成analyze-auth-patterns（被规划任务阻塞）
等待模式分析完成
生成create-auth-hooks（被分析任务阻塞）
等待Hook创建完成
并行生成refactor-components-1和refactor-components-2
等待两者完成
返回给用户

并行度： 4个阶段（规划 -> 分析 -> Hook创建 -> 2个重构任务并行）

Escalation Criteria

升级标准

Escalate to user immediately when:

Architectural ambiguity - Multiple valid approaches with significant tradeoffs
- Example: "Use REST vs GraphQL for new API"
- Escalation: Present options with pros/cons, request decision
Missing information - Task cannot be completed without user input
- Example: "Which auth provider should we use?"
- Escalation: List options, explain what's needed
Scope expansion - Task is larger than initially described
- Example: "Adding profile page requires new database schema and migration"
- Escalation: Show expanded scope, request approval
Agent failure after alternates - Agent failed 3 times, alternate approach also failed
- Example: "Cannot fix type error after trying 2 different approaches"
- Escalation: Show attempts, request guidance or manual intervention
Conflicting requirements - Discovered constraints contradict each other
- Example: "User wants Prisma but codebase uses Drizzle"
- Escalation: Explain conflict, request resolution

在以下场景立即升级至用户处理：

架构模糊性 - 存在多种有效方案且有显著权衡
- 示例：“为新API选择REST还是GraphQL”
- 升级方式：展示选项及优缺点，请求用户决策
信息缺失 - 无用户输入无法完成任务
- 示例：“我们应使用哪种身份验证提供商？”
- 升级方式：列出选项，说明所需信息
范围扩展 - 任务规模超出初始描述
- 示例：“添加用户资料页面需要新的数据库模式和迁移”
- 升级方式：展示扩展后的范围，请求用户批准
Agent多次失败 - Agent失败3次，替代方案也失败
- 示例：“尝试2种不同方案后仍无法修复类型错误”
- 升级方式：展示尝试过程，请求用户指导或手动干预
需求冲突 - 发现的约束相互矛盾
- 示例：“用户要求使用Prisma但代码库使用Drizzle”
- 升级方式：说明冲突，请求用户解决

Summary

总结

Task orchestration workflow:

Classify request (feature, bug, refactoring, etc.)
Identify parallel opportunities (domains, files, research)
Define agent tasks (task structure with blocking/blocked_by)
Assign agents and skills (use decision table)
Spawn agents with structured prompts (include WRFC guidance)
Monitor active agents (up to 6 concurrent)
Coordinate WRFC loops (WRITE -> REPORT -> FIX -> CONTINUE)
Aggregate results and return to user

Key principles:

Explicit > implicit (file paths, not vague descriptions)
Parallel when possible, sequential when necessary
WRFC loop is orchestrator's pattern, agents participate in one step
Escalate on ambiguity in justvibes, decide in vibecoding
Use memory to inform decisions and avoid repeating failures

任务编排工作流：

对请求分类（功能、Bug、重构等）
识别并行机会（领域、文件、调研）
定义Agent任务（包含阻塞/被阻塞关系的任务结构）
分配Agent与技能（使用决策表）
用结构化提示生成Agent（包含WRFC指导）
监控活跃Agent（最多6个并发）
协调WRFC循环（WRITE -> REPORT -> FIX -> CONTINUE）
汇总结果并返回给用户

核心原则：

明确优于模糊（使用文件路径，而非模糊描述）
尽可能并行，必要时串行
WRFC是编排器的模式，Agent仅参与其中一个步骤
Justvibes模式下模糊场景升级至用户，Vibecoding模式下自主决策
使用记忆辅助决策，避免重复失败