file-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

File PR

提交 PR

Before filing, check whether a PR for this branch already exists. Review the diff locally against the base branch (usually

origin/main

) to make sure its contents match the goal.

PR titles usually become commit messages, so follow the repository's title conventions. Look at recently merged PRs and Git history for examples. Prefer a concise, human-readable title that explains why the change matters:

BAD

❌ perf(server): negotiate permessage-deflate on the websocket

GOOD

✅ perf(server): cut websocket frame size by 70%+ with gzipping

Open the description with a simple explanation of the problem based on the user's original prompt, then briefly explain the solution. Do not lead with an implementation inventory:

BAD

❌ Removed implicit workspace carry-over from every "new thread" entry point (cmd+n / cmd+shift+o, sidebar v1/v2 buttons, command palette). New threads inherit only the project from context; branch, worktree, and env mode always come from the configured defaults. Deleted buildContextualThreadOptions, startNewThreadInProjectFromContext, and the v1 sidebar's seed-context machinery.

GOOD

✅ My "new worktree" default was ignored when starting new threads on existing worktrees. Super unintuitive. Now your preferences always apply.

End the description with the public model name and harness that made the changes, for example

Created with <model> in <harness>.

Include subagent models that wrote part of the change. Use the model name the harness reports. If model identity is unavailable, name the harness without guessing a model.

Before submission, check the title, description, quotes, and attachments for secrets and private details.

Open a real PR rather than a draft so review bots run. If

gh pr create

fails because the GraphQL rate limit is used up, open it through REST with

gh api repos/<owner>/<repo>/pulls -f title=... -f head=... -f base=... -F body=@<file>

. If the user also asked to babysit it, continue with the

babysit-pr

skill.

Do not post a follow-up PR comment unless it serves the user's request. When a comment is needed, use the

leaving-pr-comments

skill.

提交前，检查此分支是否已有 PR。相对于基础分支（通常是

origin/main

）在本地审查 diff，确认其内容与目标一致。

PR 标题通常会用作 commit message，因此应遵循仓库的标题规范。可以查看最近合并的 PR 和 Git 历史记录作为参考。优先使用简洁、易读的标题，并说明为何该变更很重要：

BAD

❌ perf(server): 在 websocket 上协商 permessage-deflate

GOOD

✅ perf(server): 通过 gzipping 将 websocket 帧大小缩减 70%+

描述开头应根据用户的原始需求，简洁地说明问题，然后简要解释解决方案。不要以实现细节清单开头：

BAD

❌ 从每个“new thread”入口（cmd+n / cmd+shift+o、sidebar v1/v2 按钮、command palette）中移除了隐式 workspace carry-over。新线程仅从 context 继承 project；branch、worktree 和 env mode 始终来自配置的默认值。删除了 buildContextualThreadOptions、startNewThreadInProjectFromContext 以及 v1 sidebar 的 seed-context 机制。

GOOD

✅ 在现有 worktree 上启动新线程时，我的“new worktree”默认值会被忽略。这太反直觉了。现在你的偏好设置始终会生效。

描述结尾应注明完成变更的公开模型名称和 harness，例如

由 <model> 在 <harness> 中创建。

如果部分变更由 subagent 模型编写，也应包含这些模型。使用 harness 报告的模型名称。如果无法确定模型身份，则仅注明 harness，不要猜测模型。

提交前，检查标题、描述、引用的内容和附件中是否包含密钥或私密信息。

创建正式 PR 而非草稿 PR，以便 review bot 能够运行。如果

gh pr create

因 GraphQL 速率限制用尽而失败，则通过 REST 提交：

gh api repos/<owner>/<repo>/pulls -f title=... -f head=... -f base=... -F body=@<file>

。如果用户还要求持续跟进（babysit），则继续使用

babysit-pr

skill。

除非后续评论有助于满足用户需求，否则不要在 PR 下发表评论。需要发表评论时，使用

leaving-pr-comments

skill。