Planning Pr

Planning PR

This is a commit-placement advisor, not part of the normal ln-* execution path.

Most memory/SPEC.md and memory/PLAN.md edits stay on the active feature branch. A separate planning PR is useful only when planning docs become a shared serialization point for multiple branches.

Default stance

Stay on the current feature branch for:

• one-line status ticks or typo fixes
• marking the active frontier item done
• routine ln-build / ln-scope canonical reconciliation
• small SPEC/PLAN edits needed to explain the current code change
• local planning edits that do not affect other active branches

Do not invoke Linear, Graphite, or branch creation just because a planning file is touched.

When to recommend a planning PR

Recommend, but do not create, a separate planning PR when one or more is true:

• the user explicitly asks for a planning PR or asks where planning edits should land
• active branches are already conflicting on memory/SPEC.md or memory/PLAN.md
• an ln-sync or planning pass rewrites shared narrative sections, reorders frontier items, or rotates substantial history
• edits to SPEC tracked rows (A##, D###, Requirement N, I###) are likely to collide with other active branches adding adjacent IDs
• the edit establishes a planning baseline that several implementation branches should rebase onto before continuing

Phrase it as a recommendation:

This looks like a planning-PR candidate because [reason].
Do you want me to split it onto a separate planning branch off main, or keep it on the current feature branch?

Ask before creating issues, branches, commits, or PRs.

Decision table

When uncertain, ask. Do not silently escalate to process work.

Planning PR workflow

Only after user approval:

1. Create a Linear issue in the Frontend (FE) team and brunch project via /cli-linear. Title frames the planning intent, not a feature. No parent unless explicitly named.
2. Create a Graphite branch off main via /cli-graphite after reading docs/praxis/graphite-workflow.md. Name it using the project branch convention.
3. Move only planning files onto the branch: normally memory/PLAN.md, memory/SPEC.md, and related archive/history files. No code, tests, config, or unrelated docs.
4. Run npm run verify before submission unless the user explicitly accepts a lighter check.
5. Submit a PR titled FE-XXX: <Sentence-case planning frame>.
6. State in the PR body that this is a planning baseline / serialization point for downstream branches.
7. After merge, restack downstream feature branches onto the new main baseline.

Anti-patterns

• Treating this skill as a mandatory gate for every memory/* edit.
• Creating Linear issues or branches without explicit user approval.
• Bundling code changes into a planning PR.
• Splitting tiny status updates away from the feature branch that produced them.
• Stacking a planning PR on top of an implementation branch when the goal is a shared baseline.

Relationship to other skills

• ln-spec, ln-plan, ln-sync, ln-scope, and ln-build decide what the planning docs should say.
• planning-pr only advises where substantive planning edits should be committed.
• /cli-linear and /cli-graphite perform the tracker/branch work after the user approves the split.