design-structure

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Design Structure

设计结构

Overview

概述

This skill turns a vague idea into an initial design tree through a two-phase workflow:

Interactive confirmation — progressively confirm
```
design_target_type
```
, problem, scope, and assumptions with the user
Design tree generation — produce the design tree based on confirmed inputs

Its primary output is

design_state

. When the initial tree first becomes stable enough to reference safely, persist it as the authoritative design artifact in the designated directory

docs/design-tree/

before handing off to the next design step.

本技能通过两阶段工作流将模糊想法转化为初始设计树：

交互式确认 — 逐步与用户确认
```
design_target_type
```
、问题、范围及假设
设计树生成 — 根据确认的输入生成设计树

其主要输出为

design_state

。当初始树首次达到可安全参考的稳定状态时，将其作为权威设计工件持久化存储到指定目录

docs/design-tree/

，再移交至后续设计步骤。

When to Use

使用场景

Use this skill when:

the user has an idea but not a design
the task lacks scope, boundaries, core objects, or key flows
there is no clear design tree yet
the current design conversation is still at the "what are we even designing?" stage
an existing tree is missing
```
design_target_type
```
and needs that field to be made explicit

Do not use this skill when:

a workable design tree already exists
the main need is deeper decomposition of existing branches
the main need is to compare options for one explicit decision node
the main need is to decide whether the design is ready for planning
the current tree only needs deeper refinement rather than a true derived tree
the task is a report, note, summary, or documentation rewrite
the task is a simple linear SOP with no real design-state boundary

在以下场景中使用此技能：

用户有想法但尚未形成设计方案
任务缺乏范围、边界、核心对象或关键流程
目前没有清晰的设计树
当前设计对话仍处于「我们到底要设计什么？」的阶段
现有设计树缺少
```
design_target_type
```
字段，需要明确该字段

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

已有可用的设计树
主要需求是对现有分支进行深度拆解
主要需求是针对某个明确决策节点对比方案
主要需求是判断设计是否已准备好进入规划阶段
当前设计树仅需深度细化，而非生成全新的衍生树
任务是报告、笔记、总结或文档重写
任务是简单的线性SOP，无实际设计状态边界

Language Strategy

语言策略

Match the design file language to the user's instruction language.

Use this priority order:

An explicit output-language request from the user
The dominant natural language of the user's current instruction
The dominant natural language of the most recent user instructions in the same task
English if the signal is weak or ambiguous

Rules:

Keep the chat response, interactive Q&A, and the design file in the same language
Translate section headings into the chosen language
Keep file paths, code identifiers, template placeholders (e.g.,
```
{{...}}
```
), and literal config keys unchanged
Do not mix languages unless the user explicitly asks for bilingual output
Interactive Q&A in Phase 1 must also match the chosen language

Default heading examples:

If the output language is English:

```
Problem
```
```
Scope
```
```
Included
```
/
```
Excluded
```
```
Assumptions
```
```
Design Tree
```
```
Open Branches
```
```
Decision Nodes
```
```
Decisions
```
```
External Dependencies
```

设计文件的语言需与用户指令语言匹配。

遵循以下优先级顺序：

用户明确提出的输出语言要求
用户当前指令的主导自然语言
同一任务中用户最近指令的主导自然语言
若信号较弱或模糊，默认使用英文

规则：

聊天回复、交互式问答及设计文件需使用同一语言
将章节标题翻译为选定语言
保留文件路径、代码标识符、模板占位符（如
```
{{...}}
```
）及字面配置键不变
除非用户明确要求双语输出，否则请勿混合使用语言
第一阶段的交互式问答也需匹配选定语言

默认标题示例：

若输出语言为英文：

```
Problem
```
```
Scope
```
```
Included
```
/
```
Excluded
```
```
Assumptions
```
```
Design Tree
```
```
Open Branches
```
```
Decision Nodes
```
```
Decisions
```
```
External Dependencies
```

Workflow

工作流

Phase 1: Interactive Confirmation

第一阶段：交互式确认

Confirm the foundation before generating the design tree. Proceed in order:

Design target type — confirm one of
```
system
```
,
```
workflow
```
,
```
methodology
```
,
```
framework
```
Problem — confirm the core problem and success metrics
Scope — confirm what is included and excluded
Assumptions — confirm implicit assumptions being made

After each confirmation, update the shared

design_state

. Do not repeat confirmed content in subsequent conversation.

Skip a section only if the user explicitly provides it upfront (e.g., "the problem is X and the scope is Y" — confirm both in one round).

生成设计树前先确认基础信息，按以下顺序进行：

设计目标类型 — 确认
```
system
```
、
```
workflow
```
、
```
methodology
```
、
```
framework
```
中的一种
问题 — 确认核心问题及成功指标
范围 — 确认包含与排除的内容
假设 — 确认当前隐含的假设条件

每次确认后更新共享的

design_state

，后续对话中请勿重复已确认的内容。

仅当用户提前明确提供某部分内容时（例如：「问题是X，范围是Y」——可在一轮对话中同时确认两者），才可跳过对应章节。

Phase 2: Design Tree Generation

第二阶段：设计树生成

Based on confirmed inputs, generate the design tree using the branch skeleton that matches

design_target_type

Use

../design-tree-core/REFERENCE.md

for shared type definitions and

REFERENCE.md

for preferred local branch skeletons.

If a branch is not relevant, say so explicitly instead of silently omitting it.

In conversation, show only:

the tree diagram
decision nodes that need user action
open branch names
next step recommendation

根据确认的输入，使用与

design_target_type

匹配的分支框架生成设计树。

使用

../design-tree-core/REFERENCE.md

获取共享类型定义，使用

REFERENCE.md

获取首选本地分支框架。

若某分支不相关，请明确说明，而非静默省略。

对话中仅展示：

树状图
需要用户操作的决策节点
未闭合分支名称
下一步建议

Derived Tree Creation

衍生树创建

This skill may also be used to create a derived tree when a parent tree has already identified a new stable problem domain.

Use the shared derivation and handoff rules in

../design-tree-core/REFERENCE.md

as the source of truth.

When creating a derived tree, do all of the following:

Name the parent tree and the derived tree explicitly.
State the reason for derivation.
Define what the derived tree owns.
Define what the derived tree does not own.
Record the minimum parent/child handoff:
- branch being extracted
- inherited constraints
- unresolved questions
- expected output
- return conditions

Do not copy the parent tree into the derived tree. Do not use derivation as a way to dump overflow detail.

当父树已确定新的稳定问题域时，也可使用此技能创建衍生树。

以

../design-tree-core/REFERENCE.md

中的共享衍生与移交规则为依据。

创建衍生树时，需完成以下所有操作：

明确命名父树与衍生树。
说明衍生原因。
定义衍生树负责的内容。
定义衍生树不负责的内容。
记录最少的父子移交信息：
- 提取的分支
- 继承的约束条件
- 未解决的问题
- 预期输出
- 返回条件

请勿将父树内容复制到衍生树中。请勿将衍生作为堆砌冗余细节的方式。

Interactive Q&A

交互式问答

Intent-Driven Strategy

意图驱动策略

Use whatever interactive question tool is available in the current environment. Do not hardcode tool names — describe the interaction intent and constraints; the model selects the right tool based on its environment.

Constraints (cross-CLI compatible):

1–3 questions per prompt
≤ 4 options per question
Structured text (question + optional choices)

Fallback: If no dedicated question tool is available, use natural language prompts (see format templates below).

使用当前环境中可用的任何交互式提问工具。请勿硬编码工具名称——描述交互意图与约束，模型会根据自身环境选择合适的工具。

约束（跨CLI兼容）：

每次提示包含1–3个问题
每个问题最多4个选项
使用结构化文本（问题 + 可选选项）

备选方案： 若没有专用提问工具，使用自然语言提示（见下方格式模板）。

Question Types and Formats

问题类型与格式

Confirmation — state understanding, ask to verify

确认类 — 说明理解内容，请求验证

undefined

undefined

Problem

问题

Core problem: Build an internal API gateway for unified routing, authentication, and rate limiting. Success metrics: P99 latency < 50ms, availability > 99.9%

↑ Is this correct? Anything to amend?

undefined

核心问题：为统一路由、认证与限流构建内部API网关。成功指标：P99延迟 < 50ms，可用性 > 99.9%

↑ 是否正确？有需要修改的内容吗？

undefined

Scope — checklist with include/exclude markers

范围类 — 包含/排除标记的清单

undefined

undefined

Scope

范围

My assessment:

Included ✓

Request routing
Authentication and authorization
Rate limiting
Request logging

Excluded ✗

Service discovery
Load balancing

↑ Any adjustments?

undefined

我的评估：

包含 ✓

请求路由
认证与授权
限流
请求日志

排除 ✗

服务发现
负载均衡

↑ 需要调整吗？

undefined

Decision — table with star ratings, best option first, max 4 options

决策类 — 带星级评分的表格，最优选项优先，最多4个选项

undefined

undefined

Pending Decision: Auth Mode

待决策：认证模式

Option	Rating	Pros	Cons
JWT (stateless)	★★★	Scales horizontally, no server state	Revocation is complex, token size
Session (stateful)	★★	Instant revocation, mature pattern	Requires shared storage, limited scaling
API Key	★	Simple to implement	Low security, not suitable for user-level auth

↑ Which one? Or a different idea?

undefined

选项	评分	优势	劣势
JWT（无状态）	★★★	水平扩展能力强，无服务器状态	吊销流程复杂，令牌体积大
Session（有状态）	★★	即时吊销，成熟模式	需要共享存储，扩展受限
API Key	★	实现简单	安全性低，不适用于用户级认证

↑ 选择哪一个？或者有其他想法？

undefined

Supplement — direct question with relaxed prompt

补充类 — 直接提问，提示宽松

undefined

undefined

Supplementary Info

补充信息

Expected daily request volume?

↑ Please fill in (a rough range is fine if uncertain)


**Rules for all types:**
- One question type per message
- End every question with `↑` marker to signal "your turn"
- After user confirms, do not repeat the confirmed content (it is already captured in `design_state` and will be persisted once the tree is stable enough to reference safely)

预期日请求量是多少？

↑ 请补充信息（不确定的话提供大致范围即可）


**所有类型的规则：**
- 每条消息仅包含一种问题类型
- 每个问题末尾添加`↑`标记，表示「请回复」
- 用户确认后，请勿重复已确认内容（该内容已记录在`design_state`中，当树达到可安全参考的稳定状态后会被持久化存储）

Persistence

持久化存储

Use

REFERENCE.md

for the repo-local save and naming contract. This persistence behavior is a repo-local rule for this repository, not a shared default for the design-tree family.

When the tree first reaches a stable-to-reference threshold, save it to the designated directory

docs/design-tree/

using the path

docs/design-tree/<feature-slug>.md

. Mark the saved document status as

draft

. Do this before handing off to

design-refinement

or any other next design step.

使用

REFERENCE.md

获取仓库本地的存储与命名约定。此持久化行为是本仓库的本地规则，并非设计树体系的通用默认规则。

当树首次达到可参考的稳定阈值时，将其保存到指定目录

docs/design-tree/

，路径为

docs/design-tree/<feature-slug>.md

。将保存的文档状态标记为

draft

。在移交至

design-refinement

或其他后续设计步骤前完成此操作。

Design Tree Requirement

设计树要求

Create an initial design tree that:

makes
```
design_target_type
```
explicit
uses the correct branch skeleton for that target type
identifies open branches
identifies explicit decision nodes
captures assumptions rather than relying on them silently
reaches a stable-to-reference threshold before handoff
keeps the output as
```
design_state
```
first and the saved artifact as the authoritative persisted record

If a branch is not relevant, say so explicitly instead of silently omitting it.

创建的初始设计树需满足：

明确
```
design_target_type
```
使用与目标类型匹配的正确分支框架
识别未闭合分支
识别明确的决策节点
记录假设条件，而非默认依赖这些假设
在移交前达到可参考的稳定阈值
先将输出保存为
```
design_state
```
，再将存储的工件作为权威持久化记录

若某分支不相关，请明确说明，而非静默省略。

Core Responsibilities

核心职责

Your responsibilities are:

Clarify the real goal of the design through interactive confirmation.
Make
```
design_target_type
```
explicit before building the tree.
Capture scope, non-goals, and constraints.
Build an initial design tree with first-level and, where useful, second-level branches.
Identify open branches that still need refinement.
Identify explicit decision nodes that should later go to
```
decision-evaluation
```
.
Record assumptions instead of silently relying on them.
Flag nodes that depend on unverified external tools, APIs, libraries, or services. Perform a lightweight feasibility check (web search or doc lookup) at the time of flagging. If the dependency is clearly infeasible, mark
```
✗
```
immediately; if confirmed feasible with open questions, mark
```
[RESEARCH]
```
with initial findings; if fully confirmed, mark
```
✓
```
.
Persist the design as soon as it first reaches a stable-to-reference threshold into the designated directory
```
docs/design-tree/
```
, and mark the saved document as
```
draft
```
.
If acting on a parent-tree handoff, create a derived tree with explicit parent/child boundaries rather than repeating the parent tree inline.

你的职责包括：

通过交互式确认明确设计的真实目标。
构建树之前明确
```
design_target_type
```
。
记录范围、非目标及约束条件。
构建包含一级分支（必要时包含二级分支）的初始设计树。
识别仍需细化的未闭合分支。
识别后续需移交至
```
decision-evaluation
```
的明确决策节点。
记录假设条件，而非默认依赖这些假设。
标记依赖未验证外部工具、API、库或服务的节点。标记时执行轻量级可行性检查（网页搜索或文档查阅）。若依赖明显不可行，立即标记
```
✗
```
；若已确认可行但仍有未解决问题，标记
```
[RESEARCH]
```
并附上初步结论；若已完全确认可行，标记
```
✓
```
。
一旦设计首次达到可参考的稳定阈值，立即将其持久化存储到指定目录
```
docs/design-tree/
```
，并将保存的文档标记为
```
draft
```
。
若基于父树移交的任务开展工作，需创建具有明确父子边界的衍生树，而非在衍生树中重复父树内容。

Expected Outputs

预期输出

Required Output

必需输出

Produce or update a

design_state

that includes:

```
design_target_type
```
```
problem
```
```
scope
```
```
design_tree
```
```
open_branches
```
```
decision_nodes
```
```
external_dependencies
```
```
status
```

If the tree being created is a derived tree, also include:

parent/child ownership
derivation reason
parent/child handoff

生成或更新包含以下内容的

design_state

：

```
design_target_type
```
```
problem
```
```
scope
```
```
design_tree
```
```
open_branches
```
```
decision_nodes
```
```
external_dependencies
```
```
status
```

若创建的是衍生树，还需包含：

父子职责划分
衍生原因
父子移交信息

Conversation Output (concise)

对话输出（简洁版）

Phase 1: one question at a time (see Question Types)
Phase 2: tree diagram + decision node summaries + open branch names + saved file path +
```
draft
```
status + next step

You are not expected to fully close every branch.

第一阶段：一次一个问题（见问题类型）
第二阶段：树状图 + 决策节点摘要 + 未闭合分支名称 + 保存文件路径 +
```
draft
```
状态 + 下一步建议

无需完全闭合所有分支。

Diagram Conventions

图表约定

Render the design tree as a character tree diagram inside a code block (no language tag).

Format:

design_tree
├── 1. Problem definition
│   ├── 1.1 Core problem
│   └── 1.2 Success metrics ✓
├── 2. Core flows [OPEN]
│   ├── 2.1 Happy path
│   └── 2.2 Error path
├── 3. Interfaces and data
│   └── 3.1 API contract [DRAFT]
├── 4. External integrations
│   └── 4.1 Payment SDK [RESEARCH]
└── 5. Decision points
    └── 5.1 Storage choice [DECISION]

Character rules:

Branches:
```
├──
```
(middle),
```
└──
```
(last)
Continuation:
```
│   
```
(non-last parent),
```
    
```
(last parent, 4 spaces)
Numbering:
```
1.
```
,
```
1.1
```
— required at first two levels
Max width: 78 characters

Status markers:

Marker	Meaning
`[OPEN]`	Unresolved, needs refinement or decision
`[DECISION]`	Decision node with multiple real options
`[DRAFT]`	Tentative, may change
`[RESEARCH]`	Depends on an external tool, API, library, or service that has passed initial feasibility check but needs deeper validation
`✓`	Complete / verified
`✗`	Rejected / out of scope

When to render: Always include a tree diagram when the design tree has 3+ branches. Omit only if the design is trivially small (1-2 branches).

在代码块内（无需语言标签）将设计树渲染为字符树状图。

格式：

design_tree
├── 1. 问题定义
│   ├── 1.1 核心问题
│   └── 1.2 成功指标 ✓
├── 2. 核心流程 [OPEN]
│   ├── 2.1 正常路径
│   └── 2.2 异常路径
├── 3. 接口与数据
│   └── 3.1 API契约 [DRAFT]
├── 4. 外部集成
│   └── 4.1 支付SDK [RESEARCH]
└── 5. 决策点
    └── 5.1 存储方案选择 [DECISION]

字符规则：

分支：
```
├──
```
（中间分支）、
```
└──
```
（最后分支）
延续线：
```
│   
```
（非最后父分支）、
```
    
```
（最后父分支，4个空格）
编号：
```
1.
```
、
```
1.1
```
— 前两级分支必须编号
最大宽度：78个字符

状态标记：

标记	含义
`[OPEN]`	未解决，需细化或决策
`[DECISION]`	存在多个实际选项的决策节点
`[DRAFT]`	暂定，可能变更
`[RESEARCH]`	依赖已通过初步可行性检查但需深度验证的外部工具、API、库或服务
`✓`	已完成 / 已验证
`✗`	已否决 / 超出范围

渲染时机： 当设计树包含3个及以上分支时，始终包含树状图。仅当设计规模极小（1-2个分支）时可省略。

Entry and Exit Criteria

进入与退出标准

Enter when:

there is no meaningful design tree yet
the request is still mostly unstructured

Exit when:

the design tree exists with enough structure for follow-on work
the main remaining work is branch refinement or explicit decision analysis

进入条件：

目前无可用的设计树
请求仍大多为非结构化内容

退出条件：

设计树已存在且具备足够结构支持后续工作
剩余主要工作为分支细化或明确决策分析

Handoff Rules

移交规则

Persist the tree before any downstream design handoff once it first reaches the stable-to-reference threshold.
The first persisted version of the tree must be marked
```
draft
```
.
Hand off to
```
design-refinement
```
as the default next step when the main body exists but branches are still too shallow.
Hand off to
```
decision-evaluation
```
when there is a concrete decision node with real options.
Hand back to
```
design-orchestrator
```
if the design state changed enough that routing should be re-evaluated.
Do not continue past Phase 1 if
```
design_target_type
```
is still unresolved.
Do not force the conversation into option comparison before the design tree is formed.
Do not delay persistence after the stable-to-reference threshold has been reached.

一旦设计首次达到可参考的稳定阈值，在移交至下游设计步骤前先持久化存储树。
树的首个持久化版本必须标记为
```
draft
```
。
当主体结构已存在但分支仍过浅时，默认移交至
```
design-refinement
```
作为下一步。
当存在带有实际选项的具体决策节点时，移交至
```
decision-evaluation
```
。
若设计状态变化较大需要重新评估路由，移交回
```
design-orchestrator
```
。
若
```
design_target_type
```
仍未确定，请勿推进至第一阶段之后。
在设计树形成前，请勿强迫对话进入方案对比环节。
达到可参考的稳定阈值后，请勿延迟持久化存储。

Journal Integration

日志集成

When operating on a task tracked under

.agents/tasks/<task-id>/

, append a journal entry at this skill's milestone.

Trigger: after the design tree reaches the stable-to-reference threshold and is persisted to docs/design-tree/
Reserved key(s):
```
saved
```

Entry shape:

## <ISO8601-timestamp> — design-structure
saved: docs/design-tree/<file>.md
[optional ≤ 15-line body; longer content goes to artifacts/]

Resolve the task id from the explicit caller argument or

.agents/tasks/.current

. If neither resolves, skip the append; do not guess.

See

task-journal

for the full convention.

当处理

.agents/tasks/<task-id>/

下跟踪的任务时，在此技能的里程碑处添加日志条目。

触发时机： 设计树达到可参考的稳定阈值并持久化存储到docs/design-tree/之后
保留键：
```
saved
```

条目格式：

## <ISO8601时间戳> — design-structure
saved: docs/design-tree/<file>.md
[可选 ≤15行正文；更长内容请存入artifacts/]

从明确的调用者参数或

.agents/tasks/.current

中解析任务ID。若两者均无法解析，跳过添加操作；请勿猜测。

完整约定请参考

task-journal

。