For your role
You are not short of tickets. You are short of tickets someone can start without a follow-up conversation, and the follow-up is nearly always about something the ticket left out rather than something it got wrong. Spectr drafts against your actual repos, docs and designs, so what reaches your board describes the system that exists. Once stories are approved, a developer can start a coding agent on them from Spectr.
How it works
A call is imported from a note-taker (Fathom, Granola, Read.ai, or Fireflies.ai). Spectr picks out a requirement, a bug, an action item and an out-of-scope ask, reads GitHub, Figma, and Notion for context, and drafts a story and a bug with acceptance criteria. A person approves both, they are published to the team's tracker (Jira, Linear, or Shortcut), and the requirements, scope log and project memory update from the same call.
Then build it
Two approved stories become one workstream on the Development board. The developer starts a Conductor run from it: their own Conductor account, the repository matched to the project's GitHub repo, and the stories to send. Spectr shows the exact message and sends it only on confirm. The workstream moves to In Progress and the run's state shows on its card. The run uses the developer's Conductor compute, not the workspace's Spectr AI allowance.
How the Conductor integration works →
A one-line ticket with no acceptance criteria costs nothing to write. Inside the team it becomes a Slack thread, a guess, a half-built feature and a re-open. Across a sprint, a real share of engineering time goes on reconstructing intent that was perfectly clear in a meeting three weeks ago.
Your team of six. Refinement is Wednesday. Eighteen items in the queue.
Before
Refinement runs an hour and a half because half the items need scoping in the room. Two get pushed for lack of detail.
Wednesday 10am
Now: the eighteen items already have acceptance criteria and estimates, written against your three repos.
10:04am
One estimate is higher than expected. It is correct - the change touches a queue consumer nobody in the room had thought of, which Spectr found in the code.
10:11am
Two items were flagged as probable duplicates before they got here. One was real and is already linked to the original.
10:32am
Refinement is done. Four items get their criteria tightened; nothing gets pushed for lack of detail.
Friday
Three stories are marked done in Jira. One status refresh brings that into Spectr, so nobody updates a second system for the delivery report.
Ninety minutes of refinement has turned into about thirty - with one wrong estimate caught before it was committed to, and one duplicate that never became work at all.
Pin up to five GitHub repos and Spectr searches for the code a discussion concerns, reading those files rather than skimming. Open issues come in too, so a story can point at work already in flight. Acceptance criteria and estimates end up anchored in what the change would really touch.
Every finished spec sheet is checked against the whole project for probable repeats. A flag can be promoted to a confirmed duplicate, which links the two permanently. That is how your backlog stops collecting the same work under three phrasings from three different meetings.
Several stories from one requirement publish as a parent with real sub-tasks instead of unrelated siblings. Descriptions keep their structure: markdown is converted to Jira wiki markup on the way in, so a heading renders as a heading rather than as raw syntax. Invisible when it works, infuriating when it does not.
A status refresh reads each published issue's state back from Jira, Linear and Shortcut: done, in progress, or cancelled as its own outcome. Nobody has to keep a second system up to date for the delivery numbers to be right.
Approved stories go into a workstream on the Development board. A developer starts a Conductor run from it on their own account: Spectr builds one message from the stories, with their acceptance criteria, links and Figma screens, shows it in full, and sends it only when they confirm. The run's state shows on the workstream's card, and it uses none of the workspace's Spectr AI allowance.
Connect Cursor, Codex or Claude Code to Spectr's MCP server and the agent reads the story it is implementing, with its acceptance criteria and the spec sheet behind it, as you and within your role.
Anything else? Email hello@crowdlinker.com and a person will answer.
Not itself. GitHub access is read-only: no pushes, no pull requests, no comments. Code is written by a coding agent a developer starts from a workstream, on their own Conductor account, in its own branch.
Spectr proposes one and anyone can change it at review or afterwards - an edit in Spectr syncs to the ticket. It is a starting point, not an authority.
No. Sentry is read-only evidence that gets quoted, with a date, in the specs Spectr writes. Whether an error becomes a ticket is still someone's decision.
It writes from the repos you pinned and lists which files it read, so you can check. That is a large part of why pinning the right repos is worth the five minutes.
Fathom
Granola
Read.ai
Fireflies.ai
acme/web
Pricing page
Billing PRD
Jira
Linear
Shortcut
