plan

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

plan

规划

Create a clear, implementation-ready PRD for a single feature (not code).

为单个功能(非代码)创建一份清晰、可直接用于落地的PRD。

Guardrails

约束规则

  • Do not implement the feature.
  • If the user asks to implement, propose writing a PRD first (or ask if they want to skip the PRD).
  • Prefer asking a small number of high-value questions; otherwise write a draft PRD with explicit assumptions.
  • Write the PRD so a junior dev (or another AI) can implement it without extra context (plain language, explicit edge cases, verifiable acceptance criteria).
  • Treat memory capture as built-in: if planning introduces durable decisions/constraints, update
    tasks/memory.md
    in this step.

  • 不要实现该功能。
  • 如果用户要求实现功能,建议先编写PRD(或询问用户是否要跳过PRD环节)。
  • 优先提出少量高价值问题;否则基于明确假设编写PRD草稿。
  • PRD的编写应确保初级开发人员(或其他AI)无需额外上下文即可实现功能(使用直白语言,明确边缘情况,验收标准可验证)。
  • 内置记忆捕获功能:若规划过程中产生了具有长期影响的决策/约束,需在此步骤更新
    tasks/memory.md

Workflow

工作流程

  1. Identify the feature:
    • Prefer a feature ID like
      f-01
      if available.
    • If
      tasks/todo.md
      exists, use the matching feature entry as the baseline for outcome + scope.
    • If the feature entry includes
      Type:
      , carry it into the PRD Summary so
      implement
      can branch and implement appropriately.
    • If
      Type:
      is missing, assume
      Type: feat
      .
    • If
      tasks/todo.md
      is missing or the feature is not in it yet, stop and use
      new
      to add the feature to
      tasks/todo.md
      first.
    • If
      tasks/memory.md
      exists, skim relevant key decisions / notes before finalising requirements.
  2. Check priority (if
    tasks/todo.md
    exists):
    • Priority is determined by list order (higher in the list = higher priority).
    • If there are higher-priority unchecked items above this feature, ask the user to confirm they want to proceed (vs writing a PRD for one of the higher-priority items first). Mention the higher-priority IDs/names.
    • If the user says this item is urgent, recommend switching to
      new
      to move it higher in
      tasks/todo.md
      , then return to
      plan
      .
  3. Determine the PRD file path:
    • First look for an active PRD matching the feature ID in
      tasks/
      (
      tasks/f-##-*.md
      ).
    • If one exists, use it.
    • Otherwise use
      tasks/f-##-<feature-slug>.md
      (include the feature ID in the filename).
  4. If a PRD already exists at that path, update it in place (do not create a duplicate PRD unless the user asks). Do not reset any existing checklist items inside the PRD.
  5. Ask essential clarifying questions (lettered options) only when needed.
  6. Confirm scope boundaries (in-scope vs non-goals) and success metrics.
  7. Write or update the PRD at the chosen path (create
    tasks/
    if missing):
    • Ensure implementation progress is trackable via checklist items (for example, user stories and acceptance criteria checkboxes).
    • If
      tasks/todo.md
      lists
      Dependencies:
      for this feature, include them in "Dependencies & Constraints" (dependency validation happens during
      implement
      ).
  8. If
    tasks/todo.md
    exists, update it to reflect the PRD:
    • Check the feature checkbox (
      - [ ]
      - [x]
      ).
  9. Evaluate memory-worthy outcomes and update
    tasks/memory.md
    inline when needed:
    • architecture or requirement decisions with durable impact
    • new constraints, non-goals, or rollout assumptions
    • risk decisions likely to affect later implementation/review
  10. Reply with updated file paths and a short summary + open questions.

  1. 确定功能:
    • 若有可用的功能ID(如
      f-01
      ),优先使用。
    • tasks/todo.md
      存在,以匹配的功能条目作为成果范围的基准。
    • 若功能条目包含
      Type:
      ,需将其带入PRD摘要中,以便
      implement
      环节可分支进行相应实现。
    • 若缺少
      Type:
      ,默认假设为
      Type: feat
    • tasks/todo.md
      不存在或该功能未被收录,需先使用
      new
      将功能添加至
      tasks/todo.md
      ,再继续后续操作。
    • tasks/memory.md
      存在,在最终确定需求前浏览相关的关键决策/备注。
  2. 检查优先级(若
    tasks/todo.md
    存在):
    • 优先级由列表顺序决定(列表中位置越靠上,优先级越高)。
    • 若该功能上方存在未勾选的更高优先级条目,需询问用户是否确认继续(或是先为更高优先级条目编写PRD),并提及更高优先级条目的ID/名称。
    • 若用户表示该条目紧急,建议使用
      new
      将其移至
      tasks/todo.md
      的更上方,再返回
      plan
      环节。
  3. 确定PRD文件路径:
    • 首先在
      tasks/
      目录下查找与功能ID匹配的活跃PRD(
      tasks/f-##-*.md
      )。
    • 若存在,直接使用该文件。
    • 否则使用
      tasks/f-##-<feature-slug>.md
      (文件名需包含功能ID)。
  4. 若该路径下已存在PRD,直接在原文件上更新(除非用户要求,否则不要创建重复PRD)。不要重置PRD内已有的任何复选框项。
  5. 仅在必要时提出关键澄清问题(带选项的字母标识)。
  6. 确认范围边界(范围内vs非目标)和成功指标。
  7. 在选定路径下编写或更新PRD(若
    tasks/
    目录不存在则创建):
    • 确保可通过复选框项跟踪落地进度(例如用户故事和验收标准的复选框)。
    • tasks/todo.md
      中列出了该功能的
      Dependencies:
      ,需将其纳入“依赖与约束”部分(依赖验证在
      implement
      环节进行)。
  8. tasks/todo.md
    存在,更新文件以反映PRD状态:
    • 勾选功能对应的复选框(
      - [ ]
      - [x]
      )。
  9. 评估需存入记忆的成果,必要时实时更新
    tasks/memory.md
    • 具有长期影响的架构或需求决策
    • 新的约束、非目标或上线假设
    • 可能影响后续落地/评审的风险决策
  10. 回复时需包含更新后的文件路径、简短摘要以及待解决问题。

Clarifying Questions (Only If Needed)

澄清问题(仅在必要时提出)

Ask up to ~7 questions. Use numbered questions with A/B/C/D options and an Other option so the user can reply like
1B, 2D, 3A
.
Cover only what is ambiguous:
  • which feature this PRD is for (feature ID/name)
  • user + use case
  • problem + desired outcome
  • scope boundaries (in scope vs out of scope)
  • whether this is
    Type: feat
    vs
    fix
    vs
    chore
  • feature dependencies (by feature ID)
  • conflicts with existing decisions/constraints (from
    tasks/memory.md
    )
  • platforms/surfaces
  • data + permissions
  • integrations / external dependencies
  • success metrics
  • rollout constraints / timeline
最多提出约7个问题。使用带编号的问题,并提供A/B/C/D选项以及其他选项,以便用户可以如
1B, 2D, 3A
这样回复。
仅针对模糊点提问:
  • 此PRD对应的是哪个功能(功能ID/名称)
  • 用户+使用场景
  • 问题+期望成果
  • 范围边界(范围内vs范围外)
  • 此功能属于
    Type: feat
    /
    fix
    /
    chore
    中的哪一类
  • 功能依赖项(按功能ID)
  • 与现有决策/约束的冲突(来自
    tasks/memory.md
  • 平台/界面
  • 数据+权限
  • 集成/外部依赖
  • 成功指标
  • 上线约束/时间线

Example question format

示例问题格式

text
1. What is the primary goal?
   A. Enable a new capability
   B. Improve an existing workflow
   C. Reduce cost / time / errors
   D. Other: [describe]

text
1. What is the primary goal?
   A. Enable a new capability
   B. Improve an existing workflow
   C. Reduce cost / time / errors
   D. Other: [describe]

PRD Template (Markdown)

PRD模板(Markdown)

Use
references/prd-template.md
as the default PRD template and checklist.
  • Read it before drafting a new PRD.
  • For updates to an existing PRD, edit only impacted sections and preserve existing checkbox state.
  • Keep acceptance criteria concrete and verifiable; examples are in the reference file.

默认使用
references/prd-template.md
作为PRD模板和检查清单。
  • 编写新PRD前先阅读该模板。
  • 更新现有PRD时,仅编辑受影响的部分,并保留现有复选框状态。
  • 验收标准需具体且可验证;参考文件中有示例。

Output

输出结果

  • Create or reuse
    tasks/
    .
  • Save/update the PRD at the chosen path (prefer existing active
    tasks/f-##-*.md
    ; otherwise
    tasks/f-##-<feature-slug>.md
    ).
  • If the slug or scope is ambiguous, ask the user to confirm before saving.
  • If
    tasks/todo.md
    exists, update it (check the feature only; no PRD path field).
  • If the PRD introduces durable decisions/constraints, 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/
    目录。
  • 在选定路径下保存/更新PRD(优先使用现有活跃的
    tasks/f-##-*.md
    ;否则使用
    tasks/f-##-<feature-slug>.md
    )。
  • 若功能别名(slug)或范围不明确,需先询问用户确认再保存。
  • tasks/todo.md
    存在,更新该文件(仅勾选功能复选框;无需添加PRD路径字段)。
  • 若PRD引入了具有长期影响的决策/约束,需在本次操作中同步更新
    tasks/memory.md
  • 结尾附上简短状态块:
    • 文件变更:列出创建/更新的文件
    • 关键决策:做出的任何假设或选择(若有)
    • 下一步:推荐的后续技能或操作

Todo Sync (If
tasks/todo.md
Exists)

待办事项同步(若
tasks/todo.md
存在)

  • Update
    tasks/todo.md
    in place; do not reformat the whole file.
  • Find the matching feature by ID (preferred) or by feature name.
  • Update the feature checklist item to checked (
    - [ ]
    - [x]
    ). In
    tasks/todo.md
    , checked means "PRD exists" (not "built").
  • Preserve the feature's
    Type:
    /
    Dependencies:
    lines as-is unless the user explicitly asked to change them.
  • If the feature is not present in
    tasks/todo.md
    , do not create a PRD yet—use
    new
    to add the feature first, then return to
    plan
    .

  • 直接在原文件中更新
    tasks/todo.md
    ;不要重新格式化整个文件。
  • 优先按功能ID(其次按功能名称)查找匹配的功能。
  • 将功能对应的复选框项改为已勾选(
    - [ ]
    - [x]
    )。在
    tasks/todo.md
    中,已勾选表示“PRD已存在”(而非“已开发完成”)。
  • 保留功能的
    Type:
    /
    Dependencies:
    行不变,除非用户明确要求修改。
  • 若该功能未出现在
    tasks/todo.md
    中,暂不创建PRD——先使用
    new
    添加功能,再返回
    plan
    环节。

Quality Checklist

质量检查清单

Before saving, run the "Quality Checklist" in
references/prd-template.md
. At minimum confirm:
  • existing PRDs were updated in place (no duplicates)
  • tasks/todo.md
    checkbox was synced when applicable
  • dependencies and
    Type:
    were preserved/updated correctly
保存前,执行
references/prd-template.md
中的“质量检查清单”。 至少确认以下内容:
  • 现有PRD已在原文件上更新(无重复文件)
  • 适用时已同步
    tasks/todo.md
    的复选框状态
  • 依赖项和
    Type:
    已正确保留/更新