create-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create a PR

创建PR

Goal

目标

Produce a PR that’s easy to review and safe to merge:
  • small, scoped changes
  • green checks (lint/tests/build as appropriate)
  • clear description + validation steps
生成易于评审且可安全合并的PR:
  • 小型、范围明确的变更
  • 检查全部通过(根据情况完成lint/测试/构建)
  • 清晰的描述 + 验证步骤

Workflow (checklist)

工作流(检查清单)

  1. Confirm scope
    • Restate the goal and acceptance criteria.
    • Identify files likely to change; avoid unrelated cleanup.
  2. Create a branch
    • Use a descriptive name:
      fix/<topic>
      ,
      feat/<topic>
      ,
      chore/<topic>
      .
  3. Implement changes
    • Keep diffs focused; prefer small commits.
  4. Run quality gates
    • Run the repo’s standard commands (lint/tests/build).
    • If
      bun.lock
      exists, prefer
      bun lint
      /
      bun build
      .
    • If
      bun.lock
      exists but
      bun
      is not available, tell the user and ask whether to install
      bun
      or use the repo’s alternative package manager.
  5. Commit
    • Prefer Conventional Commits:
      fix: ...
      ,
      feat: ...
      ,
      chore: ...
      .
  6. Push + open PR
    • Always use GitHub CLI (
      gh
      ) for PR workflows (e.g.
      gh pr create --fill
      ).
    • If
      gh
      is not authenticated, run
      gh auth login
      (or
      gh auth status
      to check).
    • If
      gh
      is not installed or cannot be authenticated, tell the user and ask whether to install/authenticate or proceed with manual PR creation steps.
  7. Fill in PR body
    • Use
      references/pr-description-template.md
      .
  1. 确认范围
    • 重述目标和验收标准。
    • 确定可能要修改的文件,避免无关的清理操作。
  2. 创建分支
    • 使用描述性名称:
      fix/<topic>
      ,
      feat/<topic>
      ,
      chore/<topic>
  3. 实现变更
    • 保持差异内容聚焦,优先使用小型提交。
  4. 运行质量门禁
    • 运行代码仓库的标准命令(lint/测试/构建)。
    • 如果存在
      bun.lock
      ,优先使用
      bun lint
      /
      bun build
    • 如果存在
      bun.lock
      但没有可用的
      bun
      ,告知用户并询问是安装
      bun
      还是使用仓库的其他包管理器。
  5. 提交
    • 优先使用约定式提交:
      fix: ...
      ,
      feat: ...
      ,
      chore: ...
  6. 推送并打开PR
    • PR工作流始终使用GitHub CLI (
      gh
      )(例如
      gh pr create --fill
      )。
    • 如果
      gh
      未完成身份验证,运行
      gh auth login
      (或运行
      gh auth status
      检查状态)。
    • 如果
      gh
      未安装或无法完成身份验证,告知用户并询问是安装/完成身份验证,还是继续使用手动创建PR的步骤。
  7. 填写PR正文
    • 使用
      references/pr-description-template.md
      模板。

Notes

注意事项

  • Don't force-push unless you're sure it's safe for collaborators.
  • If the PR changes UX, include screenshots or a short GIF.
  • Prefer
    gh
    for create/view/checks (e.g.
    gh pr view
    ,
    gh pr checks
    ).
  • 除非你确认对协作者安全,否则不要强制推送。
  • 如果PR改动了UX,包含截图或短GIF。
  • 优先使用
    gh
    进行创建/查看/检查操作(例如
    gh pr view
    ,
    gh pr checks
    )。

Deliverable

交付内容

Provide:
  • Branch name and PR URL (or the exact steps to open it manually).
  • PR title/body (using
    references/pr-description-template.md
    ).
  • Commits included and verification commands run.
  • Screenshots/GIFs if UX changed.
提供以下内容:
  • 分支名称和PR URL(或手动打开PR的具体步骤)。
  • PR标题/正文(使用
    references/pr-description-template.md
    模板)。
  • 包含的提交记录和运行过的验证命令。
  • 如果UX有改动,提供截图/GIF。