Back to Details

nemoclaw-contributor-create-pr

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Create GitHub Pull Request

创建GitHub拉取请求（PR）

Create pull requests on the NemoClaw GitHub repository using the 
gh
CLI. This skill ensures every PR follows the project's PR template exactly.
使用
gh
CLI在NemoClaw GitHub仓库创建拉取请求。此技能确保每个PR严格遵循项目的PR模板。

Prerequisites

前置条件

  • The 
    gh
    CLI must be authenticated (
    gh auth status
    ).
  • You must be in the NemoClaw git repository.
  • You must have commits on a branch that is pushed to the remote.
  • 必须已完成
    gh
    CLI的身份验证（执行
    gh auth status
    验证）。
  • 你必须处于NemoClaw git仓库目录中。
  • 你所在的分支必须有已推送到远程仓库的提交记录。

Step 1: Verify Branch State

步骤1：验证分支状态

Before creating a PR, verify the branch.
  1. Not on main. Never create PRs from main.
    bash
    git branch --show-current
  2. Branch has commits ahead of main.
    bash
    git log main..HEAD --oneline
  3. Working tree is clean. Stage or stash any uncommitted changes first.
    bash
    git status
创建PR前，请验证分支状态。
  1. 不在main分支。切勿从main分支创建PR。
    bash
    git branch --show-current
  2. 分支存在超前于main的提交。
    bash
    git log main..HEAD --oneline
  3. 工作区干净。请先暂存或储藏所有未提交的变更。
    bash
    git status

Step 2: Run Pre-PR Checks

步骤2：运行PR前置检查

Choose checks based on the files changed.
For code changes, run both checks and confirm they pass before proceeding:
bash
npx prek run --all-files
npm test
For doc-only changes, do not run the full test suite unless the docs change requires it. Run the docs and hook checks instead:
bash
npx prek run --all-files
make docs
If a required check fails, fix the issue before creating the PR. When preparing the PR body for a doc-only change, leave the 
npm test
verification box unchecked unless you actually ran it.
根据变更的文件选择对应的检查项。
对于代码变更，需运行以下两项检查并确认通过后再继续：
bash
npx prek run --all-files
npm test
对于仅文档变更，除非文档变更有特殊要求，否则无需运行完整测试套件。只需运行文档和钩子检查：
bash
npx prek run --all-files
make docs
如果某项必填检查未通过，请先修复问题再创建PR。当为仅文档变更准备PR正文时，若未实际运行
npm test
，请保留该项验证框为未勾选状态。

Step 3: Push the Branch

步骤3：推送分支

Ensure the branch is pushed to the remote.
bash
git push -u origin HEAD
确保分支已推送到远程仓库。
bash
git push -u origin HEAD

Step 4: Determine PR Metadata

步骤4：确定PR元数据

Title

标题

PR titles must follow Conventional Commits format:
text
<type>(<scope>): <description>
Types: 
feat
, 
fix
, 
docs
, 
chore
, 
refactor
, 
test
, 
ci
, 
perf
Scope is typically the component name (e.g., 
cli
, 
blueprint
, 
plugin
, 
policy
, 
docs
).
Examples:
  • feat(cli): add offline mode for onboarding
  • fix(blueprint): prevent SSRF bypass via redirect
  • docs: update quickstart for Windows prerequisites
PR标题必须遵循Conventional Commits格式：
text
<type>(<scope>): <description>
类型包括：
feat
、
fix
、
docs
、
chore
、
refactor
、
test
、
ci
、
perf
范围通常为组件名称（例如：
cli
、
blueprint
、
plugin
、
policy
、
docs
）。
示例：
  • feat(cli): add offline mode for onboarding
  • fix(blueprint): prevent SSRF bypass via redirect
  • docs: update quickstart for Windows prerequisites

Type of Change

变更类型

Determine which type applies based on the diff:
  • Code change for a new feature, bug fix, or refactor — most PRs.
  • Code change with doc updates — code plus changes under 
    docs/
    .
  • Doc only, prose changes without code sample modifications — only Markdown prose.
  • Doc only, includes code sample changes — doc changes that modify fenced code blocks.
根据代码差异确定适用的变更类型：
  • 代码变更（新功能、Bug修复或重构） —— 大多数PR属于此类。
  • 代码变更并包含文档更新 —— 代码变更加上
    docs/
    目录下的修改。
  • 仅文档变更，仅修改 prose 内容未改动代码示例 —— 仅修改Markdown文本内容。
  • 仅文档变更，包含代码示例修改 —— 文档变更涉及修改 fenced code blocks（代码块）。

Related Issue

关联Issue

Check the branch name and commit messages for issue references. If an issue exists, use 
Fixes #NNN
or 
Closes #NNN
.
查看分支名称和提交信息中的Issue引用。若存在关联Issue，请使用
Fixes #NNN
或
Closes #NNN
格式。

DCO Sign-Off

DCO签署

The PR body must include a DCO sign-off line. Determine the user's name and email from git config:
bash
git config user.name
git config user.email
PR正文必须包含DCO签署行。从git配置中获取用户名和邮箱：
bash
git config user.name
git config user.email

Step 5: Compose the PR Body

步骤5：撰写PR正文

Use the exact template structure below. Fill in each section based on the diff (
git diff main...HEAD
). Check the applicable boxes and leave others unchecked. Do not add, remove, or reorganize sections.
markdown
undefined
使用以下精确的模板结构。根据代码差异（
git diff main...HEAD
）填写每个部分。勾选适用的选项框，其余保持未勾选状态。请勿添加、删除或重新组织任何章节。
markdown
undefined

Summary

摘要

<!-- 1-3 sentences: what this PR does and why. -->
<!-- 1-3句话：说明此PR的功能及实现原因。 -->

Related Issue

关联Issue

<!-- Fixes #NNN or Closes #NNN. Remove this section if none. -->
<!-- 格式为Fixes #NNN或Closes #NNN。若无关联Issue请删除此章节。 -->

Changes

变更内容

<!-- Bullet list of key changes. -->
<!-- 列出关键变更的项目符号列表。 -->

Type of Change

变更类型

  • Code change (feature, bug fix, or refactor)
  • Code change with doc updates
  • Doc only (prose changes, no code sample modifications)
  • Doc only (includes code sample changes)
  • 代码变更（新功能、Bug修复或重构）
  • 代码变更并包含文档更新
  • 仅文档变更（仅修改文本内容，未改动代码示例）
  • 仅文档变更（包含代码示例修改）

Verification

验证项

<!-- Check each item you ran and confirmed. Leave unchecked items you skipped. Doc-only changes do not require npm test unless you ran it. --> 
  • npx prek run --all-files
    passes
  • npm test
    passes
  • Tests added or updated for new or changed behavior
  • No secrets, API keys, or credentials committed
  • Docs updated for user-facing behavior changes
  • make docs
    builds without warnings (doc changes only)
  • Doc pages follow the style guide (doc changes only)
  • New doc pages include SPDX header and frontmatter (new pages only)
<!-- DCO sign-off required by CI. Run: git config user.name && git config user.email -->
Signed-off-by: {name} <{email}>
undefined
<!-- 勾选你实际运行并确认通过的项。未运行的项请保持未勾选状态。仅文档变更无需运行npm test，除非你实际执行了该命令。 --> 
  • npx prek run --all-files
    执行通过
  • npm test
    执行通过
  • 为新增或变更的行为添加或更新了测试用例
  • 未提交任何密钥、API密钥或凭证信息
  • 针对面向用户的行为变更更新了文档
  • make docs
    构建无警告（仅文档变更时需验证）
  • 文档页面遵循风格指南（仅文档变更时需验证）
  • 新增文档页面包含SPDX头部和前置元数据（仅新增页面时需验证）
<!-- CI要求必须包含DCO签署。执行命令：git config user.name && git config user.email -->
Signed-off-by: {name} <{email}>
undefined

Populating the Template

填充模板规则

Follow these rules when filling in the template:
  • Summary: Write 1-3 sentences describing what the PR does and why. Derive this from the commit messages and diff, not from generic descriptions.
  • Related Issue: Include 
    Fixes #NNN
    or 
    Closes #NNN
    if an issue exists. Remove the section entirely if there is no related issue.
  • Changes: Bullet list of key changes. Be specific — reference file names, commands, or behaviors that changed.
  • Type of Change: Check exactly one box. Use 
    [x]
    for checked, 
    [ ]
    for unchecked.
  • Verification: Check only the boxes for steps you actually ran and confirmed passing. Do not check boxes for steps you skipped or did not verify. For doc-only changes, 
    npm test
    is not required; leave it unchecked unless you ran it.
  • DCO Sign-Off: Replace 
    {name}
    and 
    {email}
    with values from 
    git config user.name
    and 
    git config user.email
    .
填充模板时请遵循以下规则：
  • 摘要：撰写1-3句话说明此PR的功能及实现原因。内容需来自提交信息和代码差异，而非通用描述。
  • 关联Issue：若存在关联Issue，添加
    Fixes #NNN
    或
    Closes #NNN
    格式内容。若无关联Issue，请完全删除该章节。
  • 变更内容：列出关键变更的项目符号列表。需具体明确——引用变更的文件名、命令或行为。
  • 变更类型：仅勾选一个选项框。使用
    [x]
    表示已勾选，
    [ ]
    表示未勾选。
  • 验证项：仅勾选你实际运行并确认通过的项。请勿勾选未运行或未验证的项。对于仅文档变更，
    npm test
    并非必填项；除非你实际执行了该命令，否则请保持未勾选状态。
  • DCO签署：将
    {name}
    和
    {email}
    替换为
    git config user.name
    和
    git config user.email
    输出的内容。

Step 6: Create the PR

步骤6：创建PR

Use 
gh pr create
with the 
--assignee @me
flag and a HEREDOC for the body to preserve formatting.
bash
gh pr create \
  --title "<type>(<scope>): <description>" \
  --assignee "@me" \
  --body "$(cat <<'EOF'
<full PR body from Step 5>
EOF
)"
使用
gh pr create
命令，添加
--assignee @me
参数，并通过HEREDOC传入正文以保留格式。
bash
gh pr create \
  --title "<type>(<scope>): <description>" \
  --assignee "@me" \
  --body "$(cat <<'EOF'
<步骤5中撰写的完整PR正文>
EOF
)"

Labels

标签

Add labels when applicable:
bash
--label "documentation"   # for doc-only or doc-inclusive PRs
--label "topic:security"  # for security-related changes
适当时添加标签：
bash
--label "documentation"   # 适用于仅文档变更或包含文档变更的PR
--label "topic:security"  # 适用于安全相关变更

Draft PRs

草稿PR

For work-in-progress that is not ready for review:
bash
gh pr create --draft --title "..." --assignee "@me" --body "..."
对于尚未准备好审核的进行中工作：
bash
gh pr create --draft --title "..." --assignee "@me" --body "..."

Step 7: Report the Result

步骤7：反馈结果

After the PR is created, display the PR URL as a clickable markdown link:
text
Created PR [#NNN](https://github.com/NVIDIA/NemoClaw/pull/NNN)
PR创建完成后，以可点击的Markdown链接形式展示PR URL：
text
已创建PR [#NNN](https://github.com/NVIDIA/NemoClaw/pull/NNN)

Common Mistakes to Avoid

需避免的常见错误

  • Do not invent your own PR body format. Use the template from Step 5 exactly.
  • Do not omit sections. Even if a section is not applicable, keep it with the "Skip if..." comment.
  • Do not check boxes for steps you did not run. If you did not run 
    make docs
    , leave that box unchecked.
  • Do not run the full test suite for doc-only changes by default. Run docs and hook checks instead, and leave 
    npm test
    unchecked unless you actually ran it.
  • Do not forget the DCO sign-off. CI will reject the PR without it.
  • Do not forget 
    --assignee @me
    .     Every PR must be assigned to its creator.
  • Do not create PRs from main. Always use a feature branch.
  • 请勿自行设计PR正文格式。严格使用步骤5中的模板。
  • 请勿省略章节。即使某章节不适用，也请保留其“若无需...”的注释内容。
  • 请勿勾选未运行的步骤对应的选项框。若未运行
    make docs
    ，请保持该选项框为未勾选状态。
  • 默认情况下，请勿为仅文档变更运行完整测试套件。请改为运行文档和钩子检查，且若未实际运行
    npm test
    ，请保持该项未勾选。
  • 请勿忘记DCO签署。若无DCO签署，CI将拒绝该PR。
  • 请勿忘记添加
    --assignee @me
    。每个PR必须分配给创建者本人。
  • 请勿从main分支创建PR。请始终使用功能分支。