用途：planning-pr 是提交位置顾问，不属于常规 ln-* 执行路径，只回答「规划文档的修改应该提交到哪里」。
主要能力：根据改动类型给出放置建议。默认留在当前功能分支的情况包括：单行状态勾选或错别字修复、标记当前前沿项完成、日常 ln-build / ln-scope 规范化协调、解释当前代码改动的小幅 SPEC/PLAN 编辑、不影响其他活跃分支的本地规划编辑。建议拆分独立规划 PR 的情况包括：用户明确要求规划 PR、多个活跃分支已在 memory/SPEC.md 或 memory/PLAN.md 上冲突、ln-sync 或规划流程重写共享叙述段/重排前沿项/迁移大段历史、SPEC 受跟踪行（A##、D###、Requirement N、I###）的编辑可能与其他分支新增相邻 ID 冲突、该编辑确立多个实现分支需先 rebase 的规划基线。
使用方式：该技能只建议不自动创建。推荐措辞为：这看起来是规划 PR 候选，原因是……，你是想拆到基于 main 的独立规划分支，还是留在当前功能分支？创建 issue、分支、提交或 PR 前必须先征得用户同意。经批准后才执行工作流：先读取 docs/praxis/graphite-workflow.md，用 /cli-linear 在 Frontend（FE）团队 brunch 项目建 Linear issue；用 /cli-graphite 从 main 建分支，按项目分支约定命名；只把规划文件（通常为 memory/PLAN.md、memory/SPEC.md 及归档/历史文件）移入该分支，不带代码、测试、配置或无关文档；提交前运行 npm run verify，除非用户明确接受更轻量检查；PR 标题为 FE-XXX: <句首大写的规划框架>，PR 正文声明这是下游分支的规划基线/序列化点；合并后将下游功能分支 restack 到新的 main 基线。
适用场景：规划文档成为多分支共享序列化点时。
限制与反模式：不要把它当作每次 memory/* 编辑的强制门槛；未经用户批准不得创建 Linear issue 或分支；不要把代码改动混入规划 PR；不要把微小状态更新从产生它的功能分支拆走；当目标是共享基线时，不要把规划 PR 叠在实现分支之上。ln-spec、ln-plan、ln-sync、ln-scope、ln-build 决定规划文档写什么，planning-pr 只建议实质性规划编辑应提交到哪里。