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 ready-for-review PR, not a draft, unless the user asks for a draft. 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。应在本地将 diff 与基础分支（通常是

origin/main

）进行对比，确保其内容符合目标。

PR 标题通常会成为 commit message，因此应遵循仓库的标题规范。可以查看近期合并的 PR 和 Git history 以寻找示例。优先使用简洁、便于阅读的标题，说明这项变更为何重要：

BAD

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

GOOD

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

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

BAD

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

GOOD

✅ 在已有 worktree 上启动 new thread 时，我的“new worktree”默认值会被忽略，非常不直观。现在你的 preferences 始终会生效。

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

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

如果部分变更由 subagent model 完成，也应包含这些 model。使用 harness 报告的 model 名称。如果无法获取 model 身份信息，则仅注明 harness，不要猜测 model。

提交前，检查标题、描述、引述和附件中是否包含 secrets 或隐私信息。

应创建一个可供审查的 PR，而不是 draft，除非用户明确要求创建 draft。如果

gh pr create

因 GraphQL rate limit 已耗尽而失败，则使用 REST 接口：

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

如果用户还要求持续跟进该 PR，请继续使用

babysit-pr

skill。

不要发布与用户需求无关的后续 PR 评论。确有必要发表评论时，使用

leaving-pr-comments

skill。