Summary
A lot of what we ship isn't tied to a Linear issue (refactors, chores, dependency bumps, small fixes). We'd love releases to natively list the individual commits/PRs that make up a release as they accumulate into an in-progress ("Started") release, and for those commits to be available as source material for the "Write Release Notes with Agent" feature, not only the linked issues.
Context / use case
We track releases via the CLI / GitHub Action across continuous (web) and scheduled (mobile/desktop) pipelines. A release accumulates commits over a train, and a meaningful fraction of those commits have no associated Linear issue. Today that work is essentially invisible on the release: only issue-referencing commits surface, and the release itself natively stores a single commit SHA.
Current workaround and its limitations
To make issue-less work visible we currently:
- attach each commit's PR/commit body as a release document, and
- add a per-commit GitHub commit link.
This works but is clearly a workaround:
- Documents and links are auxiliary attachments, not a first-class "what commits are in this release" list.
- They don't feed the Agent. "Write Release Notes with Agent" only draws on linked issues, so any AI-written notes silently omit everything that isn't ticketed.
- It's manual CI plumbing to format titles and links, and it doesn't reflect the actual commit range the way a native list could.
Request
- Natively associate and display a release's commits/PRs.
sync already scans the commit range, so the data is in hand. Surface that set in the release UI as a commit/PR list (subject, SHA, author, link), accumulating as a "Started" release grows.
- Feed those commits into "Write Release Notes with Agent" as source material alongside linked issues, so releases with little or no issue coverage still produce useful notes.
- Expose it on the access-key-scoped path so CI and integrations using a pipeline access key (not a personal API key) benefit, the same as
sync.
Why this matters
A large share of real, user-relevant change lands without a Linear issue. Surfacing commits natively closes that gap, removes our document/link workaround, and lets the Agent's notes reflect everything that actually shipped rather than only the ticketed subset.
Related: #67 (closed) asked for a description/body input to enrich notes; this is the more native, commit-centric version of that need, plus the Agent integration.
Summary
A lot of what we ship isn't tied to a Linear issue (refactors, chores, dependency bumps, small fixes). We'd love releases to natively list the individual commits/PRs that make up a release as they accumulate into an in-progress ("Started") release, and for those commits to be available as source material for the "Write Release Notes with Agent" feature, not only the linked issues.
Context / use case
We track releases via the CLI / GitHub Action across continuous (web) and scheduled (mobile/desktop) pipelines. A release accumulates commits over a train, and a meaningful fraction of those commits have no associated Linear issue. Today that work is essentially invisible on the release: only issue-referencing commits surface, and the release itself natively stores a single commit SHA.
Current workaround and its limitations
To make issue-less work visible we currently:
This works but is clearly a workaround:
Request
syncalready scans the commit range, so the data is in hand. Surface that set in the release UI as a commit/PR list (subject, SHA, author, link), accumulating as a "Started" release grows.sync.Why this matters
A large share of real, user-relevant change lands without a Linear issue. Surfacing commits natively closes that gap, removes our document/link workaround, and lets the Agent's notes reflect everything that actually shipped rather than only the ticketed subset.
Related: #67 (closed) asked for a description/body input to enrich notes; this is the more native, commit-centric version of that need, plus the Agent integration.