analyze

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Analyze (Orchestrator)

分析（编排器）

Run the full analytics pipeline in sequence: research, goal definition, brainstorming, PRD, architecture, and task breakdown. Produces a complete set of interlinked artifacts from a raw idea.

按顺序运行完整的分析流程：调研、目标定义、头脑风暴、PRD、架构设计和任务拆分。从初步想法生成一套完整且相互关联的产物。

When to Use

使用场景

A feature request or idea needs the full treatment: analysis through to task list
The problem is straightforward enough that all 6 steps can flow in one session
You want to minimize manual skill invocation and let the pipeline run

When NOT to use:

The problem is complex or ambiguous — run skills individually with more deliberation at each stage
Only one phase is needed (e.g., just need a PRD for existing requirements) — invoke that skill directly
Upstream artifacts already exist — pick up from the appropriate skill in the chain

某个功能需求或想法需要完整处理：从分析到生成任务列表
问题足够简单，6个步骤可在一个会话中顺畅推进
希望尽量减少手动调用技能，让流程自动运行

不适用场景：

问题复杂或模糊——在每个阶段更审慎地单独调用技能
仅需单个阶段（例如，仅需为现有需求生成PRD）——直接调用对应技能
上游产物已存在——从流程链中的对应技能开始

Input

输入

A raw idea, feature request, or problem description from the user
A codebase to analyze (current workspace or specified path)

用户提供的初步想法、功能需求或问题描述
待分析的代码库（当前工作区或指定路径）

Output

输出

A complete artifact folder containing:

```
context-map.md
```
```
goal-definition.md
```
```
brainstorming.md
```
```
prd.md
```
```
architecture.md
```
```
tasks.md
```

一个完整的产物文件夹，包含：

```
context-map.md
```
```
goal-definition.md
```
```
brainstorming.md
```
```
prd.md
```
```
architecture.md
```
```
tasks.md
```

The Pipeline

流程

research → goal-definition → brainstorming → prd → architecture → breakdown

Each step produces an artifact that the next step consumes. Human review gates occur between phases.

research → goal-definition → brainstorming → prd → architecture → breakdown

每个步骤生成的产物会被下一个步骤使用。各阶段之间设有人工审核环节。

The Process

执行步骤

Step 1: Determine Artifact Folder

步骤1：确定产物文件夹

Ask the user for the artifact folder, or accept one specified in chat:

"Where should I save the analysis artifacts? Provide a folder path (e.g.
docs/analytics/user-auth/
), or I'll use
docs/analytics/
as default."

Create the folder if it doesn't exist.

询问用户产物保存路径，或接受聊天中指定的路径：

“我应该将分析产物保存到哪里？请提供文件夹路径（例如
docs/analytics/user-auth/
），否则我将使用默认路径
docs/analytics/
。”

如果文件夹不存在则创建。

Step 2: Run Research

步骤2：运行调研

Before scanning, check for existing project documentation listed in

references/context-sources.md

(

docs/TechStack.md

docs/ProjectStructure.md

). If they exist and are fresh, use them to accelerate the research phase.

Follow the

research

skill process:

Scan codebase structure, tech stack, patterns, conventions
Find rules files, note constraints
Save
```
context-map.md
```

Present a brief summary and confirm before continuing:

"Context mapped. Key findings: [tech stack], [N patterns identified], [any notable constraints]. Continue to goal definition?"

扫描前，检查

references/context-sources.md

中列出的现有项目文档（如

docs/TechStack.md

、

docs/ProjectStructure.md

）。如果这些文档存在且内容最新，可用于加速调研阶段。

遵循

research

技能流程：

扫描代码库结构、技术栈、模式、约定
查找规则文件，记录约束条件
保存
```
context-map.md
```

展示简要总结并确认是否继续：

“已完成上下文梳理。关键发现：[技术栈]、[已识别N种模式]、[任何值得注意的约束条件]。是否继续进行目标定义？”

Step 3: Run Goal Definition

步骤3：运行目标定义

Follow the

goal-definition

skill process:

Restate the idea as "How Might We"
Ask 3-5 sharpening questions (one at a time)
Surface assumptions
Define testable success criteria
Save
```
goal-definition.md
```

Present the goal and confirm before continuing:

"Goal defined: [problem statement]. [N success criteria]. Continue to brainstorming?"

遵循

goal-definition

技能流程：

将想法重述为“我们如何才能...”的形式
提出3-5个细化问题（逐个提出）
梳理假设条件
定义可测试的成功标准
保存
```
goal-definition.md
```

展示目标内容并确认是否继续：

“已完成目标定义：[问题陈述]。[N条成功标准]。是否继续进行头脑风暴？”

Step 4: Run Brainstorming

步骤4：运行头脑风暴

Follow the

brainstorming

skill process:

Scan for prior art in the codebase
Generate 2-3 approaches with trade-offs
Present comparison and recommendation
Get user to pick a direction
Save
```
brainstorming.md
```

Present the chosen direction and confirm before continuing:

"Direction chosen: [approach name]. Continue to PRD?"

遵循

brainstorming

技能流程：

在代码库中查找现有方案
生成2-3种方案并说明权衡点
展示对比结果并给出推荐
让用户选择方向
保存
```
brainstorming.md
```

展示选定的方向并确认是否继续：

“已选定方向：[方案名称]。是否继续进行PRD编写？”

Step 5: Run PRD

步骤5：运行PRD编写

Follow the

prd

skill process:

Ask 3-5 clarifying questions where gaps exist
Write user stories with acceptance criteria
Write functional requirements
Define non-goals and success metrics
Save
```
prd.md
```

Present the PRD summary and confirm before continuing:

"PRD complete: [N user stories], [N functional requirements], [N non-goals]. Continue to architecture?"

遵循

prd

技能流程：

针对存在的空白提出3-5个澄清问题
编写包含验收标准的用户故事
编写功能需求
定义非目标和成功指标
保存
```
prd.md
```

展示PRD摘要并确认是否继续：

“PRD已完成：[N个用户故事]、[N条功能需求]、[N条非目标]。是否继续进行架构设计？”

Step 6: Run Architecture

步骤6：运行架构设计

Follow the

architecture

skill process:

Identify components with responsibilities and locations
Map data flow and dependency graph
Document tech decisions and integration points
Define boundaries, identify risks
Save
```
architecture.md
```

Present architecture summary and confirm before continuing:

"Architecture designed: [N components], [key tech decisions]. Continue to task breakdown?"

遵循

architecture

技能流程：

识别组件及其职责和位置
绘制数据流和依赖关系图
记录技术决策和集成点
定义边界，识别风险
保存
```
architecture.md
```

展示架构摘要并确认是否继续：

“架构设计已完成：[N个组件]、[关键技术决策]。是否继续进行任务拆分？”

Step 7: Run Breakdown

步骤7：运行任务拆分

Follow the

breakdown

skill process:

Map dependency graph to build order
Slice vertically, size each task
Write tasks with acceptance criteria and verification
Group into phases with checkpoints
Classify parallelization opportunities
Save
```
tasks.md
```

Present the final summary:

"Pipeline complete. Artifact folder
[path]
contains:
context-map.md
— codebase context
goal-definition.md
— problem and success criteria
brainstorming.md
— approaches and chosen direction
prd.md
— requirements with acceptance criteria
architecture.md
— technical design
tasks.md
— [N tasks] in [N phases], ready for implementation"

遵循

breakdown

技能流程：

将依赖关系图映射为构建顺序
垂直拆分任务，估算每个任务的规模
编写包含验收标准和验证方式的任务
按阶段分组并设置检查点
识别可并行处理的任务
保存
```
tasks.md
```

展示最终总结：

“流程已完成。产物文件夹
[路径]
包含：
context-map.md
— 代码库上下文
goal-definition.md
— 问题和成功标准
brainstorming.md
— 方案和选定方向
prd.md
— 包含验收标准的需求
architecture.md
— 技术设计
tasks.md
— [N个任务]分为[N个阶段]，可直接用于开发”

Human Review Gates

人工审核环节

Between every phase, ask the user to confirm before proceeding. Do not skip gates.

If the user wants to revise an earlier phase:

Go back to that phase
Update the artifact
Assess whether downstream artifacts need updating
Continue from the revised phase forward

If the user wants to stop mid-pipeline, that's fine. The artifacts saved so far are valid. The user can resume from any point by invoking the appropriate skill directly.

每个阶段之间，必须询问用户确认后再继续。不得跳过审核环节。

如果用户希望修改之前的阶段：

返回对应阶段
更新产物
评估下游产物是否需要更新
从修改后的阶段继续推进

如果用户希望中途停止流程，也可终止。目前已保存的产物均有效。用户可通过直接调用对应技能从任意节点恢复流程。

Common Rationalizations

常见误区

Rationalization	Reality
"This is simple, just give me the tasks"	Simple problems still benefit from explicit goals and requirements. The orchestrator moves quickly through simple cases.
"The review gates slow things down"	Review gates catch wrong directions early. Fixing a goal is cheaper than fixing a task list.
"I'll skip brainstorming, I know the approach"	Even obvious approaches have trade-offs worth documenting. Brainstorming takes 5 minutes in the orchestrator.

错误认知	实际情况
“这个很简单，直接给我任务就行”	即使是简单问题，明确的目标和需求也能带来价值。编排器处理简单案例时速度很快。
“审核环节拖慢了进度”	审核环节能尽早发现错误方向。修正目标的成本远低于修正任务列表的成本。
“我知道该用什么方案，跳过头脑风暴”	即使是显而易见的方案也有值得记录的权衡点。编排器中的头脑风暴仅需5分钟。

Red Flags

验证

Skipping review gates between phases
Proceeding when the user expressed doubt or confusion
Producing a task list without the user confirming the PRD
Artifacts that don't reference each other (broken chain)
Not saving artifacts to the folder (keeping everything in conversation)

流程结束时，确认以下内容：

所有6种产物均存在于产物文件夹中
每个产物均引用了上游产物
用户已确认每个审核环节
任务列表中的每个任务都包含验收标准和验证方式
任务依赖关系排序正确
已向用户告知产物文件夹路径

Verification

—

At the end of the pipeline, confirm:

All 6 artifacts exist in the artifact folder
Each artifact references its upstream artifacts
User confirmed at each review gate
Task list has acceptance criteria and verification for every task
Task dependencies are ordered correctly
Artifact folder path communicated to user

—