wtf.create-pr

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create PR

创建PR

Open a pull request for a completed task branch. Core value: reads the full spec hierarchy (Task + Feature + Epic) and the branch diff to write a PR description that explains why the change exists — not just what it does.

为已完成的任务分支打开拉取请求。核心价值：读取完整的规格层级（Task + Feature + Epic）和分支差异，撰写PR描述来解释为什么要进行这项更改——而不只是说明更改了什么。

Process

流程

0. GitHub CLI setup

0. GitHub CLI 配置

Run steps 1–2 of

../references/gh-setup.md

(install check and auth check). Stop if

gh

is not installed or not authenticated. Extensions are not required for this skill.

Skip this step if invoked from

verify-task

or another skill that already ran gh-setup this session.

执行

../references/gh-setup.md

中的步骤1–2（安装检查和身份验证检查）。如果

gh

未安装或未通过身份验证，则停止操作。此技能不需要扩展。

如果是从

verify-task

或本次会话中已运行gh-setup的其他技能调用，则跳过此步骤。

1. Confirm the branch

1. 确认分支

Check the current branch and verify it is not

main

bash

git branch --show-current

If on

main

, ask: "Which branch should I open a PR from?"

Check whether a PR already exists for this branch:

bash

gh pr list --head <branch_name> --state open

If an open PR already exists, print its URL and call

AskUserQuestion

with:

```
question
```
: "A PR already exists for this branch. Would you like me to update its description instead?"
```
header
```
: "Existing PR"

options

[{label: "Update description", description: "Edit the existing PR's description"}, {label: "Open a new one", description: "Create a new PR anyway"}]

Update description → skip to step 5, targeting the existing PR for update via
```
gh pr edit <pr_number>
```
.
Open a new one → continue.

检查当前分支并验证它不是

main

分支：

bash

git branch --show-current

如果当前在

main

分支上，询问：“我应该从哪个分支创建PR？”

检查该分支是否已存在PR：

bash

gh pr list --head <branch_name> --state open

如果已存在打开的PR，打印其URL并调用

AskUserQuestion

，参数如下：

```
question
```
: “该分支已存在PR。您是否希望我更新它的描述？”
```
header
```
: “已存在的PR”

options

[{label: "更新描述", description: "编辑现有PR的描述"}, {label: "创建新PR", description: "无论如何都创建新PR"}]

更新描述 → 跳至步骤5，通过
```
gh pr edit <pr_number>
```
针对现有PR进行更新。
创建新PR → 继续操作。

2. Identify the Task (if any)

2. 识别任务（如果有）

Try to extract a task number from the branch name (e.g.

task/42-date-range-filter

→

#42

If found, call

AskUserQuestion

with

question: "I found Task #<n> linked to this branch. Is that the right task?"

header: "Linked task"

, and

options: [{label: "Yes, that's correct", description: "Use Task #<n>"}, {label: "No, use a different task", description: "I'll provide the correct issue number"}]

If not found or the user says no, call

AskUserQuestion

with

question: "Is there a Task issue linked to this work?"

header: "Linked task"

, and

options: [{label: "No linked task", description: "Proceed without a task link"}, {label: "Yes — I'll provide the number", description: "Enter the task issue number"}]

尝试从分支名称中提取任务编号（例如

task/42-date-range-filter

→

#42

）。

如果找到，调用

AskUserQuestion

，参数为

question: "我发现该分支关联了任务#<n>。是否正确？"

，

header: "关联任务"

，以及

options: [{label: "是的，正确", description: "使用任务#<n>"}, {label: "否，使用其他任务", description: "我将提供正确的议题编号"}]

。

如果未找到或用户选择否，调用

AskUserQuestion

，参数为

question: "这项工作是否关联了任务议题？"

，

header: "关联任务"

，以及

options: [{label: "无关联任务", description: "不关联任务继续操作"}, {label: "是——我将提供编号", description: "输入任务议题编号"}]

。

3. Lifecycle check (if Task linked)

3. 生命周期检查（如果关联了任务）

If a Task issue is known, check its labels:

bash

gh issue view <task_number> --json labels --jq '.labels[].name'

If the

verified

label is absent, warn the user that the task hasn't been verified yet and that the recommended flow is: write-task → design-task → implement-task → verify-task → create-pr. Then call

AskUserQuestion

with:

```
question
```
: "This task hasn't been verified yet. How would you like to proceed?"
```
header
```
: "Verify first?"

options

[{label: "Verify first", description: "Run

verify-task

 before opening the PR (default)"}, {label: "Open PR anyway", description: "Skip verification and open the PR now"}]

Verify first → follow the
```
verify-task
```
process, passing the Task number in as context.
Open PR anyway → proceed.

If no Task is linked, skip this step.

如果已知任务议题，检查其标签：

bash

gh issue view <task_number> --json labels --jq '.labels[].name'

如果

verified

标签不存在，警告用户该任务尚未验证，推荐流程为：write-task → design-task → implement-task → verify-task → create-pr。然后调用

AskUserQuestion

，参数如下：

```
question
```
: “该任务尚未验证。您希望如何继续？”
```
header
```
: “先验证？”

options

[{label: "先验证", description: "创建PR前先运行

verify-task

（默认选项）"}, {label: "直接创建PR", description: "跳过验证，立即创建PR"}]

先验证 → 遵循
```
verify-task
```
流程，传入任务编号作为上下文。
直接创建PR → 继续操作。

如果未关联任务，跳过此步骤。

4. Fetch the spec hierarchy

4. 获取规格层级

If a Task issue is known, fetch the full hierarchy:

bash

gh issue view <task_number>    # Gherkin, Contracts, DoD, Test Mapping — also yields feature and epic numbers

如果已知任务议题，获取完整层级：

bash

gh issue view <task_number>    # Gherkin、契约、DoD、测试映射——同时获取功能和史诗编号

Extract feature and epic numbers, then in parallel:

提取功能和史诗编号，然后并行执行：

gh issue view <feature_number> # ACs, user stories gh issue view <epic_number> # Goal, context, constraints


**If no Task issue**, skip hierarchy fetch. The PR will be written from diff context alone (step 5).

gh issue view <feature_number> # 验收标准、用户故事 gh issue view <epic_number> # 目标、背景、约束条件


**如果无任务议题**，跳过层级获取。PR将仅基于差异上下文撰写（步骤5）。

5. Inspect the diff

5. 检查差异

Determine the base branch using the same logic as step 8 (task/* → parent feature branch; feature/* → main), then collect the branch diff against that base:

bash

git log <base_branch>..HEAD --oneline
git diff <base_branch>...HEAD --stat

This avoids including unrelated merged commits when the branch has a long history against main. Use

--stat

output only unless a specific commit message is ambiguous and cannot be resolved without the diff.

使用与步骤8相同的逻辑确定基准分支（task/* → 父功能分支；feature/* → main），然后收集该分支相对于基准分支的差异：

bash

git log <base_branch>..HEAD --oneline
git diff <base_branch>...HEAD --stat

当分支相对于main的历史较长时，这可以避免包含无关的合并提交。仅使用

--stat

输出，除非特定提交消息不明确，必须查看完整差异才能解析。

6. Draft the PR

6. 撰写PR草稿

Title generation: Spawn a subagent using the

claude-haiku-4-5

model to generate a PR title following Conventional Commits 1.0.0. Pass in the task title (if available), the commit log, and whether this is a breaking change. If the subagent returns nothing usable, generate the title directly using the same rules below. Rules:

Format:
```
<type>[optional scope]: <description>
```

Types:

feat

(new feature),

fix

(bug fix),

docs

style

refactor

perf

test

build

chore

ci

Scope: optional noun in parentheses describing the codebase section, e.g.
```
feat(auth): …
```
Breaking change: append
```
!
```
after type/scope, e.g.
```
feat!: …
```
Description: lowercase, imperative mood, no period at end
Under 72 characters total

Examples:

feat(search): add date range filter

fix(payments): prevent double settlement

refactor(orders): extract fulfilment service

Body: Use the structure from @.github/pull_request_template.md. Fill in all sections:

Summary: derived from the Task's Intent + Functional Description (or commit messages if no Task). Explain the why.
Changes: grouped logical summary of
```
git diff --stat
```
output — not a file list.
Test plan: if a Task exists, derive checklist items from the Gherkin scenario names. If no Task, derive from changed files and commit messages. At minimum one item per observable behavior changed.
Related: one
```
Closes #<n>
```
line per closed issue — never comma-separated. If a Task exists, include
```
Closes #<task_number>
```
. If the PR also closes the parent Feature (all sibling tasks already merged), add
```
Closes #<feature_number>
```
on its own line. Example:
```
Closes #42
Closes #15
```

标题生成：使用

claude-haiku-4-5

模型生成子代理，按照Conventional Commits 1.0.0规范生成PR标题。传入任务标题（如果可用）、提交日志以及是否为破坏性更改。如果子代理未返回可用内容，则直接按照以下规则生成标题：

格式：
```
<type>[可选范围]: <描述>
```
类型：
```
feat
```
（新功能）、
```
fix
```
（bug修复）、
```
docs
```
、
```
style
```
、
```
refactor
```
、
```
perf
```
、
```
test
```
、
```
build
```
、
```
chore
```
、
```
ci
```
范围：可选的名词，放在括号中描述代码库部分，例如
```
feat(auth): …
```
破坏性更改：在类型/范围后追加
```
!
```
，例如
```
feat!: …
```
描述：小写、祈使语气，结尾无句号
总长度不超过72个字符

示例：

feat(search): add date range filter

、

fix(payments): prevent double settlement

、

refactor(orders): extract fulfilment service

正文：使用@.github/pull_request_template.md中的结构。填写所有部分：

摘要：来自任务的意图+功能描述（如果无任务则来自提交消息）。解释为什么进行更改。
更改内容：对
```
git diff --stat
```
输出进行逻辑分组总结——不是文件列表。
测试计划：如果存在任务，从Gherkin场景名称生成检查项。如果无任务，从更改的文件和提交消息生成。至少为每个更改的可观察行为添加一个检查项。
关联内容：每个关闭的议题单独一行
```
Closes #<n>
```
——切勿用逗号分隔。如果存在任务，包含
```
Closes #<task_number>
```
。如果PR同时关闭父功能（所有兄弟任务已合并），单独添加一行
```
Closes #<feature_number>
```
。示例：
```
Closes #42
Closes #15
```

7. Review with user

7. 与用户审核

Show the draft title and body. Then call

AskUserQuestion

with

question: "Does this look right?"

header: "Review"

, and

options: [{label: "Looks good — create the PR", description: "Proceed with PR creation"}, {label: "I have changes", description: "I want to adjust something first"}]

Apply edits, then proceed.

展示草稿标题和正文。然后调用

AskUserQuestion

，参数为

question: “这样看起来是否正确？”

，

header: “审核”

，以及

options: [{label: “没问题——创建PR”, description: “继续创建PR”}, {label: “我需要修改”, description: “我想先调整一些内容”}]

。

应用修改后继续操作。

8. Create the PR

8. 创建PR

Determine the base branch from the current branch name:

```
task/*
```
branch → target the parent feature branch (
```
feature/<feature-number>-<feature-slug>
```
)
```
feature/*
```
branch → target
```
main
```

Other → call

AskUserQuestion

with

question: "What branch should this PR target?"

header: "Base branch"

, options derived from

git branch -r

Write the body to a temp file, then create the PR:

bash

undefined

根据当前分支名称确定基准分支：

task/*

分支 → 目标为父功能分支（

feature/<feature-number>-<feature-slug>

）

```
feature/*
```
分支 → 目标为
```
main
```

其他分支 → 调用

AskUserQuestion

，参数为

question: “此PR应针对哪个分支？”

，

header: “基准分支”

，选项来自

git branch -r

的结果。

将正文写入临时文件，然后创建PR：

bash

undefined

task branch:

task分支:

gh pr create
--title "<title>"
--body-file /tmp/wtf-create-pr-body.md
--base feature/<feature-number>-<feature-slug>

feature branch:

feature分支:

gh pr create
--title "<title>"
--body-file /tmp/wtf-create-pr-body.md
--base main


Print the PR URL.

gh pr create
--title "<title>"
--body-file /tmp/wtf-create-pr-body.md
--base main


打印PR的URL。

9. Update the Task issue (if linked)

9. 更新任务议题（如果关联）

If a Task issue is linked, post a comment linking the PR:

bash

gh issue comment <task_number> --body "PR opened: <pr_url>"

如果关联了任务议题，发布评论链接该PR：

bash

gh issue comment <task_number> --body "PR已创建: <pr_url>"

10. Offer next steps

10. 提供下一步选项

Call

AskUserQuestion

with:

```
question
```
: "What's next?"
```
header
```
: "Next step"

options

[{label: "Request a review", description: "Add reviewers to this PR now (default)"}, {label: "Done", description: "Exit — no further action"}]

Request a review → call
```
AskUserQuestion
```
with
```
question: "Who should review this?"
```
,
```
header: "Reviewer"
```
, and
```
options
```
pre-filled with team member usernames inferred from recent git log authors or the repository's CODEOWNERS file. Then:
bash
```
gh pr edit <pr_number> --add-reviewer <username>
```
For multiple reviewers, pass a comma-separated list:
```
--add-reviewer user1,user2
```
. Print the PR URL.
Done → exit.

调用

AskUserQuestion

，参数如下：

```
question
```
: “下一步做什么？”
```
header
```
: “下一步”

options

[{label: “请求审核”, description: “立即为此PR添加审核者（默认选项）”}, {label: “完成”, description: “退出——无需进一步操作”}]

请求审核 → 调用
```
AskUserQuestion
```
，参数为
```
question: “谁来审核此PR？”
```
，
```
header: “审核者”
```
，选项从最近的git日志作者或仓库的CODEOWNERS文件中推断出团队成员用户名。然后执行：
bash
```
gh pr edit <pr_number> --add-reviewer <username>
```
若有多个审核者，传入逗号分隔的列表：
```
--add-reviewer user1,user2
```
。打印PR的URL。
完成 → 退出。