Back to Details

new

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

new

新建

Create or update 
tasks/todo.md
as the source of truth for what the project is and what features will be built.
创建或更新
tasks/todo.md
，作为项目定位及待开发功能的唯一可信来源。

Guardrails

约束规则

  • Do not implement code.
  • Do not write individual feature PRDs (use 
    plan
    for that).
  • Keep features "PRD-sized": one feature = one PRD. If it spans >2 subsystems, >1 UI surface + backend, or >~1 day of work, split it.
  • Prefer a stable 
    todo.md
    structure; edit in place rather than rewriting.
  • Write 
    tasks/todo.md
    so a junior dev (or another AI) can pick it up without extra context.
  • Do not use Markdown tables (use checklists + bullets).
  • Do not check feature boxes unless the PRD actually exists (typically updated by 
    plan
    ).
  • Treat memory capture as built-in: if durable decisions are made, update 
    tasks/memory.md
    in this step instead of deferring to a separate memory pass.
  • 不要编写代码。
  • 不要编写单个功能的PRD（此类操作请使用
    plan
    ）。
  • 保持功能为“PRD量级”：一个功能对应一个PRD。如果某个功能涉及超过2个子系统、1个以上UI界面+后端，或需要耗时超过1天完成，请拆分该功能。
  • 优先保持
    todo.md
    结构稳定；建议原地编辑而非重写。
  • 编写
    tasks/todo.md
    时，应确保初级开发人员（或其他AI）无需额外上下文即可接手。
  • 不要使用Markdown表格（请使用复选框+项目符号）。
  • 除非PRD已实际存在（通常由
    plan
    更新），否则不要勾选功能对应的复选框。
  • 内置记忆捕获功能：若做出了需要长期保留的决策，请在此步骤更新
    tasks/memory.md
    ，而非推迟到单独的记忆处理环节。

Workflow

工作流程

  1. Determine intent:
    • New project → initialise 
      tasks/todo.md
      .
    • Add/update features → edit the existing 
      tasks/todo.md
      .
  2. If 
    tasks/memory.md
    exists, skim relevant sections (project, key decisions, notes / gotchas) so you don't conflict with prior decisions.
  3. Ask clarifying questions only when needed (use A/B/C/D options).
  4. Update 
    tasks/todo.md
    using the template below:
    • New project: write a crisp Project section + propose an initial prioritised feature list, ordered by priority (highest first).
    • Add/update: add, merge, re-scope, and/or re-order features.
      • If adding a new 
        Type: fix
        item and the user didn't specify placement, explicitly ask if it should move up the list (priority is determined by list order).
  5. Ensure each feature has clear in-scope vs out-of-scope boundaries and dependencies (if any).
  6. Evaluate memory-worthy outcomes and update 
    tasks/memory.md
    inline when needed:
    • project definition changes
    • scope boundaries or constraints that affect future features
    • priority decisions with durable rationale
  7. Reply with updated file paths and a short change summary (what you added/changed).
  1. 确定意图：
    • 新项目 → 初始化
      tasks/todo.md
      。
    • 添加/更新功能 → 编辑现有的
      tasks/todo.md
      。
  2. 若
    tasks/memory.md
    已存在，浏览相关章节（项目、关键决策、注意事项/陷阱），避免与之前的决策冲突。
  3. 仅在必要时提出澄清问题（使用A/B/C/D选项形式）。
  4. 使用以下模板更新
    tasks/todo.md
    ：
    • 新项目：撰写简洁的项目章节 + 提出初始的优先级功能列表，按优先级从高到低排序。
    • 添加/更新：添加、合并、重新界定范围和/或重新排序功能。
      • 若添加新的
        Type: fix
        事项且用户未指定位置，请明确询问是否应提升其列表排序（优先级由列表顺序决定）。
  5. 确保每个功能都有清晰的范围内/范围外边界及依赖关系（如有）。
  6. 评估需要保留的决策结果，必要时同步更新
    tasks/memory.md
    ：
    • 项目定义变更
    • 影响未来功能的范围边界或约束条件
    • 带有长期依据的优先级决策
  7. 回复时附上更新后的文件路径及简短的变更摘要（新增/修改了内容）。

Clarifying Questions (Only If Needed)

澄清问题（仅在必要时提出）

Ask up to ~7 high-value questions. Keep them answerable via 
1A, 2C, 3B
.
Focus on ambiguity around:
  • target user + primary use case
  • the problem + desired outcome
  • constraints (platforms, timeline, integrations)
  • success metrics / how we know it worked
  • scope boundaries (what's explicitly in vs out)
  • priority order (what should be done first)
  • whether an item should be 
    Type: feat
    vs 
    fix
    vs 
    chore
    (and where it should sit in priority order)
  • dependencies between features (by ID)
最多提出约7个高价值问题。问题需支持通过
1A, 2C, 3B
形式作答。
聚焦以下模糊点：
  • 目标用户 + 主要使用场景
  • 问题 + 期望结果
  • 约束条件（平台、时间线、集成需求）
  • 成功指标 / 如何判断任务完成
  • 范围边界（明确包含/排除的内容）
  • 优先级顺序（应优先完成的事项）
  • 某事项应归类为
    Type: feat
    /
    fix
    /
    chore
    的哪一类（及其在列表中的优先级位置）
  • 功能之间的依赖关系（按ID）

Example question format

问题示例格式

text
1. What are we doing right now?
   A. Start a brand new project
   B. Add new features to an existing plan
   C. Refine/re-scope existing planned features
   D. Other: [describe]
text
1. 当前我们的任务是什么？
   A. 启动一个全新项目
   B. 为现有计划添加新功能
   C. 优化/重新界定现有计划功能的范围
   D. 其他：[描述]

tasks/todo.md
Template (Markdown)

tasks/todo.md
模板（Markdown）

If 
tasks/todo.md
does not exist, create it with this structure (fill in details; keep it concise).
markdown
undefined
若
tasks/todo.md
不存在，请使用以下结构创建（填充详细信息；保持简洁）。
markdown
undefined

TODO: <Project name>

TODO: <项目名称>

Project

项目

  • One-liner: …
  • Target users: …
  • Problem: …
  • Success metrics: …
  • Constraints (optional): …
  • Non-goals: …
  • 一句话简介：……
  • 目标用户：……
  • 解决的问题：……
  • 成功指标：……
  • 约束条件（可选）：……
  • 非目标：……

Features

功能

Checkbox meaning: unchecked = PRD not written yet; checked = PRD exists; checked + strikethrough = completed (PRD archived). Leave unchecked until a PRD exists. Feature completion is determined by PRDs being archived to 
tasks/archive/
and recorded in 
tasks/memory.md
; strikethrough here is a derived marker applied during 
commit
finalise.
复选框含义：未勾选 = PRD尚未编写；已勾选 = PRD已存在；已勾选 + 删除线 = 已完成（PRD已归档）。 在PRD存在前请勿勾选。 功能完成状态由PRD是否归档至
tasks/archive/
并记录在
tasks/memory.md
中决定；此处的删除线是在
commit
终环节自动生成的标记。

Features (priority order)

功能列表（按优先级排序）

  • Higher in the list = higher priority.
  • f-01: <feature name>
    • Type: feat | fix | chore
    • Outcome: <user-visible outcome>
    • In scope: <what ships>
    • Out of scope: <what does not ship>
    • Dependencies: <none> | f-02, f-10
  • f-02: <feature name>
    • Type: feat | fix | chore
    • Outcome: <user-visible outcome>
    • In scope: <what ships>
    • Out of scope: <what does not ship>
    • Dependencies: <none> | f-01
  • 列表位置越靠上 = 优先级越高。
  • f-01: <功能名称>
    • Type: feat | fix | chore
    • 预期结果：<用户可见的成果>
    • 范围内：<将交付的内容>
    • 范围外：<不包含的内容>
    • 依赖关系：<无> | f-02, f-10
  • f-02: <功能名称>
    • Type: feat | fix | chore
    • 预期结果：<用户可见的成果>
    • 范围内：<将交付的内容>
    • 范围外：<不包含的内容>
    • 依赖关系：<无> | f-01

Open Questions (project-wide only; per-feature questions go under each feature entry)

待解决问题（仅针对项目层面；单个功能的问题请放在对应功能条目下）

  • Q-1: …

---
  • Q-1: ……

---

Update Rules (When 
tasks/todo.md
Exists)

更新规则（当
tasks/todo.md
已存在时）

  • Preserve existing content and wording unless the user asks to change it.
  • Avoid duplicates: if a new feature overlaps an existing one, merge or propose a rename instead of adding a second item.
  • Keep IDs stable; IDs must be globally unique within 
    tasks/todo.md
    .
  • When adding a new feature, use the next ID as 
    (max existing f-##) + 1
    (never reuse old IDs).
  • If duplicate IDs already exist, resolve by renumbering the newer/less-referenced item(s) and updating any 
    Dependencies:
    references.
  • Keep the list prioritised top-to-bottom; if placement is unclear, ask where to insert (or add to the bottom).
  • If a feature depends on another feature, ensure the dependency is listed above it (or explicitly confirm the ordering).
  • Keep checkbox meaning consistent: checked means "PRD exists".
  • Ensure each feature entry includes:
    • a type (feat/fix/chore)
    • a clear user-visible outcome
    • in scope / out of scope boundaries
    • dependencies by ID (if any)
  • 保留现有内容和措辞，除非用户要求修改。
  • 避免重复：若新功能与现有功能重叠，请合并或建议重命名，而非添加重复条目。
  • 保持ID稳定；ID在
    tasks/todo.md
    中必须全局唯一。
  • 添加新功能时，使用下一个连续ID：
    (现有最大f-##编号) + 1
    （切勿复用旧ID）。
  • 若已存在重复ID，请通过重命名较新/引用较少的条目并更新所有
    Dependencies:
    中的引用解决。
  • 保持列表按优先级从上到下排序；若位置不明确，请询问插入位置（或添加至列表底部）。
  • 若某功能依赖另一功能，请确保依赖项位于其上方（或明确确认排序）。
  • 保持复选框含义一致：已勾选表示“PRD已存在”。
  • 确保每个功能条目包含：
    • 类型（feat/fix/chore）
    • 清晰的用户可见预期结果
    • 范围内/范围外边界
    • 依赖关系ID（如有）

Feature Writing Guidelines

功能编写指南

  • Prefer feature names as verb phrases (e.g., "Invite teammates", "Export CSV").
  • For fix items, name them clearly (e.g., "Fix <problem>") and set 
    Type: fix
    . Include minimal bug info:
    • Current behaviour: …
    • Expected behaviour: …
    • Repro steps (if known): …
  • For chores, keep them crisp and outcome-oriented (e.g., "Chore: remove dead code") and set 
    Type: chore
    .
  • Ensure each feature has a crisp outcome (what changes for the user).
  • Avoid implementation tasks ("refactor", "set up DB") unless they are truly user-facing requirements.
  • If a feature is too large, split by user goal or workflow step until each item could reasonably become a single PRD.
  • 优先使用动词短语作为功能名称（例如：“邀请团队成员”、“导出CSV文件”）。
  • 对于fix类型事项，名称需清晰明确（例如：“修复<问题>”）并设置
    Type: fix
    。包含必要的bug信息：
    • 当前行为：……
    • 预期行为：……
    • 复现步骤（如有）：……
  • 对于chore类型事项，保持简洁并聚焦结果（例如：“Chore: 移除无用代码”）并设置
    Type: chore
    。
  • 确保每个功能都有简洁的预期结果（用户将看到哪些变化）。
  • 避免编写实现类任务（如“重构”、“搭建数据库”），除非它们是真正面向用户的需求。
  • 若某功能过大，请按用户目标或工作流程步骤拆分，直到每个条目都能合理成为单个PRD。

Output

输出要求

  • Create or reuse 
    tasks/
    .
  • Create or update 
    tasks/todo.md
    .
  • After updating, suggest the next feature to spec with 
    plan
    (by ID/name): highest priority unchecked feature (checked = PRD exists).
  • When a PRD is created via 
    plan
    , ensure the matching feature checkbox is checked in 
    tasks/todo.md
    .
  • If you made a durable project decision (scope boundary, constraint, key choice), update 
    tasks/memory.md
    in the same run.
  • End with a short status block:
    • Files changed: list of created/updated files
    • Key decisions: any assumptions or choices made (if any)
    • Next step: recommended next skill or action
  • 创建或复用
    tasks/
    目录。
  • 创建或更新
    tasks/todo.md
    。
  • 更新完成后，建议使用
    plan
    工具对下一个功能进行规格编写（按ID/名称）：优先级最高的未勾选功能（已勾选表示PRD已存在）。
  • 当通过
    plan
    创建PRD时，请确保
    tasks/todo.md
    中对应功能的复选框被勾选。
  • 若做出了长期有效的项目决策（范围边界、约束条件、关键选择），请在同一操作中更新
    tasks/memory.md
    。
  • 结尾附上简短的状态块：
    • 已修改文件：列出创建/更新的文件
    • 关键决策：做出的任何假设或选择（如有）
    • 下一步：推荐的后续工具或操作

Quality Checklist

质量检查清单

Before finalising 
tasks/todo.md
:
  • Project section explains what the project is and who it serves.
  • Feature list is prioritised and reasonably sized (avoid 30 "must-haves").
  • Feature IDs are unique and stable (no duplicates).
  • No feature is checked unless its PRD exists.
  • Each feature has a 
    Type:
    (
    feat
    / 
    fix
    / 
    chore
    ).
  • Each feature has a user-visible outcome and explicit scope boundaries.
  • Dependencies (if any) reference valid feature IDs.
  • Duplicates/overlaps are merged or clearly distinguished.
在最终确定
tasks/todo.md
前：
  • 项目章节说明了项目定位及服务对象。
  • 功能列表已按优先级排序且规模合理（避免30个“必备项”）。
  • 功能ID唯一且稳定（无重复）。
  • 除非PRD已存在，否则功能未被勾选。
  • 每个功能都有
    Type:
    标识（
    feat
    /
    fix
    /
    chore
    ）。
  • 每个功能都有用户可见的预期结果及明确的范围边界。
  • 依赖关系（如有）引用了有效的功能ID。
  • 重复/重叠的功能已被合并或明确区分。