plan-to-task-list-with-dag

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

<EXTREMELY-IMPORTANT> This skill creates schedulable plan artifacts, not loose planning prose.

Non-negotiable rules:

Start with scope challenge and mode selection using AskUserQuestion.
Explore existing code before decomposing. Never invent file paths.
Build one canonical plan object, then emit both markdown and JSON from it.
Every task must have explicit ownership, validation, dependency handling, and an Agent field.
Keep the skill body focused on workflow. Load plan schema, agent mapping, and examples from references.
Every task needs 2-3 testable acceptance criteria, at least one covering a failure or edge case.
Never create tasks touching more than 3 files, never create circular dependencies, never assume codebase structure.
If a task claims side effects (persistence, WAL, network I/O, registration), state where the capability comes from.
For new files, explicitly assign export/registration/wiring ownership to a task.
If a task can be "completed" with placeholders or dead wiring, split semantic hardening into an explicit follow-up.
Treat JSON as the source of truth. Render markdown from the same canonical plan object.
Do not use vague contract language ("internal update", "eventually skipped", "graceful degradation") without defining owner, behavior, and recovery.
Distinguish local reuse from external references. Do not present external docs or clones as local code.

</EXTREMELY-IMPORTANT>

<EXTREMELY-IMPORTANT> 本技能生成可调度的计划产物，而非松散的规划文本。

不可违背的规则：

首先使用AskUserQuestion发起范围确认并选择模式。
分解任务前先调研现有代码。切勿虚构文件路径。
构建一个标准的计划对象，再基于它生成Markdown和JSON两种格式输出。
每个任务必须明确包含负责人、验证方式、依赖处理及Agent字段。
技能主体需聚焦于工作流。从参考资料中加载计划schema、Agent映射及示例。
每个任务需包含2-3条可测试的验收标准，其中至少一条覆盖故障或边缘场景。
切勿创建涉及超过3个文件的任务，切勿创建循环依赖，切勿假设代码库结构。
如果任务涉及副作用（持久化、WAL、网络I/O、注册），需说明该能力的来源。
对于新文件，需明确将导出/注册/连接的职责分配给某个任务。
如果某个任务可以通过占位符或无效连接"完成"，需将语义强化拆分为明确的后续任务。
将JSON作为事实来源。基于同一标准计划对象渲染Markdown。
不得使用模糊的契约语言（如"内部更新"、"最终跳过"、"优雅降级"），除非明确定义负责人、行为及恢复方式。
区分本地复用与外部引用。不得将外部文档或克隆内容当作本地代码呈现。

</EXTREMELY-IMPORTANT>

Plan To Task List With DAG

基于DAG的任务列表规划

Inputs

输入

```
$request
```
: Optional feature or planning request text

```
$request
```
：可选的功能或规划请求文本

Goal

目标

Produce a concrete task DAG that is safe to execute:

scope-challenged
grounded in real repository structure
atomic enough for parallel work

persisted to

.ulpi/plans/<plan-name>.md

and

.ulpi/plans/<plan-name>.json

生成可安全执行的具体任务DAG：

经过范围确认
基于真实仓库结构
原子化程度支持并行工作

持久化到

.ulpi/plans/<plan-name>.md

和

.ulpi/plans/<plan-name>.json

Step 0: Challenge scope before planning

步骤0：规划前确认范围

Before decomposing, do a quick overlap check:

prefer the
```
codemap
```
skill if available for semantic search
otherwise use
```
Glob
```
,
```
Grep
```
, and
```
Read
```

Identify:

what already exists
what can be reused
what is truly new
likely prerequisites
likely non-goals
whether the request is small enough to execute directly instead of planning

Then use

AskUserQuestion

to confirm:

planning mode:
```
EXPANSION
```
,
```
HOLD
```
, or
```
REDUCTION
```
default post-task review:
```
claude
```
,
```
codex
```
,
```
kiro
```
,
```
all
```
, or
```
none
```
any scope cuts or explicit non-goals

Do not proceed until the scope framing is confirmed.

Success criteria: The user has confirmed the scope, selected a planning mode, and chosen a default review posture.

在分解任务前，先快速检查重叠内容：

如果有
```
codemap
```
技能，优先使用它进行语义搜索
否则使用
```
Glob
```
、
```
Grep
```
和
```
Read
```

确认以下内容：

已存在的内容
可复用的内容
真正需要新增的内容
可能的前置条件
明确的非目标
请求是否足够小，可以直接执行而无需规划

然后使用

AskUserQuestion

确认：

规划模式：
```
EXPANSION
```
、
```
HOLD
```
或
```
REDUCTION
```
默认任务后审核：
```
claude
```
、
```
codex
```
、
```
kiro
```
、
```
all
```
或
```
none
```
任何范围缩减或明确的非目标

在范围框架确认前，不得继续推进。

成功标准：用户已确认范围、选择规划模式并选定默认审核方式。

Step 1: Explore the real code surface

步骤1：调研真实代码范围

Explore the repository before writing any task:

likely modules and directories involved
existing code that partially solves the request
shared integration surfaces:
- package roots
- export barrels
- registries
- routers
- manifests
- startup hooks
public surfaces:
- API routes
- CLI commands
- config files
- schemas
- persisted formats

Rules:

prefer semantic search via
```
codemap
```
skill when available
use
```
Grep
```
for exact-string validation
use
```
Read
```
on the actual files before naming them in tasks
never invent paths, modules, or existing helpers

Success criteria: Every path named in the plan comes from observed repository state.

在编写任何任务前，先调研仓库内容：

可能涉及的模块和目录
已存在的可部分满足请求的代码
共享集成面：
- 包根目录
- 导出桶（export barrels）
- 注册中心
- 路由
- 清单
- 启动钩子
公共面：
- API路由
- CLI命令
- 配置文件
- 模式（schemas）
- 持久化格式

规则：

如果有
```
codemap
```
技能，优先使用它进行语义搜索
使用
```
Grep
```
进行精确字符串验证
在任务中提及文件前，先使用
```
Read
```
读取实际文件
切勿虚构路径、模块或已存在的辅助工具

成功标准：计划中提及的每个路径均来自已观测的仓库状态。

Step 2: Capture planning contracts

步骤2：记录规划契约

Before tasking, record the conditions that make the plan valid:

prerequisites
non-goals
cross-boundary contracts
capability providers for side effects
shared integration points
ship cut if execution stops halfway

Explicitly note:

where persistence comes from
who owns export and registration edits
which public surfaces must remain stable
which failure paths or isolation invariants must be preserved

Success criteria: The plan explains what must already be true and what is explicitly out of scope.

在拆分任务前，记录使计划有效的条件：

前置条件
非目标
跨边界契约
副作用能力提供者
共享集成点
中途停止执行时的交付边界

明确标注：

持久化能力的来源
导出和注册编辑的负责人
必须保持稳定的公共面
必须保留的故障路径或隔离不变量

成功标准：计划说明必须已满足的条件及明确的范围外内容。

Step 3: Decompose into atomic tasks

步骤3：拆分为原子任务

Create tasks that are:

atomic
file-scoped
dependency-aware
reviewable

Task rules:

prefer 1 to 3 files per task
every file in
```
writeScope
```
must have an explicit role
every task needs:
- ```
TASK-NNN
```
  id
- title
- description
- ```
Type
```
- ```
Priority
```
- ```
Effort
```
- ```
Agent
```
  (see Agent Selection Reference in
```
references/output-format.md
```
  )
- acceptance criteria
- ```
writeScope
```
- ```
validateCommand
```
include 2-3 testable acceptance criteria per task; at least one must cover a failure or edge case
for public surfaces, pin the exact signature/examples and add a wrong-shape or wrong-routing check
for rewrite or composition tasks, add at least one criterion proving existing semantics were not silently dropped
if a new file needs export or registration, assign that ownership to a specific task
if a task only creates structure and semantic hardening is still needed, split that follow-up explicitly

Success criteria: Each task is executable without hidden context and small enough for independent review.

创建满足以下要求的任务：

原子化
按文件划分范围
感知依赖关系
可审核

任务规则：

每个任务优先涉及1-3个文件
```
writeScope
```
中的每个文件必须有明确角色
每个任务需包含：
- ```
TASK-NNN
```
  编号
- 标题
- 描述
- ```
Type
```
  （类型）
- ```
Priority
```
  （优先级）
- ```
Effort
```
  （工作量）
- ```
Agent
```
  （参考
```
references/output-format.md
```
  中的Agent选择参考）
- 验收标准
- ```
writeScope
```
  （写入范围）
- ```
validateCommand
```
  （验证命令）
每个任务包含2-3条可测试的验收标准；至少一条需覆盖故障或边缘场景
对于公共面，固定精确的签名/示例，并添加错误形态或错误路由检查
对于重写或组合任务，至少添加一条标准证明现有语义未被静默丢弃
如果新文件需要导出或注册，将该职责分配给特定任务
如果某个任务仅创建结构，仍需语义强化，则将后续工作明确拆分

成功标准：每个任务无需隐藏上下文即可执行，且足够小以支持独立审核。

Step 4: Map dependencies and maximize parallelism

步骤4：映射依赖关系并最大化并行性

Add dependencies only when they are real:

file overlap
data flow
API contract
shared integration surface
capability provider
lifecycle or bootstrap dependency

Do not over-constrain:

independent tasks should stay parallel
shared-file edits should be made explicit rather than hidden
circular dependencies are invalid

Use

P0

through

P3

priorities:

```
P0
```
: foundations that unblock other tasks
```
P1
```
: core feature work
```
P2
```
: supporting work and edge cases
```
P3
```
: optional polish, docs, or cleanup

Success criteria: The dependency graph is acyclic, minimal, and exposes real parallel layers.

仅在存在真实依赖时添加依赖：

文件重叠
数据流
API契约
共享集成面
能力提供者
生命周期或启动依赖

避免过度约束：

独立任务应保持并行
共享文件的编辑需明确标注，而非隐藏
禁止循环依赖

使用

P0

至

P3

优先级：

```
P0
```
：为其他任务解除阻塞的基础工作
```
P1
```
：核心功能工作
```
P2
```
：支持性工作及边缘场景
```
P3
```
：可选的优化、文档或清理工作

成功标准：依赖图无环、最小化，并体现真实的并行层级。

Step 5: Render markdown and JSON from one canonical plan object

步骤5：基于标准计划对象渲染Markdown和JSON

Before writing output, load

references/output-format.md

Write both files:

```
.ulpi/plans/<plan-name>.md
```
```
.ulpi/plans/<plan-name>.json
```

Requirements:

markdown and JSON must describe the same tasks
task ids must match exactly in both files
dependency JSON is the source of truth
markdown must not contain
```
[PLAN]
```
markers on disk

Success criteria: Both artifacts exist and describe the same DAG.

在输出前，加载

references/output-format.md

。

写入两个文件：

```
.ulpi/plans/<plan-name>.md
```
```
.ulpi/plans/<plan-name>.json
```

要求：

Markdown和JSON必须描述相同的任务
任务编号在两个文件中必须完全匹配
JSON格式的依赖关系为事实来源
磁盘上的Markdown不得包含
```
[PLAN]
```
标记

成功标准：两种格式的产物均存在，并描述相同的DAG。

Step 6: Validate before finishing

步骤6：完成前验证

Run a final structural pass:

all task ids exist in markdown and JSON
every dependency target exists
no cycles
no phantom file paths
no task exceeds sensible write scope
acceptance criteria include edge or failure behavior where needed
review default is present

Load

references/examples.md

only if you need a pattern for presentation shape.

Success criteria: The plan is schedulable, internally consistent, and ready for execution.

执行最终结构检查：

所有任务编号均存在于Markdown和JSON中
每个依赖目标均存在
无循环依赖
无虚构文件路径
无任务超出合理的写入范围
必要时验收标准包含边缘或故障行为
默认审核方式已明确

仅在需要参考展示格式时加载

references/examples.md

。

成功标准：计划可调度、内部一致且准备就绪可执行。

Guardrails

约束规则

Do not skip AskUserQuestion-based scope challenge.
Do not turn this into direct implementation.
Do not invent existing files, helpers, or package boundaries.
Do not keep giant examples or output templates inline in
```
SKILL.md
```
.
Do not add
```
paths:
```
. This is a generic workflow skill.
Do not add
```
context: fork
```
. This workflow depends on user interaction mid-process.
Do not introduce agent-only headers.
Do not create tasks that touch more than 3 files.
Do not over-constrain dependencies -- independent tasks must stay parallel.
Do not hide required shared-file edits behind narrow write scopes.
Do not let a task claim side effects that require capabilities the task never defines.
Do not present external docs, clones, or web research as local code unless the path exists in the repo.
Do not use P1-P4 priorities. This skill uses P0-P3.
Do not hand-maintain counts, layer summaries, or dependency references separately between JSON and markdown -- derive from canonical plan object.

不得跳过基于AskUserQuestion的范围确认步骤。
不得直接转向实现工作。
不得虚构已存在的文件、辅助工具或包边界。
不得在
```
SKILL.md
```
中嵌入大型示例或输出模板。
不得添加
```
paths:
```
字段。本技能为通用工作流技能。
不得添加
```
context: fork
```
。本工作流依赖过程中的用户交互。
不得引入仅Agent可见的头部信息。
不得创建涉及超过3个文件的任务。
不得过度约束依赖——独立任务必须保持并行。
不得在狭窄的写入范围后隐藏必要的共享文件编辑。
不得让任务声称需要自身未定义的能力来实现副作用。
除非路径存在于仓库中，否则不得将外部文档、克隆内容或网络研究当作本地代码呈现。
不得使用P1-P4优先级。本技能使用P0-P3。
不得在JSON和Markdown中分别手动维护计数、层级摘要或依赖引用——需从标准计划对象派生。

When To Load References

何时加载参考资料

```
references/personality.md
```
Use at session start for role, expertise, traits, and communication style.
```
references/knowledge.md
```
Use for DAG semantics, parser assumptions, and plan-object knowledge.
```
references/output-format.md
```
Use before rendering final markdown and JSON artifacts.
```
references/examples.md
```
Use only when you need an example shape for a similar request.

```
references/personality.md
```
在会话开始时使用，用于确定角色、专业能力、特质及沟通风格。
```
references/knowledge.md
```
用于了解DAG语义、解析器假设及计划对象相关知识。
```
references/output-format.md
```
在渲染最终Markdown和JSON产物前使用。
```
references/examples.md
```
仅在需要参考类似请求的展示格式时使用。

Output Contract

输出契约

Report:

selected mode and review default
plan file paths
task count and critical path summary
major prerequisites and non-goals
any notable risks or cut-line decisions

需报告：

选定的模式和默认审核方式
计划文件路径
任务数量及关键路径摘要
主要前置条件和非目标
任何显著风险或交付边界决策