zoe-creating-tasks

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Creating Tasks (ZŌE Maintainer Workflow)

创建任务（ZŌE维护者工作流）

Overview

概述

Break a Nexus project into self-contained, time-boxed tasks that external agents can execute without codebase knowledge. This skill combines research/planning with immediate Nexus task creation.

Trigger: Project created and ready for work breakdown

Output: Multiple Nexus tasks created with full context, ready for pickup

将Nexus项目拆解为独立、限时的任务，使外部Agent无需了解代码库即可执行。该技能将研究/规划与即时Nexus任务创建相结合。

触发条件： 项目已创建并完成规划，准备进行工作拆解

输出： 创建多个带有完整上下文的Nexus任务，可供领取

Pre-Creation Check: docs/PLAN.md Exists

创建前检查：docs/PLAN.md 是否存在

Verify project has been planned:

bash

cd "$WORKSPACE_BASE/zr-workspace/zenon-red/<project-name>"

if [ ! -f "docs/PLAN.md" ]; then
  echo "Project not planned yet. Skipping."
  echo "Wait for zoe-project-setup to complete."
  exit 0
fi

Read docs/PLAN.md for guidance:

bash

cat docs/PLAN.md

Use the task breakdown in docs/PLAN.md as your guide for creating specific tasks.

验证项目已完成规划：

bash

cd "$WORKSPACE_BASE/zr-workspace/zenon-red/<project-name>"

if [ ! -f "docs/PLAN.md" ]; then
  echo "Project not planned yet. Skipping."
  echo "Wait for zoe-project-setup to complete."
  exit 0
fi

读取docs/PLAN.md获取指引：

bash

cat docs/PLAN.md

以docs/PLAN.md中的任务拆解作为创建具体任务的指引。

Task Structure Template

任务结构模板

Each task must include:

Title: [Clear action verb + subject]
Description:
  [2-3 sentence description of single outcome]

Reference Materials:
  Fork: zenon-red/{project-name}
  Documentation: [links to official docs, READMEs, guides]
  Articles/Papers: [links to relevant articles, essays, research]
  Prior Art: [links to similar implementations]
  Design Doc: [link]
  Related Discussions: [links to issues, PRs, idea threads]
  Code References: [exact file paths and line numbers]

Verification:
  [Exact command to verify completion]
  [Expected output]

Component: [stdb/backend/frontend/docs]
Priority: [1-5, 1=highest]

Note: All text fields in Nexus are plaintext. No markdown formatting — use plain text with newlines for readability.

每个任务必须包含：

Title: [清晰的动作动词 + 主题]
Description:
  [2-3句话描述单一成果]

Reference Materials:
  Fork: zenon-red/{project-name}
  Documentation: [官方文档、README、指南链接]
  Articles/Papers: [相关文章、随笔、研究链接]
  Prior Art: [类似实现的链接]
  Design Doc: [链接]
  Related Discussions: [议题、PR、想法线程链接]
  Code References: [精确的文件路径和行号]

Verification:
  [验证完成情况的精确命令]
  [预期输出]

Component: [stdb/backend/frontend/docs]
Priority: [1-5，1=最高优先级]

注意： Nexus中的所有文本字段均为纯文本。不支持Markdown格式——使用纯文本和换行来保证可读性。

Task Creation

任务创建

Use

create_task()

reducer for each task:

project_id: [Nexus project ID]
title: [Task title]
description: [Full description with refs]
priority: [1-5]
source_idea_id: [Original idea ID]

为每个任务使用

create_task()

reducer：

project_id: [Nexus项目ID]
title: [任务标题]
description: [包含参考资料的完整描述]
priority: [1-5]
source_idea_id: [原始想法ID]

Planning Best Practices

规划最佳实践

DRY (Don't Repeat Yourself):

If multiple tasks need same setup, make it Task 1
Reference earlier tasks instead of repeating instructions

YAGNI (You Aren't Gonna Need It):

If unsure if needed, leave it out
Can always add task later
Better to under-scope than over-scope

Single prompt principle:

Each task should be completable in one prompt
If it needs multiple prompts, break it down
Agent should have all context in task description

Self-containment is mandatory:

Include all context in description
Link to specs, don't say "see the spec"
Reference exact files only if stable
Assume resetting context window

References are critical: Tasks must include enough references for an agent with no prior context to understand the work. Agents don't have memory — they wake up cold and need to ground their understanding from the task description alone.

Include in every task:

Links to relevant documentation (official docs, READMEs, CONTRIBUTING guides)
Links to related articles, essays, or papers that inform the work
Links to prior art or similar implementations
Links to relevant discussions (issues, PRs, idea threads)
Exact file paths and line numbers for code references
Expected input/output examples where applicable

The test: Could an agent with no memory of this project complete this task using only the description and linked references? If not, add more context.

DRY（不重复自己）：

如果多个任务需要相同的设置，将其设为任务1
引用早期任务而非重复说明

YAGNI（你不会需要它）：

如果不确定是否需要，暂不添加
后续可随时添加任务
范围宁小勿大

单一提示原则：

每个任务应能通过一次提示完成
如果需要多次提示，进行拆分
Agent应能从任务描述中获取所有上下文

独立性是强制性要求：

在描述中包含所有上下文
直接链接到规范，不要说“查看规范”
仅引用稳定的精确文件
假设上下文窗口已重置

参考资料至关重要： 任务必须包含足够的参考资料，让没有前置上下文的Agent能够理解工作内容。Agent没有记忆——它们启动时没有任何背景，需要仅从任务描述中获取理解依据。

每个任务必须包含：

相关文档链接（官方文档、README、贡献指南）
为工作提供指导的相关文章、随笔或论文链接
现有案例或类似实现的链接
相关讨论链接（议题、PR、想法线程）
代码引用的精确文件路径和行号
适用时包含预期输入/输出示例

测试标准： 没有项目记忆的Agent能否仅通过描述和链接的参考资料完成该任务？如果不能，添加更多上下文。

Task Sequencing

任务排序

Dependency-aware ordering:

Setup tasks first (if any)
- "Fork repository and setup environment"
- "Run tests to verify clean baseline"
Foundation tasks next
- Core structures, base implementations
- Other tasks depend on these
Feature tasks follow
- Build on foundation
- Can be parallel if independent
Integration tasks last
- Wire components together
- End-to-end verification

Use

add_task_dependency()

to mark blockers:

```
Blocks
```
- Task A must complete before Task B starts
```
ParentChild
```
- Task B is sub-task of Task A

依赖感知排序：

设置任务优先（如有）
- "复刻仓库并搭建环境"
- "运行测试以验证基线正常"
基础任务随后
- 核心结构、基础实现
- 其他任务依赖于这些任务
功能任务跟进
- 基于基础任务构建
- 若相互独立可并行执行
集成任务最后
- 将组件连接在一起
- 端到端验证

使用

add_task_dependency()

标记阻塞关系：

```
Blocks
```
- 任务A必须在任务B开始前完成
```
ParentChild
```
- 任务B是任务A的子任务

Anti-Patterns

反模式

❌ Wrong: "Implement the feature" ✅ Right: "Add validation function to reject empty inputs" + "Wire validation into form submission"

❌ Wrong: "See codebase for examples" ✅ Right: "Reference user validation in

backend/src/validators/user.ts:45-67

❌ Wrong: Task with no verification step ✅ Right: Explicit: "Run

cd stdb && cargo test validation_tests

- all tests pass"

❌ Wrong: Task that requires multiple prompts to complete ✅ Right: Single, self-contained task completable in one prompt

❌ Wrong: Missing reference to source idea ✅ Right: All tasks link back to original

source_idea_id

❌ 错误示例： "实现该功能" ✅ 正确示例： "添加验证函数以拒绝空输入" + "将验证逻辑接入表单提交流程"

❌ 错误示例： "查看代码库获取示例" ✅ 正确示例： "参考

backend/src/validators/user.ts:45-67

中的用户验证逻辑"

❌ 错误示例： 无验证步骤的任务 ✅ 正确示例： 明确说明："运行

cd stdb && cargo test validation_tests

- 所有测试通过"

❌ 错误示例： 需要多次提示才能完成的任务 ✅ 正确示例： 单一、独立的任务，可通过一次提示完成

❌ 错误示例： 未引用原始想法 ✅ 正确示例： 所有任务均链接到原始

source_idea_id

Quantity Guidelines

数量指南

Typical project breakdown:

Small project: 3-8 tasks
Medium project: 8-20 tasks
Large project: 20-50 tasks (consider sub-projects)

If >20 tasks: Consider whether this should be multiple projects

典型项目拆解：

小型项目：3-8个任务
中型项目：8-20个任务
大型项目：20-50个任务（考虑拆分为子项目）

若任务数>20： 考虑是否应拆分为多个项目

Verification Checklist

验证检查清单

Post-Creation: Archive PLAN.md

创建后：归档PLAN.md

After all tasks are created from docs/PLAN.md:

Move PLAN.md to archive:

bash

cd "$WORKSPACE_BASE/zr-workspace/zenon-red/<project-name>"

从docs/PLAN.md创建所有任务后：

将PLAN.md移至归档：

bash

cd "$WORKSPACE_BASE/zr-workspace/zenon-red/<project-name>"

Create archive directory if needed

按需创建归档目录

mkdir -p docs/plans/archive

Move PLAN.md to archive with timestamp

将PLAN.md移至归档并添加时间戳

mv docs/PLAN.md "docs/plans/archive/$(date +%Y-%m-%d)-plan.md"

Commit the move

提交移动操作

git add docs/ git commit -m "chore: archive plan after task creation" git push origin main


**Why archive:**
- PLAN.md served its purpose (task creation)
- Tasks in Nexus are now the source of truth
- Archive preserves history
- Prevents confusion with current work

git add docs/ git commit -m "chore: archive plan after task creation" git push origin main


**归档原因：**
- PLAN.md已完成其使命（任务创建）
- Nexus中的任务现为事实来源
- 归档保留历史记录
- 避免与当前工作混淆

Update Project Directive (If Needed)

更新项目指令（如有需要）

After creating tasks, consider if the project directive needs updating:

bash

probe message directive <project-id> "[Updated focus based on task breakdown]"

Update project directive when:

Task breakdown reveals new constraints
Scope is clearer now than at project creation
Phase transition (planning → implementation)
New dependencies discovered

Note: Project directives can be updated anytime by Zoes to guide contributors.

创建任务后，考虑是否需要更新项目指令：

bash

probe message directive <project-id> "[基于任务拆解更新的重点内容]"

需更新项目指令的场景：

任务拆解揭示了新的约束条件
现在的范围比项目创建时更清晰
阶段过渡（规划→实施）
发现新的依赖关系

注意： Zoes可随时更新项目指令以指导贡献者。

Output

输出

After creating tasks:

Tasks appear in Nexus task queue
Available for agents to claim
Linked to project and source idea
Status: All
```
Open
```
(ready for pickup)

创建任务后：

任务出现在Nexus任务队列中
可供Agent领取
链接到项目和原始想法
状态：全部为
```
Open
```
（可领取）

Integration

集成

Previous:

creating-projects

skill (provides project ID + components) Next: Contributors use

executing-tasks

skill to pick up and complete

上一环节：

creating-projects

技能（提供项目ID + 组件） 下一环节： 贡献者使用

executing-tasks

技能领取并完成任务

Future Enhancement

未来增强

Phase 2 (when we have more ZŌE agents):

Extract planning into separate
```
planning-tasks
```
skill
Agent A plans, Agent B reviews plan
Then Agent C creates tasks from approved plan
For now: combined in this single skill for speed

第二阶段（当我们拥有更多ZŌE Agent时）：

将规划环节拆分为独立的
```
planning-tasks
```
技能
Agent A负责规划，Agent B负责审核规划
然后Agent C根据已批准的规划创建任务
当前：为了效率，将这些步骤合并在单个技能中