用途：在使用 Graphite CLI（gt）管理分支和 PR 时提供操作规范，覆盖创建堆叠 PR、修改栈中分支、提交、同步与解决冲突。
核心原则：不要提交到 main，所有提交必须在功能分支上；除非被明确要求，否则不创建新分支；不要使用原生 git rebase，始终用 gt 命令以保留栈元数据；提交时始终将 Claude 设为共同作者。
分支策略：制定计划时列出每个工作单元对应的预期分支；超过 500 LOC 的工作应拆分为多个分支并相互堆叠；按逻辑顺序堆叠分支，每个分支包含独立功能；每个分支都必须能通过全部 lint、检查和测试。
提交代码：用 git 命令手动暂存受影响文件，不要用 -a 自动暂存全部改动；新功能用 gt modify --commit -m "description of the change" 创建提交；修改已有功能或修复缺陷用 gt modify 修订提交。
提交变更：任务完成时始终执行 gt restack，并确认受影响的上层分支仍然有效（lint 检查通过）；任务完成时使用 gt submit --stack --update-only；若改动重大，先阅读现有 PR 描述并融入改动，不要覆盖丢失重要上下文；向用户展示 PR 描述改动以获得批准。
创建 PR：仅在用户明确同意后提交新 PR；用 gt submit --draft 创建，新 PR 一律以草稿提交；提交后用 gh 工具创建详细 PR 描述；提交 PR 描述前先征求用户批准。
处理冲突：在 gt sync、gt restack 或 gt modify 出现冲突时，解决受影响文件中的冲突，用 git add <files> 暂存已解决文件，然后执行 gt continue 或 gt continue --all。
更新栈中分支的流程：gt checkout <target-branch>，进行编辑，gt modify -a（修订并重新堆叠上层），gt submit --stack --update-only --no-interactive（推送所有已更新分支）。
常见陷阱：不要用 git rebase -i，会破坏 Graphite 元数据，改用 gt move；不要用 git branch -d，改用 gt delete 以保留元数据；不要用 git commit --amend，改用 gt modify -a，它还会重新堆叠；gt rename 会破坏 PR 链接，避免重命名已有 PR 的分支；squash 合并会导致级联冲突，用 gt sync 加 gt restack 解决。