发布时间:2026/9/7 18:50:36
Plane 的 create-pull-request 技能:用 Claude Code 技能文件自动化生成标准化 PR 的完整工作流 Plane 的 create-pull-request 技能用 Claude Code 技能文件自动化生成标准化 PR 的完整工作流【免费下载链接】plane Open-source Jira, Linear, Monday, and ClickUp alternative. Plane is a modern project management platform to manage tasks, sprints, docs, and triage.项目地址: https://gitcode.com/GitHub_Trending/pl/planePlane 仓库在.claude/skills/目录下维护了一组 Claude Code 技能SKILL.md其中create-pull-request技能定义了从分支上下文到 PR 创建的完整自动化流程以preview为默认目标分支从分支名中提取 Plane 工作项 ID 作为 PR 标题前缀并依据仓库根目录的.github/pull_request_template.md逐节填写 PR 正文。读完本文你可以完整理解该技能的六步工作流、每条 git/gh 命令的用途、PR 标题与正文的格式规范以及它与branch-name技能在分支命名约定上的配合关系。技能文件结构与 Frontmatter技能定义位于 .claude/skills/create-pull-request/SKILL.md采用标准的 Claude Code 技能格式YAML frontmatter 加 Markdown 正文。frontmatter 包含三个字段字段值作用namecreate-pull-request技能标识与所在目录同名descriptionUse when creating a pull request for the current branch — gathers branch context, generates a PR description following the repos pull_request_template.md, and creates the PR with a Plane work item ID prefix in the title.触发条件描述供 Agent 判断何时调用该技能user_invocabletrue允许用户直接显式调用如输入/create-pull-request而不仅由 Agent 自动触发该技能位于 Plane 的.claude/skills/技能族中同目录还有 branch-name、release-notes、react-doctor 等技能各自覆盖分支命名、PR 创建、发布说明生成、React 代码体检等环节共同构成一套面向 Plane 开发流程的 Agent 工具链。六步工作流从上下文采集到 PR 创建技能正文# Create PR一节把整个流程拆分为 6 个步骤每一步都有明确的命令与判断规则。步骤 1确定目标base分支默认目标分支为preview除非用户另行指定。这一点与 release-notes 技能 中记录的 Plane 发布约定一致——功能分支通常汇入preview/master体系PR 的 base 选择直接影响 diff 的基准。步骤 2并行采集分支上下文技能要求以下 6 个上下文采集操作尽量并行执行一次性拿全判断依据命令 / 操作用途git status -s检查是否存在未提交的改动避免 PR 遗漏工作区内容git diff base...HEAD --stat查看变更文件统计确定影响范围git log base...HEAD --oneline列出分支上全部提交而非仅最新一条git diff base...HEAD --no-color完整 diff用于理解改动实质若 diff 过大优先聚焦最重要的文件git rev-parse --abbrev-ref --symbolic-full-name {u}判断当前分支是否已设置远程跟踪upstream决定后续 push 是否需要-u读取.github/pull_request_template.md从仓库根目录读取 PR 模板作为正文结构的唯一来源其中三点值得注意使用base...HEAD三点语法而非base..HEAD即 diff 基于两者的共同祖先merge-base保证只包含本分支引入的变更git log明确覆盖分支上所有提交——这直接对应常见错误一节中的第一条只总结最新提交是典型错误读取 PR 模板而非凭记忆撰写正文保证 PR 结构与 .github/pull_request_template.md 保持同步模板变更时无需修改技能本身。步骤 3确定工作项Work ItemIDPlane 团队使用 Plane 自身作为项目管理工具PR 标题前缀采用[工作项ID]形式。ID 的确定规则优先从分支名提取。分支命名约定为type/work-item-id-short-description例如chore/silo-1146-foo→SILO-1146feat/web-1234-x→WEB-1234注意分支名中 ID 是小写的silo-1146作为 PR 标题前缀时需还原为大写形式SILO-1146。分支名中找不到时询问用户而不是自行编造一个 ID。这一约定与姊妹技能 branch-name 形成闭环该技能在创建分支时强制使用type/work-item-id-short-description格式其描述中明确写道compatible with the create-pr skills work item ID extraction与 create-pr 技能的 ID 提取逻辑保持兼容。branch-name 技能还给出了一组示例分支名fix/silo-1146-relative-config-urls feat/web-1234-app-tile-visibility chore/web-2201-bump-eslint refactor/silo-980-extract-auth-middleware docs/web-1500-pr-template-update perf/silo-1310-cache-workspace-lookup至于SILO、WEB等前缀的含义release-notes 技能 中有更完整的说明[WEB-XXXX]是 web/前端产品项[SILO-XXXX]对应 SiloSlack、GitHub、GitLab 等集成项目另有[MOBILE-XXXX]、[API-XXXX]等。步骤 4按模板起草 PR这是技能的核心产出环节规则分为标题与正文两部分。标题格式[WORK-ITEM-ID] type: concise summarytype反映变更性质fix、feat、chore、refactor、docs、perf等与 branch-name 技能中定义的分支类型枚举保持一致整体长度控制在 70 字符以内。技能给出的示例标题[SILO-1146] fix: allow relative URLs for configuration_url and improve app tile visibility正文结构要求基于实际 diff 填写模板的每一个小节Fill in every section from the PR template based on the actual diff。模板即 .github/pull_request_template.md共五个小节技能的填写要求如下模板小节模板原文注释技能的填写要求DescriptionProvide a detailed description of the changes in this PR简洁说明 PR 做了什么、为什么做聚焦 what 与 why 而非逐行改动提及重要的实现决策Type of Change六个候选复选框Bug fix / Feature / Improvement / Code refactoring / Performance improvements / Documentation update勾选与变更匹配的框可多选Screenshots and MediaAdd screenshots to help explain your changes, ideally showcasing before and after保留占位注释!-- Add screenshots here --截图由用户后续补充Test ScenariosPlease describe the tests that you ran to verify your changes给出基于实际改动的具体验证场景如进入项目设置页并验证新开关生效而非泛泛的通用描述ReferencesLink related issues if there are any包含工作项 ID、用户提到的关联 issue以及对话中引用过的 Sentry issue 链接/ID如SENTRY-ABC123此外技能要求在正文末尾追加一行 Claude Code 会话标识Append a Claude Code session line at the bottom of the body用于标明该 PR 描述由 Claude Code 会话生成——这是一种常见的 AI 辅助贡献标注实践。步骤 5推送并创建 PR在尽可能并行的前提下执行两件事若步骤 2 中发现分支没有 upstream推送时带上-u参数建立跟踪关系git push -u origin branch用 GitHub CLI 创建 PR正文通过HEREDOC传入以避免 shell 对反引号、$等字符的解析gh pr create --base preview \ --title [SILO-1146] fix: allow relative URLs for configuration_url \ --body $(cat EOF ### Description ... EOF )单引号包裹的EOF是关键细节——release-notes 技能 在gh pr edit --body场景下也使用了同样的写法并特别强调Always use a HEREDOC with single-quotedEOFso backticks/dollars in the notes are preserved。步骤 6返回 PR URL流程的终点是把gh pr create返回的 PR 链接交还给用户形成闭环。编写准则与常见错误技能文档用两节清单约束生成质量这部分对任何让 Agent 代写 PR 描述的实践都有参考价值。Guidelines准则描述要简洁但信息充分concise but informative列举多项改动时使用要点列表bullet points聚焦用户可见的影响而非实现细节不得编造与本次改动无关的测试场景Dont fabricate test scenarios that arent relevant to the actual changes——这条与步骤 4 中Test Scenarios 必须基于实际改动相互呼应。Common Mistakes常见错误只总结最新一条提交而漏掉分支上的其他提交——对应步骤 2 中git log base...HEAD覆盖全部提交的设计推送前忘记检查 upstream——对应步骤 2 中git rev-parse {u}检查的设计工作项 ID 格式与分支约定不一致如大小写、位置放错——对应步骤 3 的提取规则也是 branch-name 技能 中Common Mistakes强调的镜像问题该技能指出把 ID 放在末尾而不是 type 之后会破坏提取把 PR 正文整体包进代码围栏再传给gh pr create——会导致 GitHub 把正文渲染成代码块而非 Markdown。该技能在 Plane 仓库中的定位从源码结构看Plane 仓库把 PR 流程的多个环节都沉淀成了可版本化的技能文件创建分支时branch-name 技能 保证分支名携带可提取的工作项 ID提交代码前react-doctor 技能 要求对 React 改动跑npx react-doctorlatest --verbose --diff回归体检分数回退需先修复再提交开 PR 时本文介绍的 create-pull-request 技能完成上下文采集、标题规范化、模板化正文与推送创建发版时release-notes 技能 从 release PR 的提交列表生成 GitHub Releases 格式的版本说明并明确排除了Sync: Enterprise Changes等同步噪音提交。值得注意的是与 create-pull-request 配套的 AGENTS.md 定义了仓库级的命令与代码风格约定如pnpm dev、pnpm check、OxLint、MobX store 位于packages/shared-state等Agent 在采集 diff 并撰写Test Scenarios时可参照其中的测试约定后端 pytest 套件通过docker-compose-test.yml运行给出贴合实际的验证建议。小结create-pull-request技能本质上是一份把人类撰写 PR的隐性规范显式化为机器可执行流程的技能文件它用git log base...HEAD与git diff base...HEAD保证不遗漏分支上的任何提交用type/work-item-id-...分支约定保证工作项 ID 可机械提取用preview默认 base 与gh pr create 单引号 HEREDOC 保证推送与创建动作的可复现性并以上游 PR 模板 .github/pull_request_template.md 作为正文结构的单一事实来源。对维护者而言模板放.github/、流程放.claude/skills/、二者解耦的划分方式使得 PR 格式变更时无需改动技能逻辑而 Agent 行为调整时也无需触碰模板文件——这对任何希望规范化 AI 辅助贡献流程的开源仓库都是可以直接借鉴的组织方式。【免费下载链接】plane Open-source Jira, Linear, Monday, and ClickUp alternative. Plane is a modern project management platform to manage tasks, sprints, docs, and triage.项目地址: https://gitcode.com/GitHub_Trending/pl/plane创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考

相关新闻

2026/9/7 18:50:36

量子传感器赋能物联网安全:从QRNG到QKD的落地实践

物联网设备数量已经冲破百亿级,摄像头、门锁、传感器、汽车、工业控制器,几乎每一样东西都在联网。但有个特别讽刺的现实:这批设备里,相当一部分用的还是几十年前设计的加密算法,密钥强度低、随机数质量差、固件常年不…

2026/9/7 18:50:36

VSCode无法注释特定语言?从语言模式识别到扩展冲突的排查指南

1. 问题现象与定位思路:先分清“注释失效”是哪种类型如果你正在看这篇文章,估计你已经遇到过这种场景:在VSCode里打开一个文件,手指很自然地按了一下Ctrl/,结果光标处什么都没发生。再按一次,还是没反应。…

2026/9/7 19:40:46

MySQL事务提交失败处理实战:回滚、重试与幂等设计

在开发中遇到“MySQL事务提交失败”这类问题,几乎是每个后端工程师都绕不过去的坎。尤其是涉及订单、库存、支付这类核心链路时,一旦事务在提交阶段爆出异常,很多人第一反应就是“回滚不就完了”,但真正落地时却发现,情…

2026/9/7 19:40:46

数据库课程为何从C++热身开始?CMU 15-445 Project #0解析

1. 为什么一门数据库课程要把第一个项目做成C热身很多人第一次看到CMU 15-445的Project #0时都有同一个疑问:我明明是来学数据库的,为什么第一个任务不是写SQL解析器,也不是实现存储引擎,而是先做一堆C练习?这个问题想…

2026/9/7 19:35:46

ETL设计实战:从分层架构到增量同步与性能优化

做数据集成这行越久,我越觉得 ETL 不只是一门“技术活”,它更像是在给企业数据大厦浇筑地基。不管是传统数仓还是现在的数据湖仓一体,数据要能真正用起来,第一步永远绕不开抽取、转换、加载这几个动作。很多刚入门的朋友会问我&am…

2026/9/7 0:47:43

超人会飞不算本事:系统稳定依赖清晰规则与边界设计

开头先不绕弯子。“#斯坦李吐槽dc 所以超人是无缘无故会飞的嘛哈哈哈哈哈哈哈锤哥真是技术人才啊!#雷神 #复联”这类调侃式短标题,第一波冲击力在于它把两个宇宙的角色塞进同一个吐槽箱里,但细想一下就能发现,它真正碰到的根本不是…

2026/9/7 0:14:19

超人VS蜘蛛侠:拆解超级IP的影响力与传播方法论

把“蜘蛛侠 vs 超人”放在 CSDN 上聊,可能很多人第一反应是走错片场了。但如果把这两个角色看成“两个持续运营了 80 多年的文化产品”,你会发现,这场比较本质上是两个不同 IP 策略的长期结果对比:超人赢在定义了整个超级英雄题材…

2026/9/7 0:14:17

基于CNN的调制信号识别:MATLAB实现时频图分类实战

简介:本资源是一套面向通信工程与信号处理方向学习者、研究者的深度学习实践方案,聚焦调制信号自动检测与识别这一典型无线通信任务,解决传统方法依赖人工特征、低信噪比下性能下降等痛点。压缩包共12个文件(10.73MB)&…

2026/9/7 0:03:36

基于YOLOv8和PyQt5的麦穗稻穗检测识别系统设计与实现

这次我们来看一个把目标检测算法和桌面端工具结合得很典型的项目:基于 YOLOv8 PyQt5 的麦穗稻穗检测识别系统。这个项目本身不是新概念,但它的价值在于落地形态很完整。YOLOv8 负责核心的麦穗稻穗目标检测,PyQt5 负责提供可视化的桌面交互界…

2026/9/7 0:03:36

UL 1642锂电池安全标准全解析:测试项目、认证流程与避坑指南

简介:UL 1642是锂电池安全领域的重要规范,本中文版资源适合锂电池制造商、检测机构工程师及产品认证相关人员阅读,用于理解电池在设计与制造层面的安全要求、测试方法与合规要点。资源共1个PDF文件,压缩包大小834KB,便…

2026/9/7 0:03:36

BS EN 13814-1-2019游乐设施安全标准:设计与制造核心要点解析

简介:BS EN 13814-1:2019是英国采纳欧洲标准EN 13814-1:2019的正式版本,由BSI标准出版,重点规定游乐设施和游乐设备在设计与制造环节的安全准则,与BS EN 13814-2:2019、BS EN 13814-3:2019共同取代旧版BS EN 13814:2004。该标准面…

2026/9/7 16:23:03

USB Type-C PCB布局分区设计:电源、高速信号与PD协议全攻略

做硬件这行,Type-C接口算是典型的“看着简单,做起来全坑”的东西。光引脚就24个,高低速信号、电源、控制线全部塞在一个小小的连接器里,如果PCB布局不做规划,打样回来基本就是“插上没反应”、“高速掉线”、“静电一打…

2026/9/6 19:33:50

系统编程学习原型如何补齐稳定性边界

系统编程学习原型如何补齐稳定性边界预算有限时&#xff0c;我先优化明显多余的复制&#xff0c;而不是猜测性地换容器。用借用传递只读数据通常就能减少分配&#xff1a; fn parse(line: &str) -> Result<Item, Error> { /* ... */ }用基准确认热点确实在分配&am…

2026/9/6 10:19:40

雨花区哪家财务公司代理记账比较好?

在雨花区&#xff0c;企业处理财税事务常常面临诸多挑战&#xff0c;选择一家靠谱的财务公司至关重要。湖南巨勤财务管理咨询有限公司就是本地正规实体财税服务机构&#xff0c;深耕本地工商财税行业多年&#xff0c;熟悉当地工商局、税务局最新政策与申报流程。主营公司注册、…