plan

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Structured Planning

结构化规划

Verification-driven task decomposition with Sibyl-native tracking. Mined from 200+ real planning sessions — the plans that actually survived contact with code.

Core insight: Plans fail when steps can't be verified. Decompose until every step has a concrete check. Track in Sibyl so plans survive context windows.

采用验证驱动的任务分解，内置Sibyl原生跟踪能力。提炼自200多场真实规划会议——都是真正落地到代码层面的有效规划方案。

核心观点： 如果步骤无法验证，规划就会失败。持续拆分直到每个步骤都有具体的校验方式。在Sibyl中跟踪进度，确保规划不会受上下文窗口限制失效。

The Process

流程

dot

digraph planning {
    rankdir=TB;
    node [shape=box];

    "1. SCOPE" [style=filled, fillcolor="#e8e8ff"];
    "2. EXPLORE" [style=filled, fillcolor="#ffe8e8"];
    "3. DECOMPOSE" [style=filled, fillcolor="#e8ffe8"];
    "4. VERIFY & APPROVE" [style=filled, fillcolor="#fff8e0"];
    "5. TRACK" [style=filled, fillcolor="#e8e8ff"];

    "1. SCOPE" -> "2. EXPLORE";
    "2. EXPLORE" -> "3. DECOMPOSE";
    "3. DECOMPOSE" -> "4. VERIFY & APPROVE";
    "4. VERIFY & APPROVE" -> "5. TRACK";
    "4. VERIFY & APPROVE" -> "3. DECOMPOSE" [label="gaps found", style=dashed];
}

dot

digraph planning {
    rankdir=TB;
    node [shape=box];

    "1. SCOPE" [style=filled, fillcolor="#e8e8ff"];
    "2. EXPLORE" [style=filled, fillcolor="#ffe8e8"];
    "3. DECOMPOSE" [style=filled, fillcolor="#e8ffe8"];
    "4. VERIFY & APPROVE" [style=filled, fillcolor="#fff8e0"];
    "5. TRACK" [style=filled, fillcolor="#e8e8ff"];

    "1. SCOPE" -> "2. EXPLORE";
    "2. EXPLORE" -> "3. DECOMPOSE";
    "3. DECOMPOSE" -> "4. VERIFY & APPROVE";
    "4. VERIFY & APPROVE" -> "5. TRACK";
    "4. VERIFY & APPROVE" -> "3. DECOMPOSE" [label="gaps found", style=dashed];
}

Phase 1: SCOPE

阶段1：范围界定（SCOPE）

Bound the work before exploring it.

在探索工作内容前先明确工作边界。

Actions

操作步骤

Search Sibyl for related tasks, decisions, prior plans:

sibyl search "<feature keywords>"
sibyl task list -s todo

Define success criteria — what does "done" look like?
- Measurable outcomes (tests pass, endpoint returns X, UI renders Y)
- NOT vague goals ("improve performance" → "p95 latency < 200ms")
Identify constraints:
- Files/modules that CAN'T change
- Dependencies that must be respected
- Timeline or budget considerations

Classify complexity:

Scale	Description	Planning Depth
Quick fix	< 3 files, clear solution	Skip to implementation
Feature	3-10 files, known patterns	Light plan (this skill)
Epic	10+ files, new patterns	Full plan + orchestration
Redesign	Architecture change	Full plan + research first

在Sibyl中搜索相关任务、决策、历史规划：

sibyl search "<feature keywords>"
sibyl task list -s todo

定义成功标准——“完成”的具体表现是什么？
- 可衡量的结果（测试通过、接口返回X、UI渲染出Y）
- 禁止模糊目标（不要写“提升性能”，要写“p95延迟低于200ms”）
明确约束条件：
- 不能修改的文件/模块
- 必须遵守的依赖关系
- 时间线或预算限制

复杂度分级：

规模	描述	规划深度
快速修复	修改少于3个文件，解决方案清晰	直接进入开发
功能需求	修改3-10个文件，有已知实现模式	轻量规划（使用本技能）
史诗任务	修改10+个文件，需要新实现模式	完整规划+任务编排
重构/重设计	架构变更	先做调研再输出完整规划

Gate

准入判断

If this is a quick fix, stop planning and go build. Planning a 5-minute fix is waste.

如果是快速修复，停止规划直接开发。为5分钟就能完成的工作做规划是浪费时间。

Phase 2: EXPLORE

阶段2：探索调研（EXPLORE）

Understand the codebase surface area before decomposing.

在拆分任务前先了解代码库的影响范围。

Actions

操作步骤

Map the impact surface — which files/modules will this touch?
- Spawn an Explore agent if the scope is uncertain
- Read the actual code, don't guess from file names
Identify existing patterns:
- How does similar functionality work in this codebase?
- What conventions exist? (naming, file structure, test patterns)
Find the dependencies:
- What must exist before this can work?
- What will break if we change X?

梳理影响面——本次修改会涉及哪些文件/模块？
- 如果范围不明确，可以启动Explore Agent调研
- 阅读实际代码，不要只通过文件名猜测
识别现有模式：
- 代码库中类似功能是怎么实现的？
- 有哪些约定规范？（命名、文件结构、测试模式）
梳理依赖关系：
- 功能实现前置需要哪些依赖？
- 如果修改X会导致哪些内容失效？

Output

阶段输出

A mental model of the change surface:

"This touches: [module A] (new endpoint), [module B] (type changes), [module C] (tests). Pattern follows [existing feature X]. Depends on [infrastructure Y] being available."

形成变更范围的认知模型：

"本次修改涉及：[模块A]（新增接口）、[模块B]（类型变更）、[模块C]（测试用例）。实现模式参考[现有功能X]。依赖[基础设施Y]就绪。"

Phase 3: DECOMPOSE

阶段3：任务拆分（DECOMPOSE）

Break work into verifiable steps. Every step must have a check.

将工作拆解为可验证的步骤，每个步骤都要有校验方式。

The Verification Rule

验证规则

A step without a verification method is not a step — it's a hope.

For each task, define:

Field	Description
What	Specific implementation action
Files	Exact files to create/modify
Verify	How to confirm it works
Depends on	Which tasks must complete first

没有验证方式的步骤不是有效步骤，只是空想。

每个任务都需要定义以下内容：

字段	描述
做什么	具体的开发动作
涉及文件	需要创建/修改的精确文件路径
验证方式	如何确认功能正常运行
依赖任务	需要先完成的前置任务

Verification Methods

验证方式参考

Method	When to Use
`typecheck`	Type changes, interface additions
`test`	Logic, edge cases, integrations
`lint`	Style, formatting, import order
`build`	Build system changes
`visual`	UI changes (screenshot or browser check)
`curl/httpie`	API endpoint changes
`manual`	Only when no automation exists

方式	适用场景
`typecheck`	类型变更、新增接口
`test`	逻辑修改、边界场景、集成功能
`lint`	代码风格、格式化、导入顺序调整
`build`	构建系统变更
`visual`	UI变更（截图或浏览器校验）
`curl/httpie`	API接口变更
`manual`	无自动化校验方案的场景

Decomposition Heuristics

拆分原则

2-5 minute tasks are the sweet spot. If a task takes > 15 minutes, break it further.
One concern per task. "Add endpoint AND write tests" is two tasks.
Order by dependency, not difficulty. Foundation first.
Mark parallelizable tasks. Tasks with no shared files can run simultaneously.

2-5分钟可完成的任务是最优粒度，如果一个任务预估耗时超过15分钟，继续拆分。
每个任务只做一件事，“新增接口+编写测试”是两个独立任务。
按依赖关系排序，而非难度，优先完成基础任务。
标记可并行任务，没有共享修改文件的任务可以同时执行。

Task Format

任务格式模板

markdown

undefined

markdown

undefined

Task [N]: [Imperative title]

任务 [N]：[祈使句标题]

Files:

src/path/file.ts

tests/path/file.test.ts

Depends on: Task [M] Parallel: Yes/No (can run alongside Task [X])

涉及文件：

src/path/file.ts

tests/path/file.test.ts

依赖任务： 任务 [M] 可并行： 是/否（可与任务 [X] 并行执行）

Implementation

实现内容

[2-4 bullet points of what to do]

[2-4个要点说明要做的操作]

Verify

验证方式

```
pnpm typecheck
```
passes
```
pnpm test -- file.test.ts
```
passes
[specific assertion about behavior]

undefined

```
pnpm typecheck
```
执行通过
```
pnpm test -- file.test.ts
```
执行通过
[具体的行为校验规则]

undefined

Parallelizability Markers

并行标记方式

Mark tasks that can run simultaneously for orchestration:

Wave 1 (foundation):  Task 1, Task 2  [parallel]
Wave 2 (core):        Task 3, Task 4  [parallel, depends on Wave 1]
Wave 3 (integration): Task 5          [sequential, depends on Wave 2]
Wave 4 (polish):      Task 6, Task 7  [parallel, depends on Wave 3]

标记可同时执行的任务用于后续编排：

第一波（基础层）：  任务1、任务2  [可并行]
第二波（核心层）：  任务3、任务4  [可并行，依赖第一波完成]
第三波（集成层）：  任务5          [串行，依赖第二波完成]
第四波（优化层）：  任务6、任务7  [可并行，依赖第三波完成]

Phase 4: VERIFY & APPROVE

阶段4：验证与审批（VERIFY & APPROVE）

Review the plan before executing it.

执行前先审核规划内容。

Self-Check

自检清单

Present for Approval

提交审批格式

Show the plan as a structured list with waves:

markdown

undefined

按波次结构化展示规划：

markdown

undefined

Plan: [Feature Name]

规划：[功能名称]

Success criteria: [measurable outcome] Estimated tasks: [N] across [M] waves Parallelizable: [X]% of tasks can run in parallel

成功标准： [可衡量的结果] 预估任务数： [N]个，分为[M]波 并行占比： [X]%的任务可并行执行

Wave 1: Foundation

第一波：基础搭建

Task 1: [title] → verify: [method]
Task 2: [title] → verify: [method]

任务1：[标题] → 验证方式：[方法]
任务2：[标题] → 验证方式：[方法]

Wave 2: Core Implementation

第二波：核心实现

Task 3: [title] → verify: [method] (depends: 1)
Task 4: [title] → verify: [method] (depends: 2)

任务3：[标题] → 验证方式：[方法]（依赖：1）
任务4：[标题] → 验证方式：[方法]（依赖：2）

Wave 3: Integration

第三波：集成验证

Task 5: [title] → verify: [method] (depends: 3, 4)

undefined

任务5：[标题] → 验证方式：[方法]（依赖：3、4）

undefined

Gap Analysis

差距分析

After presenting, explicitly check:

"Is there anything missing from this plan?"
"Should any of these tasks be combined or split further?"
"Are the success criteria right?"

提交规划后主动确认：

“这份规划有没有遗漏的内容？”
“有没有任务需要合并或者进一步拆分？”
“成功标准是否准确？”

Phase 5: TRACK

阶段5：跟踪管理（TRACK）

Register the plan in Sibyl for persistence.

将规划录入Sibyl持久化存储。

Actions

操作步骤

Create a Sibyl task for the feature:

sibyl task create --title "[Feature]" -d "[success criteria]" --complexity epic

Create sub-tasks for each plan step:

sibyl task create --title "Task 1: [title]" -e [epic-id] -d "[implementation + verify]"

Record the plan decision:

sibyl add "Plan: [feature]" "[N] tasks across [M] waves. Key decisions: [architectural choices]. Dependencies: [critical path]."

为功能创建Sibyl主任务：

sibyl task create --title "[功能名称]" -d "[成功标准]" --complexity epic

为每个规划步骤创建子任务：

sibyl task create --title "任务1：[标题]" -e [史诗任务ID] -d "[实现内容+验证方式]"

记录规划决策：

sibyl add "规划：[功能名称]" "[N]个任务分为[M]波。核心决策：[架构选择]。依赖关系：[关键路径]。"

Adaptive Replanning

自适应重规划

Plans change when they meet reality. When a task reveals unexpected complexity:

Don't force through. Pause and reassess.
Update the plan — add/remove/modify tasks.
Update Sibyl — keep the tracking current.
Communicate — "Task 3 revealed [X]. Adjusting plan: [changes]."

实际执行中规划可能会发生变化，当某个任务暴露了预期外的复杂度时：

不要硬推，暂停并重新评估。
更新规划——新增/删除/修改任务。
更新Sibyl——保持跟踪信息同步。
同步变更——“任务3暴露了[问题]，调整规划为：[变更内容]。”

Execution Handoff

执行移交

Once the plan is approved, hand off to the right tool:

Situation	Handoff
3-5 simple tasks, user present	Execute directly with verification gates
5-15 tasks, mixed parallel	`/hyperskills:orchestrate` with wave strategy
Large epic, 15+ tasks	Orchestrate with Epic Parallel Build strategy
Needs more research first	`/hyperskills:research` before executing

规划获批后，根据场景移交到对应工具处理：

场景	移交方式
3-5个简单任务，用户在线	按验证关卡直接执行
5-15个任务，混合并行	调用 `/hyperskills:orchestrate` 按波次策略编排
大型史诗任务，15+个任务	采用史诗并行构建策略编排
需要先做更多调研	执行前调用 `/hyperskills:research`

Trust Gradient for Execution

执行信任梯度

Phase	Review Level	When
Full ceremony	Implement + spec review + code review	First 3-4 tasks
Standard	Implement + spec review	Tasks 5-8, patterns stabilized
Light	Implement + quick verify	Late tasks, established patterns

This is earned confidence, not cutting corners.

阶段	审核级别	适用场景
全流程审核	实现+规格评审+代码评审	前3-4个任务
标准审核	实现+规格评审	第5-8个任务，模式稳定后
轻量审核	实现+快速验证	后期任务，模式已成熟

这是逐步建立信任的过程，不是偷工减料。

What This Skill is NOT

本技能的适用边界

Not required for simple tasks. If the solution is obvious, just build it.
Not a design doc generator. Plans are action lists, not architecture documents.
Not a blocker. If the user says "just start building," start building. You can plan in parallel.
Not rigid. Plans adapt. The first plan is a hypothesis.

简单任务无需使用，如果解决方案很明确，直接开发即可。
不是设计文档生成工具，规划是行动清单，不是架构文档。
不是开发阻塞点，如果用户说“直接开始开发”，可以边开发边并行规划。
不是刚性规则，规划可以调整，第一版规划只是假设。