Skip to main content
Most work already lives in a tracker. Loop intake reads it from there: connect Linear or GitHub once, pick an issue, and its cleaned text becomes the spec, or the requirement the spec is written from. The branch carries the issue key, and the pull request opens with a closing line, so the tracker follows the piece without you retyping anything. This is an Edge preview, off by default. Settings → Edge, then Enable Edge features and, in the “Features” card, Loop intake. See Edge features for what the channel means.

Connect a tracker

Settings → Streams appears once the feature is on. It holds your Stream Sources, the accounts Fermata reads issues from: a Linear workspace through a personal API key, or a GitHub account through the GitHub CLI or a fine-grained token. Keys stay in your Keychain, and nothing in Streams writes to Linear or GitHub. Each project picks which accounts it reads; only those appear in its issue pickers. Connect Linear and GitHub walks through it. To have matching issues come to you instead of picking each one, add a stream.

Three ways in

The empty spec screen with three tiles side by side: Import a spec, From Linear, and From GitHub

Three tiles into a spec: Import a spec, From Linear, From GitHub

  • The empty spec screen. Beside Import a spec, one tile per connected tracker: From Linear and From GitHub. The pick lands in the interview you are already in; see the interview and the spec.
  • The New Piece sheet. Start from Linear issue and Start from GitHub issue, wherever the sheet opens: the Loop board, Home’s quick start, the Pieces hub.
  • The Backlog ”+”. The same two buttons, but the issue parks as a draft instead of starting.
The GitHub button only shows when the project’s origin is on github.com, because a GitHub pick is scoped to that repository. A Linear pick searches the whole workspace. On the New Piece sheet and the Backlog ”+”, a pick only fills the sheet: the title is taken from the issue, and a picked-issue block replaces the description with the key, the title, what the chosen action will do, and a way to remove it. Lane, model, and attachments stay whatever you set. Nothing runs until you press the sheet’s own button.

Pick the issue

The picker is a two-pane sheet: the list on the left, the preview on the right.
The issue picker: a search field on top, a list of open issues on the left with one row carrying a Blocked by 2 badge, and the selected issue's cleaned preview on the right above the Use as requirement and Format and evaluate buttons

Pick an issue: the preview is what the agent reads; ↩ formats it into the spec, ⌥↩ uses it as the requirement

The search field (“Search Linear issues”, “Search GitHub issues”) starts on the most recently updated open issues and filters as you type; done and canceled issues never appear. The keyboard drives the whole thing: ↑/↓ move, ↩ picks with Format and evaluate, ⌥↩ with Use as requirement, Esc cancels. A double-click is Format and evaluate. When more than one account of the same kind is connected, a menu in the header switches between them. Each row shows the issue’s state, title, and key. An issue with open blockers wears a “Blocked by N” badge. The preview on the right is the issue as the agent will read it: the cleaned description and the latest comments. Hidden content in the issue, such as HTML comments or invisible text, is removed before anything reads it, and a disclosure line above the description says what was cut. A long issue is trimmed for display only: “The preview stops here. The agent reads the whole description.” Links in an issue are someone else’s text, so the preview opens web links only. The preview is a window, not a gate; you can pick without reading it.

Two ways to take it

The footer offers two actions, and the difference is who writes the spec.
  • Format and evaluate (↩): the issue becomes the spec, then Format & validate runs. For an issue that is already spec-shaped and just needs the mechanical pass.
  • Use as requirement (⌥↩): the issue is saved as kickoff.md and the spec is written from it. For an issue that says what, not how.
Picking an issue with open blockers raises the picker’s only confirmation, named after what blocks it: “Blocked by SUP-12 (In Progress). Start anyway?” Start anyway proceeds; Fermata does not refuse, it makes sure you saw.

Parked in the Backlog

An issue picked from the Backlog ”+” becomes a draft carrying the issue instead of a description.
A Backlog card on the Loop board showing the issue's title and a small source chip with its key, and no seed text

An issue parked in Backlog: the key chip is all the card shows

Release works like any other draft, with the pick’s action baked in: a Format and evaluate draft writes the spec and runs the pass on release, a Use as requirement draft goes through kickoff.md. The card and its inspector show the source chip, and the piece logs the start with the key (“Started from SUP-12”) when it releases. Drafts, release, and the lanes they land on are covered on the Loop board.

The branch and the pull request

A piece started from an issue keeps the link end to end.
  • The branch carries the key. A Linear key lowercases into the branch slug (sup-142-parser-crash); a GitHub issue contributes its bare number. The key is read from the source link, not the piece name, so it survives the rename at spec approval.
  • The pull request closes the issue. Create PR puts one closing line on the first line of the description: Closes SUP-142, or Closes owner/repo#142 for GitHub. Any other closing reference the generated title or description picked up along the way is removed, so exactly one issue closes and it is the one you started from; the Create PR sheet carries a caption saying both. As everywhere in Fermata, it opens the pull request and you merge.
  • A base check after opening. GitHub only closes an issue when the pull request merges into the repository’s default branch. Once the PR is open, Fermata reads its real base, and when it is not the default, the piece’s activity log warns that the issue will stay open.
The base branch you pick does not decide a piece PR’s target yet: the setting never reaches gh pr create, so the pull request opens against the repository’s default branch unless a gh-merge-base branch config says otherwise. The base check above tells you when that mismatch will keep the issue open. This is a known gap.