Issue trackers

Publish approved user stories straight into Jira Cloud

Spectr drafts the stories. Jira is where the approved ones go. Connect a Jira Cloud site, pick the project they land in, and every story you approve becomes a real Jira issue with its description, acceptance criteria, type, priority, labels, estimate and assignee already set. Spectr then reads each issue's status back, so what it thinks has shipped matches what actually has.

How it connects

OAuth 2.0 (3LO). You pick the Jira site on Atlassian's own consent screen. Spectr requests read and write access to Jira work plus read access to users, and refreshes the token itself.

Before you start

No plan requirement. Connections are configured per project, and every credential is encrypted at rest.

What Spectr reads from Jira

Projects, issue types and statuses: Read once at setup so you can choose where issues land and, optionally, which issue type and starting status they use. Statuses are workflow-scoped, so changing the project or issue type clears the dependent choice rather than leaving a stale one.
Completion status of published issues: A batched JQL read maps each issue's status category onto the story in Spectr. A story is only "done" when every tracker it was published to says so, and that feeds the budget projection. An issue deleted in Jira is skipped rather than overwriting what Spectr already knows.
Assignable users: The selected project's assignable-user list syncs into the project team, so a story's assignee can be a real person rather than a name typed twice.

What Spectr writes to Jira

Issues, only after approval: Nothing reaches Jira until a person approves it in Spectr's review step. Descriptions and acceptance criteria are converted from markdown to Jira wiki markup on the way in, so headings and lists render as headings and lists instead of raw syntax.
Type, priority, labels and estimates: Feature maps to Story, bug to Bug, chore and spike to Task - resolved against the project's real issue types. Priority maps by name against your instance's own priority scheme. Labels are slugified because Jira rejects spaces in them. Estimates use your site's story-points field when it exists.
Parent and sub-task nesting: When a spec-sheet task generates several stories, Spectr creates one parent issue and nests the rest as real Jira sub-tasks. If the project has no sub-task type, it publishes flat rather than failing.

A person approves everything before it is published

Spectr generates specs and stories, then stops. Every story goes to a review page where you approve it, edit it inline, or reject it - individually or in bulk. Only approved stories reach an issue tracker. There is no auto-publish setting to switch on, because a backlog nobody read is not a saving.

Setting it up

In Spectr, open the project and go to Integrations.
Choose Jira and click Connect. Atlassian asks which site to authorise.
Pick the Jira project new issues should land in.
Optionally set Story defaults - a default issue type and the status new issues should start in.
Generate stories from a meeting, review them, and publish. Approved stories appear in Jira with a link back to Spectr.

Frequently asked questions

Can Spectr create Jira issues without me reviewing them first?

No, and that is deliberate. Every story passes through a human review step - approve, edit inline, or reject - before it can be published. There is no auto-publish path.

Does Spectr support Jira Server or Data Center?

No. The integration is Jira Cloud only, over Atlassian's OAuth 2.0 (3LO) flow.

Why do my labels come back with hyphens?

Jira rejects labels containing spaces, so "Auth Flow" is published as "Auth-Flow". Spectr deliberately does not sync labels back from Jira, because un-slugifying them would guess at your data and sometimes guess wrong.

What happens to a story if someone moves or renames the issue in Jira?

Spectr stores Jira's stable numeric id alongside the human key, so a rename or a project move does not break the link. The key and browse URL are backfilled on the next status refresh.

Use case