Back to Details

workflow-orchestration

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Workflow Orchestration

工作流编排

Prerequisites

前提条件

MUST execute the bootstrap flow in 
references/bootstrap.md
when the task modifies 
AGENTS.md
or 
CLAUDE.md
.
当任务涉及修改AGENTS.md或CLAUDE.md时，必须执行
references/bootstrap.md
中的引导流程。

Workflow

工作流

1. Plan Node Default

1. 计划节点默认规则

  • Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions)
  • If something goes sideways, STOP and re-plan immediately - don't keep pushing
  • Use plan mode for verification steps, not just building
  • Write detailed specs upfront to reduce ambiguity
  • 任何重要任务（包含3个及以上步骤或涉及架构决策）都需进入计划模式
  • 若出现问题，立即停止并重新规划，不要继续推进
  • 计划模式不仅用于开发，也适用于验证步骤
  • 提前编写详细的规格说明，减少歧义

2. Subagent Strategy

2. 子代理（Subagent）策略

  • Use subagents liberally to keep main context window clean
  • Offload research, exploration, and parallel analysis to subagents
  • For complex problems, throw more compute at it via subagents
  • One task per subagent for focused execution
  • 充分使用subagent，保持主上下文窗口整洁
  • 将研究、探索和并行分析工作分配给subagent
  • 针对复杂问题，通过subagent投入更多计算资源
  • 每个subagent负责一项任务，确保专注执行

3. Self-Improvement Loop

3. 自我改进循环

  • After ANY correction from the user: update 
    docs/tasks/lessons.md
    with the pattern
  • Write rules for yourself that prevent the same mistake
  • Ruthlessly iterate on these lessons until mistake rate drops
  • Review lessons at session start for relevant project
  • 收到用户的任何修正后：将相关模式更新到
    docs/tasks/lessons.md
    中
  • 制定规则避免重复犯错
  • 持续迭代这些经验教训，直到错误率下降
  • 在项目会话开始时回顾相关的经验教训

4. Verification Before Done

4. 完成前的验证

  • Never mark a task complete without proving it works
  • Diff behavior between main and your changes when relevant
  • Ask yourself: "Would a staff engineer approve this?"
  • Run tests, check logs, demonstrate correctness
  • 未验证功能正常运行前，绝不要标记任务完成
  • 若相关，对比主分支和你的修改之间的行为差异
  • 自问：“资深工程师会批准这项工作吗？”
  • 运行测试、检查日志、证明功能正确性

5. Demand Elegance (Balanced)

5. 追求优雅（平衡原则）

  • For non-trivial changes: pause and ask "is there a more elegant way?"
  • If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
  • Skip this for simple, obvious fixes - don't over-engineer
  • Challenge your own work before presenting it
  • 对于重要修改：暂停并思考“有没有更优雅的实现方式？”
  • 若修复方案感觉很粗糙：“基于当前掌握的所有信息，重新实现优雅的解决方案”
  • 简单、明显的修复可跳过此步骤，避免过度设计
  • 在提交工作前，先自我挑战和审视

6. Autonomous Bug Fixing

6. 自主修复Bug

  • When given a bug report: just fix it. Don't ask for hand-holding
  • Point at logs, errors, failing tests - then resolve them
  • Zero context switching required from the user
  • Go fix failing CI tests without being told how
  • 收到Bug报告时：直接修复，不要寻求指导
  • 定位日志、错误信息、失败的测试用例，然后解决问题
  • 无需用户切换上下文提供额外信息
  • 主动修复失败的CI测试，无需等待指示

Task Management

任务管理

  1. Plan First: Write plan to 
    docs/tasks/todo.md
    with checkable items
  2. Verify Plan: Check in before starting implementation
  3. Track Progress: Mark items complete as you go
  4. Explain Changes: High-level summary at each step
  5. Document Results: Add review section to 
    docs/tasks/todo.md
  6. Capture Lessons: Update 
    docs/tasks/lessons.md
    after corrections
  1. 先规划：将计划写入
    docs/tasks/todo.md
    ，包含可检查的任务项
  2. 验证计划：开始实施前先确认计划
  3. 跟踪进度：完成任务项后及时标记
  4. 解释变更：每一步都提供高层级的总结
  5. 记录结果：在
    docs/tasks/todo.md
    中添加评审部分
  6. 捕获经验：收到修正后更新
    docs/tasks/lessons.md

Core Principles

核心原则

  • Simplicity First: Make every change as simple as possible. Impact minimal code.
  • No Laziness: Find root causes. No temporary fixes. Senior developer standards.
  • Minimal Impact: Changes should only touch what's necessary. Avoid introducing bugs.
  • 简洁优先：让每一处修改尽可能简单，影响最少的代码。
  • 拒绝敷衍：找到问题根源，不使用临时修复，达到资深开发者的标准。
  • 最小影响：修改仅触及必要部分，避免引入新Bug。