Push to your issue tracker
Send the plan to Linear, Jira or Radial, with its hierarchy and dependencies intact.
When a plan is good, push it. Your team keeps working where they already work, and the plan becomes issues they can pick up.
Where you can push
Linear
Project, issues and sub-issues nested to any depth, with dependencies as issue relations.
Jira
Epic and issues on your Jira site, with the Spec tree mapped to issue hierarchy.
Radial
Issues and sub-issues in your Radial workspace.
Connect one in Settings → Connectors. Connections are per person: the push happens as you, and the issues are created by you.
GitHub, GitLab and Bitbucket are code connectors, not push destinations. Plansmith reads them to ground your Specs; nothing is ever written back to them. See Connecting a repository.
What lands
Each Spec becomes an issue. The tree becomes issue hierarchy, "needs first" becomes issue relations, and effort becomes an estimate where the issue tracker has one.
The acceptance criteria go into the issue body as a checklist, which is the part that matters: the person who picks the issue up gets the definition of done without opening Plansmith.
Re-pushing updates the same issues
Pushing again updates the items Plansmith created rather than making new ones. Anything your team creates independently in the issue tracker is untouched.
Plansmith is the place the plan gets written, so the habit that works best is still to change the plan here and push it, rather than editing a pushed issue's description in the issue tracker and expecting Plansmith to pick that up. But an edit made over there is no longer lost silently. See below.
What happens when someone else edited it
Available on Jira today. Reading an issue back is what makes this possible, and Jira is the one issue tracker Plansmith can currently read as well as write. Pushes to Linear and radial.build still overwrite, as described above.
Before Plansmith writes anything, it checks what changed in your issue tracker since the two sides last agreed. Most of the time nothing has, and the push goes straight through.
If somebody edited an issue you had pushed or imported, the push stops before writing and the agent walks you through it. For each one it shows what they changed and what you changed since the last agreed version, and you decide: keep both, keep theirs, keep yours. What you decide becomes an ordinary edit to the spec, so you can read it in the plan before anything leaves Plansmith. When every item is settled, one button sends the lot.
Three things worth knowing:
- A status change is not a conflict. Someone moving your issue to In Progress will not stop a push. Only an edit to the words will.
- Nothing lands half-done. The push stops before it writes, so there is no partial update to undo, and nothing of your teammate's is lost while you decide.
- A deleted issue is not recreated silently. If an issue you pushed has been deleted in the issue tracker, Plansmith asks what you want rather than quietly making a duplicate.
If the issue tracker cannot be reached, the push also stops. "We could not check" is not the same as "nothing changed", and guessing wrong there costs somebody their work.
Work that is already in Jira
You do not have to start it over here. Bring the epic into a plan, refine it, and push it back to the same issues. See Import from your issue tracker.
No issue tracker yet
You can export the plan instead and connect an issue tracker whenever you like. Nothing about writing a plan depends on the connection, and the export carries the same Specs and acceptance criteria.