用途
该项目管理技能提供一套与工具无关的规范，用于撰写 issue 和 PR。规范同样适用于 GitHub Issues、Linear 以及任何 PR 托管平台，帮助团队在创建 issue、撰写 PR 时保持格式统一与流程清晰。
主要能力
一、Issue 规范
标题格式
- 使用祈使动词短语，长度在 70 字符以内
- 采用 conventional commit 前缀：feat:、fix:、refactor:、docs:、chore:、ci:、perf:、test:
- 示例：fix: shell startup hangs when config is missing
描述结构
分为四段，空段可省略：
- Context：当前现状、触发此项工作的原因
- Problem：哪里有问题或缺失什么
- Proposal：如何解决（范围、方法）
- References：相关 issue、PR、文档、审计发现
范围纪律
一个 issue 只聚焦一个关注点。如果一个 issue 覆盖两个互不相关的改动，应拆分。多关注点的 PR 引用多个 issue——每个关注点各自对应一个。
二、PR 规范
标题
- 沿用 conventional commit 格式：type(scope): description
- 与分支类型前缀保持一致
- 长度在 70 字符以内
摘要要点
- 说明改了什么以及为什么（而非怎么做的）
- 每条要点对应一个提交或一个关注点
- 覆盖分支相对 main 的所有提交，而不仅仅是最新提交
测试计划
- 可验证的操作：写“运行 just api-test”，而非笼统的“测试通过”
- 未勾选 [ ] 表示待办，已勾选 [x] 表示已验证
- 存在未勾选项时绝不合并——要么移除并说明原因，要么先验证
Issue 引用
- 每个 Fixes #N 或 Addresses #N 在 PR 正文中单独成行
- Fixes 在合并时自动关闭；Addresses 不会
- 如果工作针对的问题尚未被跟踪，先创建该 issue
草稿 PR
- 当工作仍在进行中、希望尽早获得 CI 或评审反馈时使用
- 当测试计划所有条目都可勾选时，标记为准备就绪
三、命名一致性
命名链使用相同的类型前缀，并描述同一关注点：
| 制品 | 示例 |
|---|---|
| Issue 标题 | fix: shell startup hangs when config is missing |
| 分支 | fix/42-shell-startup |
| 提交 | fix(shell): prevent startup hang on missing config |
| PR 标题 | fix(shell): prevent startup hang on missing config |
四、生命周期
- 通过 PR 合并关闭 issue（Fixes #N）——除非 issue 被撤回，否则不要手动关闭
- 部分修复：使用 Addresses #N（不自动关闭），并注明剩余工作
- 陈旧 issue：如果修复已发布但未关联，关闭并附上引用该提交或 PR 的评论
- 重新打开的 issue：添加评论说明原修复为何不充分
使用方式
资料中未提供具体的安装或调用方式，暂未提供。
适用场景
- 在 GitHub Issues、Linear 等平台创建 issue 时
- 撰写 PR 描述与测试计划时
- 统一分支、提交、PR 命名时
- 管理 issue 生命周期与关联关系时
限制
资料未提供收费、价格、平台限制等信息，暂未提供。