task-think

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Task Pipeline

任务流水线

Run a full implementation workflow with repository artifacts and clear phase boundaries.

运行包含仓库产物与清晰阶段边界的完整实现工作流。

Inputs

输入参数

Collect:

task description
optional project name (if missing, derive a short kebab-case name)
optional constraints (files, architecture, risk tolerance)
optional screenshot paths

If screenshots are attached in UI but not present as files, write a brief textual summary in

.ai/<project-name>/about.md

so child runs can consume the requirements.

收集以下信息：

任务描述
可选项目名称（若未提供，自动生成简短的kebab-case格式名称）
可选约束条件（文件范围、架构要求、风险容忍度）
可选截图路径

如果UI中已附加截图但未对应到实际文件，请在

.ai/<project-name>/about.md

中编写简短的文字摘要，以便子进程可以获取需求信息。

Overview

概述

The workflow is organized around projects. Each project lives in

.ai/<project-name>/

and can contain multiple sequential tasks (labeled

, ...

Project structure:

.ai/<project-name>/
  about.md              # Single source of truth for the entire project
  a/                    # First task
    context.md          # Gathered codebase context for this task
    plan.md             # Implementation plan
    review1.md          # Code review documents (up to 3 iterations)
    review2.md
    review3.md
  b/                    # Follow-up task
    context.md
    plan.md
    review1.md
  c/                    # Another follow-up task
    ...

```
about.md
```
is the project-level blueprint — a single comprehensive document describing what this project does and how it works, written as if everything is already fully implemented. It contains no temporal state ("current state", "pending changes", "not yet implemented"). It is rewritten (not appended to) each time a new task starts, incorporating the new task's changes as if they were always part of the design.
Each task folder (
```
a/
```
,
```
b/
```
, ...) contains self-contained files for that task. The task's
```
context.md
```
carries all task-specific information: what specifically needs to change, the delta from the current codebase, gathered file references and code patterns. Planning, implementation, and review agents only read the current task's folder.

本工作流以项目为核心组织。每个项目存储在

.ai/<project-name>/

目录下，可包含多个按顺序执行的任务（标记为

、

……

）。

项目结构：

.ai/<project-name>/
  about.md              # 整个项目的唯一事实来源
  a/                    # 第一个任务
    context.md          # 该任务收集到的代码库上下文
    plan.md             # 实现方案
    review1.md          # 代码评审文档（最多3次迭代）
    review2.md
    review3.md
  b/                    # 后续任务
    context.md
    plan.md
    review1.md
  c/                    # 其他后续任务
    ...

```
about.md
```
是项目级别的蓝图文档——一份全面描述项目功能与工作原理的文档，撰写时假设所有功能已完全实现。文档中不包含时态状态描述（如“当前状态”“待修改”“尚未实现”）。每次启动新任务时，该文档会被重写（而非追加内容），并将新任务的修改内容整合进去，仿佛这些修改原本就是设计的一部分。
每个任务文件夹（
```
a/
```
、
```
b/
```
……）包含该任务的独立文件。任务的
```
context.md
```
文件承载所有任务特定信息：具体需要修改的内容、与当前代码库的差异、收集到的文件引用和代码模式。规划、实现和评审Agent仅读取当前任务的文件夹内容。

Artifacts

产物文件

Create and maintain:

```
.ai/<project-name>/about.md
```
```
.ai/<project-name>/<letter>/context.md
```
```
.ai/<project-name>/<letter>/plan.md
```

.ai/<project-name>/<letter>/review<R>.md

(up to 3 review iterations)

.ai/<project-name>/<letter>/logs/phase-*.jsonl

(when running child

codex exec

)

创建并维护以下文件：

```
.ai/<project-name>/about.md
```
```
.ai/<project-name>/<letter>/context.md
```
```
.ai/<project-name>/<letter>/plan.md
```

.ai/<project-name>/<letter>/review<R>.md

（最多3次评审迭代）

.ai/<project-name>/<letter>/logs/phase-*.jsonl

（运行子进程

codex exec

时生成）

Phases

阶段说明

The workflow runs these phases sequentially via

codex exec --json

child sessions:

Phase 0: Setup — Record start time, detect follow-up vs new project, create directories.
Phase 1: Context Gathering — Read codebase, write
```
about.md
```
and
```
context.md
```
. (Phase 1F for follow-ups.)
Phase 2: Planning — Read context, write detailed
```
plan.md
```
with numbered steps grouped into phases.
Phase 3: Plan Assessment — Review and refine the plan for correctness, completeness, code quality, and phase sizing.
Phase 4: Implementation — One child session per plan phase. Each implements only its assigned phase and updates
```
plan.md
```
status.
Phase 5: Build Verification — Build the project, fix any build errors. Skip if no source code was modified.
Phase 6: Code Review Loop — Up to 3 review-fix iterations:
- 6a: Review agent writes
```
review<R>.md
```
  with verdict (APPROVED or NEEDS_CHANGES).
- 6b: Fix agent implements review changes and rebuilds.
- Loop until APPROVED or R > 3.

Use the phase prompt templates in

PROMPTS.md

工作流通过

codex exec --json

子会话按顺序执行以下阶段：

阶段0：初始化 — 记录启动时间，判断是后续任务还是新项目，创建对应目录。
阶段1：上下文收集 — 读取代码库内容，编写
```
about.md
```
和
```
context.md
```
。（若是后续任务则执行阶段1F。）
阶段2：方案规划 — 读取上下文信息，编写包含分阶段编号步骤的详细
```
plan.md
```
。
阶段3：方案评估 — 评审并优化方案，确保其正确性、完整性、代码质量与阶段划分合理性。
阶段4：代码实现 — 每个方案阶段对应一个子会话。每个子会话仅实现其分配的阶段，并更新
```
plan.md
```
中的状态。
阶段5：构建验证 — 构建项目，修复任何构建错误。若未修改源代码则跳过此阶段。
阶段6：代码评审循环 — 最多3次评审-修复迭代：
- 6a：评审Agent编写
```
review<R>.md
```
  ，给出评审结论（APPROVED 或 NEEDS_CHANGES）。
- 6b：修复Agent实现评审要求的修改并重新构建。
- 循环直到结论为APPROVED或迭代次数R > 3。

使用

PROMPTS.md

中的阶段提示词模板。

Execution Mode

执行模式

Run

codex exec --json

child sessions for each phase. Wait for each to finish before starting the next. After each phase, validate that the expected artifact file exists and has substantive content.

Phases that require elevated reasoning (Planning, Plan Assessment, Code Review) must use

-c model_reasoning_effort="xhigh"

. See example commands in

PROMPTS.md

为每个阶段启动

codex exec --json

子会话。等待前一个阶段完成后再启动下一个阶段。每个阶段完成后，验证预期的产物文件是否存在且包含有效内容。

需要高级推理的阶段（方案规划、方案评估、代码评审）必须使用参数

-c model_reasoning_effort="xhigh"

。具体示例命令请参考

PROMPTS.md

。

Verification Rules

验证规则

If build or test commands fail due to file locks or access-denied outputs (C1041, LNK1104), stop and ask the user to close locking processes before retrying.
Never claim completion without:
- implemented code changes present
- build attempt results recorded
- review pass documented with any follow-up fixes

如果构建或测试命令因文件锁定或权限拒绝（错误码C1041、LNK1104等）失败，请停止执行并告知用户关闭占用文件的进程后再重试。
在满足以下条件前，不得宣称任务完成：
- 存在已实现的代码修改
- 已记录构建尝试结果
- 已记录评审通过情况及后续修复内容

Completion Criteria

完成标准

Mark complete only when:

All plan phases are done
Build verification is recorded
Review issues are addressed or explicitly deferred with rationale
Display total elapsed time since start (format:
```
Xh Ym Zs
```
, omitting zero components)
Remind the user of the project name so they can request follow-up tasks within the same project

仅在满足以下所有条件时标记任务完成：

所有方案阶段均已完成
已记录构建验证结果
评审问题已解决或已明确给出延迟处理的理由
显示从启动到完成的总耗时（格式：
```
Xh Ym Zs
```
，省略为0的部分）
提醒用户项目名称，以便用户在同一项目中发起后续任务

Error Handling

错误处理

If any phase fails or gets stuck, report the issue to the user and ask how to proceed.
If context.md or plan.md is not written properly by a phase, re-run that phase with more specific instructions.
If build errors persist after the build phase's attempts, report the remaining errors to the user.
If a review fix phase introduces new build errors that it cannot resolve, report to the user.

如果任何阶段失败或停滞，向用户报告问题并询问后续处理方式。
如果某个阶段未正确生成
```
context.md
```
或
```
plan.md
```
，使用更明确的指令重新运行该阶段。
如果构建阶段尝试修复后仍存在构建错误，向用户报告剩余错误。
如果评审修复阶段引入了新的构建错误且无法自行解决，向用户报告该问题。

User Invocation

用户调用方式

Use plain language with the skill name in the request, for example:

Use local task-think skill: make sure FileLoadTask::process does not create or read QPixmap on background threads; use QImage with ARGB32_Premultiplied instead.

For follow-up tasks on an existing project:

Use local task-think skill: my-project also handle the case where the file is already cached

If screenshots are relevant, include file paths in the same prompt.

使用自然语言并在请求中包含技能名称，例如：

Use local task-think skill: make sure FileLoadTask::process does not create or read QPixmap on background threads; use QImage with ARGB32_Premultiplied instead.

针对现有项目的后续任务：

Use local task-think skill: my-project also handle the case where the file is already cached

如果截图相关，请在同一提示词中包含文件路径。