Planning a feature as Linear subtickets

Planning a feature as Linear subtickets

One idea: the planning session is where the expensive thinking happens, and it evaporates when the session ends. Write it into subtickets while you plan, one subticket per PR you intend to open, so the implementation can be handed to any agent — a cloud agent, a colleague, a session next month — and nothing is lost.

This skill owns the Linear half: whether to plan at all, and what a subticket must contain. It does not own the PR mechanics.

• Where to cut the slices, the stack rules, and how to verify each branch are pr-stack-workflow. Read it for the slicing; this file does not restate it.
• What an agent may write to Linear and how it must be marked is linear-agent-writes. Read it before your first write.
• Reconstructing history before you plan, and the handover after you ship, are linear-context-handover.

Step 0 — reconstruct before you slice

Run the context CLI on the files you are about to change, then read what it finds: linear-context-handover → reconstruct its history. Half the design questions have already been answered somewhere in that chain, and a decision that was already reversed once does not need proposing again.

Does it need a plan at all?

The discriminator is in pr-stack-workflow → Decide whether it needs a stack: one sentence without an "and", a default or persisted shape that needs a migration decision, a shared component, a click-path verification. Use that table; it is the same question.

Two consequences for the tracker specifically:

• If the fix is one commit, the ticket already is the plan. Do not manufacture subtickets for it. Hand the ticket to an agent as the whole brief.