# 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 [#where-you-can-push]

<Cards>
  <Card title="Linear">
    Project, issues and sub-issues nested to any depth, with dependencies as issue relations.
  </Card>

  <Card title="Jira">
    Epic and issues on your Jira site, with the Spec tree mapped to issue hierarchy.
  </Card>

  <Card title="Radial">
    Issues and sub-issues in your Radial workspace.
  </Card>
</Cards>

Connect one in **Settings → Connectors**. Connections are per person: the push happens as you, and
the issues are created by you.

<Callout>
  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](/docs/connecting-a-repository).
</Callout>

## What lands [#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 [#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 [#what-happens-when-someone-else-edited-it]

<Callout type="info">
  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.
</Callout>

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 [#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](/docs/import-from-your-issue-tracker).

## No issue tracker yet [#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.