Back to Details

implement

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese
Implement a feature by reading all prepared context, then propose to commit, push, and create a PR.
通过阅读所有准备好的上下文信息实现功能，然后提议进行提交、推送代码并创建PR。

Steps

步骤

  1. Resolve the issue — the argument can be:
    • A GitHub issue number or URL → fetch with 
      gh issue view
    • A description → search with 
      gh issue list --search "<description>"
      to find the matching issue
    • Nothing → ask the user what to implement
  2. Read all available context:
    • Specs in 
      doc/spec/
      related to the feature
    • ADRs in 
      doc/adr/
      related to the feature
    • Docs in 
      doc/
      related to the feature
    • Existing code and tests in the affected areas
  3. Implement the feature based on the gathered context:
    • Follow specs as acceptance criteria
    • Respect architectural decisions from ADRs
    • Match existing code style and patterns
  4. When implementation is complete, propose to the user:
    • Stage and commit the changes
    • Push the branch
    • Create a PR linking the issue
  5. If the user agrees:
    • Stage relevant files — prefer 
      git add <file>...
      over 
      git add -A
    • Do NOT stage files that look like secrets (
      .env
      , credentials, tokens)
    • Extract the issue number from the current branch name (e.g. 
      42-add-export
      → 
      #42
      )
    • Commit with message: 
      #<number> <imperative summary>
    • Push with 
      git push -u origin <branch>
    • Create PR with 
      gh pr create
      :
      • Title: imperative, under 70 chars
      • Body includes "Closes #<number>" to auto-link the issue
    • Show the PR URL when done
  1. 处理需求工单——参数可以是：
    • GitHub issue编号或URL → 使用
      gh issue view
      获取详情
    • 描述内容 → 使用
      gh issue list --search "<description>"
      查找匹配的工单
    • 无参数 → 询问用户需要实现什么功能
  2. 阅读所有可用的上下文信息：
    • 与该功能相关的
      doc/spec/
      目录下的规格文档
    • 与该功能相关的
      doc/adr/
      目录下的架构决策记录（ADRs）
    • 与该功能相关的
      doc/
      目录下的说明文档
    • 受影响区域的现有代码和测试用例
  3. 根据收集到的上下文实现功能：
    • 将规格文档作为验收标准
    • 遵循ADRs中的架构决策
    • 匹配现有代码的风格和模式
  4. 功能实现完成后，向用户提议：
    • 暂存并提交更改
    • 推送分支代码
    • 创建关联该工单的PR
  5. 如果用户同意：
    • 暂存相关文件——优先使用
      git add <file>...
      而非
      git add -A
    • 不要暂存看起来像敏感信息的文件（如
      .env
      、凭证、令牌）
    • 从当前分支名称中提取工单编号（例如
      42-add-export
      → 
      #42
      ）
    • 提交信息格式：
      #<number> <祈使语气的摘要>
    • 使用
      git push -u origin <branch>
      推送代码
    • 使用
      gh pr create
      创建PR：
      • 标题：祈使语气，长度不超过70个字符
      • 正文包含“Closes #<number>”以自动关联工单
    • 完成后展示PR的URL

Rules

规则

  • Always ask before committing, pushing, or creating a PR
  • Do NOT push or create a PR without explicit user approval
  • Follow commit message convention: 
    #<number> <imperative summary>
  • If there are no changes to commit, tell the user
  • 在提交、推送或创建PR前务必询问用户
  • 未经用户明确批准，不得推送代码或创建PR
  • 遵循提交信息规范：
    #<number> <祈使语气的摘要>
  • 如果没有需要提交的更改，告知用户