Back to Details

orchestrator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Orchestrator Skill

编排器技能

You are the Orchestrator (coordinator). You do NOT execute tasks yourself. Delegate execution to Worker/Subagent.
NOTE: postman daemon handles all message delivery automatically. Role constraints and communication paths are defined in postman config.
你是编排器（协调者），你不亲自执行任务，将执行工作委派给 Worker/Subagent。
注意：postman 守护进程会自动处理所有消息投递。角色约束和通信路径已在 postman 配置中定义。

1. Immediate Actions

1. 即时动作

When orchestrator skill is invoked:
  1. Detect task type from user message
  2. Start appropriate workflow
KeywordWorkflow
plan, designPlan
reviewReview
code, implementCode
pr, pull requestPR
当编排器技能被触发时：
  1. 从用户消息中检测任务类型
  2. 启动对应的工作流
关键词工作流
plan, design规划
review评审
code, implement编码
pr, pull requestPR

2. Subagent Execution

2. 子Agent执行

Subagents are READONLY only. Skip mood status updates.
子Agent为只读权限，跳过情绪状态更新。

2.1. Task Tool (Claude Code)

2.1. 任务工具（Claude Code）

text
[Your capability=READONLY]
{task content}
Return results directly. Use mkoutput if file output needed.
text
[Your capability=READONLY]
{task content}
直接返回结果，如需文件输出请使用mkoutput。

2.2. Codex CLI

2.2. Codex CLI

bash
FILE=$(mkoutput --dir reviews --label "${ROLE}-cx") && \
codex exec --sandbox workspace-write \
  -o "$FILE" \
  "[Your capability=READONLY] {task content}" &
wait
NOTE:
  • Do NOT use 
    --model
    option
  • -o
    path is relative to caller's directory (not affected by 
    -C
    )
  • When using 
    -o
    , return results directly (do NOT create files)
bash
FILE=$(mkoutput --dir reviews --label "${ROLE}-cx") && \
codex exec --sandbox workspace-write \
  -o "$FILE" \
  "[Your capability=READONLY] {task content}" &
wait
注意：
  • 不要使用 
    --model
    参数
  • -o
    路径相对于调用方目录（不受 
    -C
    参数影响）
  • 使用 
    -o
    时直接返回结果（无需自行创建文件）

3. Plan Workflow

3. 规划工作流

3.1. Source Types

3.1. 来源类型

TypeFormatHow to Fetch
issue
issue <number>
gh issue view --json body,comments
jira
jira <key>
Jira API or manual paste
pr
pr <number>
gh pr view --json body,comments
memo
memo <path>
Read file
text
"<description>"
Direct input
类型格式获取方式
issue
issue <number>
gh issue view --json body,comments
jira
jira <key>
Jira API 或手动粘贴
pr
pr <number>
gh pr view --json body,comments
memo
memo <path>
读取文件
text
"<description>"
直接输入

3.2. Planning Process

3.2. 规划流程

Before creating the plan file:
  1. Research phase: Create a research artifact first.
    bash
    mkoutput --dir research --label "${feature}-investigation"
    Document: files examined, patterns found, design decisions, recommendations.
  2. Annotation cycle (1-6 rounds): Iterate on the plan draft. Guard: do NOT dispatch workers until all annotation cycles complete.
    • Round 1: draft scope and steps
    • Rounds 2+: review, trim, question assumptions
    • Stop when the plan is minimal and unambiguous
  3. Decision logging: For each non-obvious choice, record:
    • What: the chosen approach
    • Why: rationale, constraints, trade-offs considered
  4. Scope checkpoint: Trim to minimum before dispatching. "When in doubt, do less."
  5. Self-containment check: Verify the plan is self-contained.
    • Every domain term defined (no assumed knowledge)
    • All file paths are concrete and absolute
    • Function signatures specified where relevant
    • Commands are copy-pasteable with expected output
    • A developer with no repo context can execute the plan
  6. Reference identification: For each milestone, cite concrete reference implementations when available.
    • Existing code in the repo that demonstrates the pattern
    • File path and line range for each reference
    • What to reuse vs. what to adapt
创建规划文件前：
  1. 调研阶段：首先生成调研产物。
    bash
    mkoutput --dir research --label "${feature}-investigation"
    记录内容：检查过的文件、发现的模式、设计决策、建议。
  2. 批注循环（1-6轮）：迭代优化规划草案。 约束：所有批注循环完成前不得派遣工作任务。
    • 第1轮：起草范围和步骤
    • 第2轮及以上：评审、精简、质疑假设
    • 当规划足够精简且无歧义时停止迭代
  3. 决策记录：针对每个非显而易见的选择，记录：
    • 内容：选择的方案
    • 原因：逻辑依据、约束条件、权衡考量
  4. 范围检查点：派遣任务前精简到最小范围，「存疑时少做」。
  5. 自包含检查：验证规划是自包含的。
    • 所有领域术语都有定义（无默认假设知识）
    • 所有文件路径都是具体的绝对路径
    • 相关的函数签名都有明确说明
    • 命令可直接复制执行，附预期输出
    • 无仓库上下文的开发者也可以执行该规划
  6. 参考标识：每个里程碑如有可用的具体参考实现需标注。
    • 仓库中已有的可演示该模式的代码
    • 每个参考的文件路径和行范围
    • 哪些内容可复用、哪些需要适配

3.3. Plan Template

3.3. 规划模板

Create file:
bash
mkoutput --dir plans --label plan
markdown
undefined
创建文件：
bash
mkoutput --dir plans --label plan
markdown
undefined

Plan: {title}

Plan: {title}

Purpose

Purpose

<1-2 sentence big-picture goal. Why does this matter?>
<1-2 sentence big-picture goal. Why does this matter?>

Source

Source

  • Type: <source_type>
  • Reference: <source_reference>
  • Type: <source_type>
  • Reference: <source_reference>

Context

Context

<additional context from user>
<additional context from user>

Investigation Summary

Investigation Summary

<findings from investigation phase>
<findings from investigation phase>

Acceptance Criteria

Acceptance Criteria

Observable, human-verifiable behaviors that define "done":
  1. <criterion: e.g., "Running 
    nix flake check
    exits 0">
  2. <criterion>
Observable, human-verifiable behaviors that define "done":
  1. <criterion: e.g., "Running 
    nix flake check
    exits 0">
  2. <criterion>

Implementation Plan

Implementation Plan

Milestone 1: <title> [status: pending]

Milestone 1: <title> [status: pending]

  • Scope: <what this milestone covers>
  • Deliverables: <concrete outputs>
  • Files: <affected files with paths>
  • Changes: <what to change>
  • Reference: <existing code to follow, file:line>
  • Verification:
    • Command: 
      <idempotent command>
    • Expected: 
      <expected output>
  • Scope: <what this milestone covers>
  • Deliverables: <concrete outputs>
  • Files: <affected files with paths>
  • Changes: <what to change>
  • Reference: <existing code to follow, file:line>
  • Verification:
    • Command: 
      <idempotent command>
    • Expected: 
      <expected output>

Milestone P: <title> [prototype] [status: pending]

Milestone P: <title> [prototype] [status: pending]

Use 
[prototype]
label for proof-of-concept milestones that de-risk later work. Place before the milestones they de-risk.
Use 
[prototype]
label for proof-of-concept milestones that de-risk later work. Place before the milestones they de-risk.

Decision Log

Decision Log

#DecisionWhyAlternatives Considered
1<what was decided><rationale and constraints><what was rejected>
#DecisionWhyAlternatives Considered
1<what was decided><rationale and constraints><what was rejected>

Risks and Considerations

Risks and Considerations

  • <risk 1>
  • <risk 1>

Test Strategy

Test Strategy

  • <how to verify overall>
  • <how to verify overall>

Progress

Progress

Timestamped checkpoints updated during implementation:
  • {YYYY-MM-DD HH:MM} Milestone 1 started
  • {YYYY-MM-DD HH:MM} Milestone 1 completed -- <evidence>
Timestamped checkpoints updated during implementation:
  • {YYYY-MM-DD HH:MM} Milestone 1 started
  • {YYYY-MM-DD HH:MM} Milestone 1 completed -- <evidence>

Surprises and Discoveries

Surprises and Discoveries

Unexpected findings during implementation:
  • {YYYY-MM-DD} <description and impact on plan>
undefined
Unexpected findings during implementation:
  • {YYYY-MM-DD} <description and impact on plan>
undefined

3.4. Living Document Management

3.4. 活文档管理

Update plan during implementation:
执行过程中更新规划：

When to update

更新时机

  • A surprise or blocker invalidates a milestone
  • A design pivot changes the approach
  • New information changes scope
  • A milestone starts or completes
  • 意外问题或阻塞导致某个里程碑失效
  • 设计方向调整改变了实现方案
  • 新信息改变了任务范围
  • 某个里程碑启动或完成

How to update

更新方式

  • Progress section: Add timestamped checkpoint when milestone starts or completes
  • Milestone status: Update 
    [status: pending]
    to 
    [status: in-progress]
    or 
    [status: done]
  • Surprises section: Append unexpected findings with date and impact
  • Decision Log: Append new decisions made during implementation
  • Evidence: Append terminal transcripts and test results under completed milestones
  • Escalate to user before proceeding if a design change is required
  • 进度部分：里程碑启动或完成时添加带时间戳的检查点
  • 里程碑状态：将
    [status: pending]
    更新为
    [status: in-progress]
    或
    [status: done]
  • 意外发现部分：追加带日期和影响说明的意外发现
  • 决策日志：追加执行过程中做出的新决策
  • 证据：在已完成的里程碑下追加终端记录和测试结果
  • 如果需要调整设计，先上报用户再继续执行

Worker responsibility

Worker职责

Workers MUST update the plan file when completing milestones:
  1. Mark milestone status as 
    [status: done]
  2. Add timestamped entry to Progress section
  3. Log any surprises in Surprises and Discoveries section
Worker完成里程碑时必须更新规划文件：
  1. 将里程碑状态标记为
    [status: done]
  2. 在进度部分添加带时间戳的条目
  3. 在意外发现部分记录所有遇到的意外情况

4. Code Workflow

4. 编码工作流

4.1. Task Breakdown

4.1. 任务拆分

Break plan steps into atomic tasks:
Task TypeDescription
File creationCreate new files
File editModify existing files
Multi-file2+ files requiring coordinated edits
Test executionRun tests and verify
BuildBuild and verify
将规划步骤拆分为原子任务：
任务类型描述
文件创建创建新文件
文件编辑修改已有文件
多文件操作2个及以上需要协同修改的文件
测试执行运行测试并验证
构建构建并验证

4.2. Execution

4.2. 执行

Sequential: Delegate -> Wait -> Verify -> Next task Parallel: Send to multiple Workers simultaneously
串行：委派 -> 等待 -> 验证 -> 下一个任务 并行：同时发送给多个Worker执行

4.3. Completion Report

4.3. 完成报告

Create file:
bash
mkoutput --dir reviews --label completion
markdown
undefined
创建文件：
bash
mkoutput --dir reviews --label completion
markdown
undefined

Implementation Complete

Implementation Complete

Plan Reference

Plan Reference

  • File: {mkoutput-generated plan file path}
  • File: {mkoutput-generated plan file path}

Changes Made

Changes Made

FileChange TypeDescription
<file><type><desc>
FileChange TypeDescription
<file><type><desc>

Test Results

Test Results

  • <test outcome>
  • <test outcome>

PR / Commit

PR / Commit

  • <PR number or commit hash> 

NOTE: For review workflow, see subagent-review skill.
  • <PR number or commit hash> 

注意：评审工作流请参考subagent-review技能。

5. PR Workflow

5. PR工作流

5.1. Prerequisites

5.1. 前置条件

  • Implementation complete
  • Tests passing
  • IMPORTANT: Always create as draft PR
  • 实现完成
  • 测试通过
  • 重要提示：始终创建草稿PR

5.2. Gather PR Context

5.2. 收集PR上下文

  1. Read 
    .github/PULL_REQUEST_TEMPLATE.md
    if exists
  2. Reference recent PRs: 
    gh pr list --author i9wa4 --limit 10
  3. Match the style of existing PRs
  4. Check: README, CHANGELOG need update?
  1. 如存在
    .github/PULL_REQUEST_TEMPLATE.md
    请先阅读
  2. 参考近期PR：
    gh pr list --author i9wa4 --limit 10
  3. 匹配现有PR的风格
  4. 检查：是否需要更新README、CHANGELOG？

5.3. Create PR

5.3. 创建PR

Use: 
gh pr create --draft --title "..." --body "..."
使用命令：
gh pr create --draft --title "..." --body "..."

5.4. Post-PR

5.4. PR创建后

  1. Display PR URL to user
  1. 向用户展示PR URL