github-pr-creation

github-pr-creation 技能概览

github-pr-creation 的作用

github-pr-creation 技能可以把已经完成的分支整理成一个可供审查的 GitHub Pull Request，并补上正确的目标分支、任务上下文和 PR 文案。它面向的是需要有纪律的 github-pr-creation 工作流的人，而不是只想随手“帮我写个 PR 描述”的通用提示词。

适合谁使用

如果你正在准备 feature、fix、hotfix 或 release PR，并希望草稿能反映仓库约定、任务追踪和提交历史，那么就该用这个 github-pr-creation skill。当目标分支不明显、需求散落在多个 spec 文件里，或者你需要符合 Conventional Commits 风格的 PR 标题和结构化模板时，它尤其有用。

它最擅长什么

对 Git Workflows 来说，github-pr-creation 的核心价值在于“先验证，再写作”。它会检查当前分支状态，要求确认目标分支，搜索任务文档，并帮助把 PR 建立在真实已完成的工作之上。相比一段式提示词，在需要对齐分支策略、 issue 引用和模板分区时，它要更稳。

什么时候不适合用

不要把这个技能用在合并已有 PR、backport 自动化，或者其他与 GitHub 维护无关的事情上。如果你只需要一个简短标题，而且已经清楚知道精确 diff，普通提示词可能就够了；当工作流和证据更重要时，这个技能才更有价值。

如何使用 github-pr-creation 技能

安装并先读对文件

执行 github-pr-creation install 时，先用 npx skills add fvadicamo/dev-agent-skills --skill github-pr-creation 把技能加进来。然后先读 SKILL.md，再读 references/pr_templates.md。如果还需要更多上下文，就检查仓库里实际使用的任务或 spec 文件，比如 .s2s/plans/*.md、.kiro/specs/*/tasks.md、.cursor/rules/*.md、.trae/rules/*.md 或 docs/specs/。

给它真正需要的输入

github-pr-creation usage 最好一次给全四样：当前分支、预期目标分支、这个 PR 对应的任务或 spec，以及任何约束，比如已跑过的测试、文档改动或迁移说明。弱一点的请求是“帮我做个 PR”；更强的说法是：“我现在在 feature/payment-retry，目标是 develop，这个 PR 关闭 .s2s/plans/billing.md 里的 2.3 任务，测试已通过，我需要一个 feature PR 草稿。”

按它预期的工作流来走

一个合格的 github-pr-creation guide 应该先确认分支流转，再检查任务文档，然后把工作映射到正确的 PR 模板上。你在希望它生成像 feat(scope): description 这样的标题、概括变更内容，并列出与分支类型匹配的 checklist 项时，就该用它。为了效果最好，先让它检查提交记录和任务文件，再让它写最终 PR 正文。

用模板感知式提示

发提示时，要明确 PR 类型和已有证据。比如：“从 feature/search-filter 到 develop 创建一个 feature PR。使用 references/pr_templates.md，包含相关 task ID，注明测试已通过，并保持描述简洁。”这样能帮助 github-pr-creation 输出更贴合仓库模板的内容，而不是自己凭空编造章节。

github-pr-creation 技能 FAQ

github-pr-creation 只是用来写 GitHub PR 文本吗？

不是。github-pr-creation skill 的目标是按分支规则、任务追踪和审查预期来准备 PR。文本只是最终产物，真正的工作是根据分支和支持证据判断 PR 应该写什么。

它和普通提示词有什么不同？

普通提示词也能起草 PR，但 github-pr-creation 多了工作流纪律：确认目标分支、查找任务文档，并使用仓库专属模板。当分支历史和需求比泛泛措辞更重要时，这种差异就会很明显。

新手也能用吗？

可以，只要他们能说清自己的分支，并知道改了什么。对新手来说，把仓库里的任务或 spec 路径直接贴进提示词，往往比凭记忆描述一个 PR 更有帮助。

什么时候该选别的方案？

如果你需要合并已有 PR，请改用 github-pr-merge。如果你的仓库没有任务文档或分支约定，你只是想要一个粗略摘要，那么一个更简单的草稿提示词可能比完整的 github-pr-creation 流程更快。

如何改进 github-pr-creation 技能

提供更干净的分支和任务证据

最好的 github-pr-creation 结果，来自清晰的分支名、已关联的任务，以及简短的变更摘要。把准确的目标分支、任何 issue 或 task ID，以及涉及的文件或功能范围都写清楚，这样技能就能避免生成空泛的 PR 语言。

说明改了什么、验证了什么

如果你希望 PR 正文更有说服力，就要明确你是新增了测试、更新了文档、改了迁移，还是只做了代码重构。比如：“在 src/payments/retry.ts 中加入重试逻辑，并已由单元测试覆盖，没有 schema 变更”就比“修复了支付 bug”有用得多。

注意常见失败模式

最常见的失败模式是缺少任务上下文，结果就会产出通用 PR 文案。另一个问题是跳过目标分支检查，这会让 PR 提交到错误的 base branch。第三个问题是夸大完成度；如果任务只做了一部分，就要如实说明并列出缺口。

从草稿迭代到可审查版本

把第一次 github-pr-creation 的输出当作草稿，再用具体细节收紧它：任务 ID、范围、测试结果，以及必要时的发布或回滚说明。如果 PR 模板要求 checklist 项，只保留你能够真实核实的内容。通常这就是把 github-pr-creation 用法快速打磨成更干净、可直接审查的 PR 的最佳方式。