implement

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

implement

功能实现

Implement a feature from a PRD.

根据PRD实现功能。

Guardrails

约束规则

Follow the repo's
```
AGENTS.md
```
instructions (if present) for any files you touch.
Keep changes simple and handoff-friendly: assume a junior dev (or another AI) will maintain this later.
Do not change product scope while executing:
- If the PRD is missing details or ambiguous, stop and use
```
plan
```
  to refine the PRD first.
- If implementation reveals the PRD is incorrect, pause and propose PRD edits via
```
plan
```
  before continuing; do not silently deviate.
- If the feature is missing from
```
tasks/todo.md
```
  , stop and use
```
new
```
  first.
- If you discover out-of-scope requirements or bugs during execution, do not expand scope—create a new backlog item via
```
new
```
  instead.
Do not edit
```
tasks/todo.md
```
in this skill.
Do not reset any existing PRD checklist items when updating an existing PRD.
Treat memory capture as built-in: when implementation yields durable decisions/gotchas, update
```
tasks/memory.md
```
in this step.
Do not claim tests passed or checks succeeded without actually running them; if you didn't run it, say so.

对于你修改的所有文件，请遵循仓库中
```
AGENTS.md
```
的说明（如果存在）。
保持修改简洁且便于交接：假设后续将由初级开发人员（或其他AI）维护代码。
执行过程中不得变更产品范围：
- 如果PRD缺少细节或表述模糊，请停止当前操作，先使用
```
plan
```
  功能完善PRD。
- 如果在实现过程中发现PRD存在错误，请暂停操作，先通过
```
plan
```
  功能提议修改PRD，再继续执行；不得擅自偏离PRD要求。
- 如果
```
tasks/todo.md
```
  中未记录该功能，请停止当前操作，先使用
```
new
```
  功能添加。
- 如果在执行过程中发现超出范围的需求或Bug，请勿扩大范围，而是通过
```
new
```
  功能创建新的待办事项。
本功能中不得编辑
```
tasks/todo.md
```
文件。
更新现有PRD时，不得重置任何已存在的PRD检查清单条目。
自动记录关键信息：如果在实现过程中做出了需要长期保留的决策或遇到了需要注意的问题，请在此步骤中更新
```
tasks/memory.md
```
文件。
未实际运行测试或检查项时，不得声称测试通过或检查合格；如果未运行，请如实说明。

Workflow

工作流程

Identify the PRD
- Ask for the PRD path if not provided (usually
```
tasks/f-##-<slug>.md
```
  ).
- Confirm which feature ID/name this PRD corresponds to.
Preflight
- Read
```
AGENTS.md
```
  (if present) and follow it.
- Check priority (if
```
tasks/todo.md
```
  exists):
  - Priority is determined by list order.
  - If there are higher-priority items above this feature, ask the user to confirm they want to work on it now (vs a higher-priority item).
    - If the higher-priority item is unchecked (no PRD yet), recommend writing its PRD via
      plan
      first.
- Create a new feature branch before making changes (unless you are already on an appropriate feature branch):
  - Base it off the repository default branch (resolve via
```
origin/HEAD
```
    or repo policy); if unclear, ask the user before branching.
  - Name it based on the PRD Summary
```
Type
```
    (or match repo conventions):
    - Type: fix
      →
      fix/f-##-<short-slug>
    - Type: chore
      →
      chore/f-##-<short-slug>
    - default (
      Type: feat
      ) →
      feat/f-##-<short-slug>
- If
```
tasks/memory.md
```
  exists, skim key decisions / notes / gotchas relevant to this area before coding.
- Parse the PRD into an execution plan: user stories, functional requirements, non-goals, risks, rollout, and testing notes.
- Verify dependencies:
  - Read this PRD's "Dependencies & Constraints" section for feature dependency IDs.
  - For each dependency ID, locate PRD files by feature ID in
```
tasks/
```
    and
```
tasks/archive/
```
    .
  - Treat dependencies as complete only when the dependency PRD is archived in
```
tasks/archive/
```
    .
  - If any dependency is still in
```
tasks/
```
    , recommend finalising that dependency first.
  - If a dependency has no PRD yet, stop and use
```
plan
```
    to create that dependency PRD first.
  - Override: if the user confirms dependencies are satisfied (e.g., dependency PR merged but not yet archived), proceed and record the override in
```
tasks/memory.md
```
    .
Execute
- Implement the feature as specified.
- Implement in small checkpoints aligned to PRD user stories to enable atomic commits.
- Add/update tests as appropriate.
- Run the project's normal checks (typecheck/lint/tests/build) per
```
AGENTS.md
```
  or project conventions.
Verify
- Verify acceptance criteria and edge cases from the PRD.
- Perform any manual QA steps listed in the PRD.
Update checklist progress (in-place)
- Check off completed user stories/tasks and acceptance criteria in the PRD as implementation progresses.
- If the PRD lacks checklist items for implementation progress, add a small checklist section and use it.
- Do not reset existing checked items.
Update memory inline when needed
- Update
```
tasks/memory.md
```
  when implementation produces durable information:
  - important gotchas or constraints
  - architectural/technical decisions with trade-offs
  - milestone-level completion notes worth preserving
Close out
- Summarise what was changed and what remains.
- Next steps:
  - PR flow: run
```
review
```
    (local) when needed, then
```
commit
```
    , then
```
open-pr
```
    , then run
```
review
```
    (PR mode) when needed, then
```
commit
```
    (finalise mode).
  - Local flow: run
```
review
```
    (local) when needed, then
```
commit
```
    .

确定目标PRD
- 如果未提供PRD路径，请向用户询问（通常路径为
```
tasks/f-##-<slug>.md
```
  ）。
- 确认该PRD对应的功能ID/名称。
前置检查
- 阅读
```
AGENTS.md
```
  文件（如果存在）并遵循其中的说明。
- 检查优先级（如果
```
tasks/todo.md
```
  存在）：
  - 优先级由列表顺序决定。
  - 如果存在优先级高于当前功能的待办项，请询问用户是否确定要先处理当前功能（而非高优先级项）。
    - 如果高优先级项未勾选（尚未创建PRD），建议先通过
      plan
      功能编写其PRD。
- 在修改代码前创建新的功能分支（除非你已处于合适的功能分支）：
  - 基于仓库默认分支创建（可通过
```
origin/HEAD
```
    或仓库规则确定）；如果不确定，在分支前询问用户。
  - 根据PRD摘要中的
```
Type
```
    命名（或遵循仓库命名规范）：
    - Type: fix
      →
      fix/f-##-<short-slug>
    - Type: chore
      →
      chore/f-##-<short-slug>
    - 默认（
      Type: feat
      ）→
      feat/f-##-<short-slug>
- 如果
```
tasks/memory.md
```
  存在，在编码前浏览与当前功能相关的关键决策、备注和注意事项。
- 将PRD拆解为执行计划：用户故事、功能需求、非目标、风险、上线计划和测试说明。
- 验证依赖关系：
  - 阅读当前PRD的“Dependencies & Constraints”部分，获取依赖的功能ID。
  - 针对每个依赖ID，在
```
tasks/
```
    和
```
tasks/archive/
```
    目录中通过功能ID查找对应的PRD文件。
  - 只有当依赖的PRD已归档到
```
tasks/archive/
```
    中时，才视为依赖已完成。
  - 如果任何依赖项仍在
```
tasks/
```
    目录中，建议先完成该依赖项。
  - 如果某个依赖项尚未创建PRD，请停止当前操作，先通过
```
plan
```
    功能创建该依赖的PRD。
  - 例外情况：如果用户确认依赖已满足（例如，依赖的PR已合并但尚未归档），则可以继续执行，并将该例外情况记录到
```
tasks/memory.md
```
    中。
执行实现
- 按照PRD的要求实现功能。
- 按照PRD中的用户故事拆分为多个小的检查点进行实现，以支持原子提交。
- 按需添加/更新测试。
- 根据
```
AGENTS.md
```
  或项目规范运行常规检查（类型检查、代码 lint、测试、构建）。
验证功能
- 验证PRD中的验收标准和边缘场景。
- 执行PRD中列出的所有手动QA步骤。
更新检查清单进度（原地更新）
- 随着实现推进，在PRD中勾选已完成的用户故事/任务和验收标准。
- 如果PRD中没有用于跟踪实现进度的检查清单条目，请添加一个小型检查清单部分并使用它。
- 不得重置已勾选的条目。
按需实时更新记忆文件
- 当实现过程中产生需要长期保留的信息时，更新
```
tasks/memory.md
```
  ：
  - 重要的注意事项或约束条件
  - 涉及权衡的架构/技术决策
  - 值得保留的里程碑级完成记录
收尾工作
- 总结已完成的修改和剩余未完成的工作。
- 后续步骤：
  - PR流程：按需运行
```
review
```
    （本地模式），然后执行
```
commit
```
    ，接着
```
open-pr
```
    ，再按需运行
```
review
```
    （PR模式），最后执行
```
commit
```
    （最终模式）。
  - 本地流程：按需运行
```
review
```
    （本地模式），然后执行
```
commit
```
    。

Output

输出内容

Update code and tests as needed.
Update PRD story/task checklist progress in the PRD file.
If you discover a durable decision/gotcha or complete a significant milestone, update
```
tasks/memory.md
```
in the same run.
Reply with:
- PRD path
- Which checklist items were completed
- Any follow-ups or open issues
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

按需更新代码和测试。
在PRD文件中更新用户故事/任务检查清单的进度。
如果发现需要长期保留的决策/注意事项，或完成了重要里程碑，请在本次操作中更新
```
tasks/memory.md
```
。
回复内容应包含：
- PRD路径
- 已完成的检查清单条目
- 后续跟进事项或未解决问题
结尾添加简短状态块：
- 修改的文件：已创建/更新的文件列表
- 关键决策：所做的假设或选择（如有）
- 下一步：推荐的后续功能或操作