design-orchestrator

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Design Orchestrator

Design Orchestrator

Overview

概述

This skill is the entrypoint for design-stage work.
It does not do the deep design work itself. Its job is to inspect the current design state, choose exactly one next design skill, and keep the workflow moving until the design is ready for
writing-plans
.
该Skill是设计阶段工作的入口。它本身不执行深度设计工作,其职责是检查当前的design_state,精准选择下一个设计Skill,推动工作流持续进行,直到设计就绪可进入
writing-plans
阶段。

When to Use

使用场景

Use this skill when:
  • the task needs design before implementation
  • the user wants to turn an idea into an implementation-ready design
  • the design exists, but the next step is unclear
  • the task needs routing between design decomposition, decision analysis, and readiness review
Do not use this skill when:
  • the user is asking for direct execution
  • the task is already in implementation planning
  • the task is a single-step coding or editing request
  • the task is a writing request such as a report, note, or summary
  • the task is a simple linear SOP with no real design state
在以下场景中使用该Skill:
  • 任务需要在实施前进行设计
  • 用户希望将想法转化为可实施的设计
  • 已有设计,但下一步方向不明确
  • 任务需要在设计分解、决策分析和就绪审查之间进行路由
请勿在以下场景中使用该Skill:
  • 用户要求直接执行任务
  • 任务已进入实施规划阶段
  • 任务是单步编码或编辑请求
  • 任务是撰写报告、笔记或摘要等写作类请求
  • 任务是简单的线性SOP,无实际设计状态

Shared Design State

共享设计状态

Assume the design workflow passes around a shared
design_state
with these logical fields:
  • problem
  • scope
  • design_tree
  • open_branches
  • decision_nodes
  • external_dependencies
  • decisions
  • risks
  • validation
  • status
  • design_target_type
Treat
design_target_type
as required. Do not silently infer it from an incomplete design-state input.
假设设计工作流中传递的共享
design_state
包含以下逻辑字段:
  • problem
  • scope
  • design_tree
  • open_branches
  • decision_nodes
  • external_dependencies
  • decisions
  • risks
  • validation
  • status
  • design_target_type
design_target_type
为必填字段,请勿从不完整的design_state输入中隐式推断该字段。

Core Responsibilities

核心职责

Your responsibilities are:
  1. Determine whether the task is actually in the design stage.
  2. Inspect the current
    design_state
    and identify the single most useful next skill.
  3. Route the task to exactly one next design skill.
  4. Re-evaluate after each handoff until the design either becomes ready for planning or the user stops.
  5. Prevent premature transition into
    writing-plans
    .
你的职责包括:
  1. 判断任务是否确实处于设计阶段。
  2. 检查当前的
    design_state
    ,确定最有用的下一个设计Skill。
  3. 将任务路由至恰好一个下一个设计Skill。
  4. 在每次交接后重新评估,直到设计就绪可进入规划阶段或用户停止操作。
  5. 防止过早过渡到
    writing-plans
    阶段。

Routing Rules

路由规则

Apply routing in this order.
按以下顺序应用路由规则:

1. Missing Required State

1. 缺失必填状态

Route to
design-structure
when:
  • the task should already be in design-state form, but
    design_target_type
    is missing
  • a design tree exists, but the target type has not been set explicitly
In this case, do not continue to any other design skill first. The next step is to make the target type explicit.
当出现以下情况时,路由至
design-structure
  • 任务本应已处于design_state形式,但
    design_target_type
    缺失
  • 存在设计树,但未明确设置目标类型
在此情况下,请勿先转向其他设计Skill,下一步是明确目标类型。

2. No Real Tree Yet

2. 尚未形成实际设计树

Route to
design-structure
when:
  • there is no real design tree yet
  • the task is still a vague idea or feature request
  • scope, boundaries, core objects, or key flows are still missing
当出现以下情况时,路由至
design-structure
  • 尚未形成实际的设计树
  • 任务仍为模糊的想法或功能需求
  • 范围、边界、核心对象或关键流程仍缺失

3. Derived Tree Candidate

3. 派生树候选

Before routing to
design-refinement
, check whether the current tree is beginning to contain a second stable problem domain.
Use the shared derivation rules in
../design-tree-core/REFERENCE.md
as the source of truth for this judgment.
A derived tree should be created only if all of the following are true:
  • the current tree is starting to answer a second distinct core question
  • that question appears repeatedly, not as a one-off exception
  • the branch now behaves like a stable decision system
  • a child tree can define its own scope and done criteria
  • deriving it will make the parent tree smaller and clearer
If those conditions are met:
  • route to
    design-structure
    to create a derived tree
  • require an explicit parent/child handoff
  • require the parent tree to shrink the extracted branch after derivation
If those conditions are not met:
  • do not derive
  • continue routing within the current tree
在路由至
design-refinement
之前,检查当前设计树是否开始包含第二个稳定的问题域。
../design-tree-core/REFERENCE.md
中的共享派生规则作为判断的依据。
仅当满足以下所有条件时,才应创建派生树:
  • 当前设计树开始回答第二个截然不同的核心问题
  • 该问题反复出现,而非一次性例外
  • 该分支的表现已类似稳定的决策系统
  • 子树可定义自身的范围和完成标准
  • 派生操作将使父树更简洁、清晰
若满足上述条件:
  • 路由至
    design-structure
    以创建派生树
  • 要求明确的父/子交接
  • 要求父树在派生后缩减提取出的分支
若不满足上述条件:
  • 不进行派生操作
  • 在当前设计树内继续路由

4. Explicit Decision Blocker

4. 明确的决策阻塞点

Route to
decision-evaluation
when:
  • there is a bounded decision node with real alternatives
  • the blocking issue is a concrete choice rather than an under-specified branch
当出现以下情况时,路由至
decision-evaluation
  • 存在带有实际备选方案的有限决策节点
  • 阻塞问题是具体的选择,而非未明确的分支

5. Mostly Complete

5. 基本完成

Route to
design-readiness-check
when:
  • the design appears mostly complete
  • the remaining question is whether it is safe to move into implementation planning
当出现以下情况时,路由至
design-readiness-check
  • 设计看起来基本完成
  • 剩余问题是是否可以安全进入实施规划阶段

6. Everything Else

6. 其他所有情况

Route to
design-refinement
when:
  • a design tree exists
  • major branches are still shallow, vague, or unresolved
  • the main need is deeper decomposition, edge-case coverage, or failure-path clarification
When
design-structure
has just completed the initial tree's main body:
  • expect that tree to be persisted before routing onward
  • treat
    design-refinement
    as the default next step unless a bounded decision or readiness check is the clearer blocker
当出现以下情况时,路由至
design-refinement
  • 已存在设计树
  • 主要分支仍较浅、模糊或未解决
  • 主要需求是更深入的分解、边缘场景覆盖或失败路径澄清
design-structure
刚完成初始设计树的主体部分时:
  • 需先保存该设计树,再进行后续路由
  • 除非明确存在有限决策或就绪检查阻塞点,否则默认下一步为
    design-refinement

Diagram Conventions

图表规范

After routing, show the current workflow position as a character DAG inside a code block (no language tag):
[task-brief]
[design-orchestrator]  ← you are here
[design-structure]
Or when showing branching:
          [orchestrator]
          │    │    │
     ┌────┘    │    └────┐
     ▼         ▼         ▼
[structure] [refine] [evaluate]
Rules:
  • Components in
    [brackets]
    , vertical flow with
    and
  • Fan-out:
    ┌────┘
    /
    └────┐
    ; fan-in:
    └────┬────┘
  • Max width: 78 characters
  • Only include when routing changes or the user asks for a status overview
路由完成后,在代码块(无语言标签)中用字符DAG展示当前工作流位置:
[task-brief]
[design-orchestrator]  ← you are here
[design-structure]
或展示分支情况时:
          [orchestrator]
          │    │    │
     ┌────┘    │    └────┐
     ▼         ▼         ▼
[structure] [refine] [evaluate]
规则:
  • 组件用
    [方括号]
    包裹,垂直流用
    表示
  • 分支展开:
    ┌────┘
    /
    └────┐
    ;分支合并:
    └────┬────┘
  • 最大宽度:78字符
  • 仅在路由变更或用户要求状态概览时展示

Entry and Exit Criteria

进入与退出条件

Enter when:
  • the task needs design-stage coordination
  • the user has not asked to skip design
Exit when:
  • design-readiness-check
    returns that the design is ready for planning
  • the user explicitly stops the design workflow
  • the task turns out not to require design-stage work after all
进入条件:
  • 任务需要设计阶段协调
  • 用户未要求跳过设计阶段
退出条件:
  • design-readiness-check
    返回设计已就绪可进入规划阶段
  • 用户明确停止设计工作流
  • 任务最终被判定无需设计阶段工作

Handoff Rules

交接规则

  • Never expand a branch in depth yourself if a specialized design skill should do it.
  • Never compare options broadly if the real next step is to structure or refine the design.
  • If a downstream skill changes the design materially, re-check routing instead of assuming the next step.
  • After
    design-structure
    completes a main tree, prefer
    design-refinement
    as the default continuation.
  • Only send the task to
    writing-plans
    after
    design-readiness-check
    has clearly passed.
  • If a downstream skill cannot be invoked in the current context, still name it explicitly as the next step and stop. Do not execute its responsibilities inline as a substitute.
  • Never route to more than one next step in the same turn.
  • Never continue a design flow that is missing
    design_target_type
    .
  • Never derive a new tree just because the current tree is long.
  • Never keep expanding a branch inline after deciding that it should become a derived tree.
  • Never absorb report writing, note production, or SOP drafting into design routing.
  • 若应由专业设计Skill执行分支深度扩展,请勿自行扩展。
  • 若实际下一步是构建或完善设计,请勿广泛比较选项。
  • 若下游Skill对设计进行了实质性修改,需重新检查路由,而非默认下一步。
  • design-structure
    完成主设计树后,默认优先选择
    design-refinement
    作为后续步骤。
  • 仅在
    design-readiness-check
    明确通过后,才可将任务发送至
    writing-plans
  • 若当前上下文无法调用下游Skill,仍需明确指定下一步为该Skill并停止操作,请勿自行替代执行其职责。
  • 同一轮操作中,请勿路由至多个下一步。
  • 若缺失
    design_target_type
    ,请勿继续设计流程。
  • 请勿仅因当前设计树过长而派生新树。
  • 若已决定将分支转为派生树,请勿继续内联扩展该分支。
  • 请勿将报告撰写、笔记生成或SOP起草纳入设计路由流程。