Linear + deariary: your sprint, your diary

#integration #guide #linear

You closed three issues this sprint, left eleven comments, and wrote one project update where you marked the health as “at risk.” A week from now you will remember none of it. You will remember “the sprint where the encryption migration ate everything,” but you will not remember which ticket you closed first, what you decided in the DEA-155 thread, or why you flipped that health indicator.

Linear remembers. The identifiers are still there, the comments are still threaded, the project updates are still archived. But Linear is built for the work in front of you, not for looking back. Six months from now you will not page through DEA-141, DEA-142, DEA-143 trying to reconstruct a Tuesday.

deariary reads your Linear activity each morning and weaves it into your diary entry. The issue identifiers become anchors. The comments you wrote (the richest signal of all) become quoted decisions and recorded frustrations. The project updates become a first-person narrative of the week. The sprint becomes something you can read.

How the connection works

Linear uses OAuth 2.0 with a read scope. You authorize deariary from inside Linear, and deariary stores the resulting access token encrypted. The token grants read-only access to your workspace through Linear’s GraphQL API. deariary cannot create issues, post comments, change states, or modify anything in your workspace.

After you authorize, a team picker appears in your settings. Linear is organized around teams, and most workspaces have several. You select which teams you want included in your diary. Anything from teams you do not pick is ignored. If you do not select any teams, the fetcher does not run.

You can revoke access at any time from your deariary settings or from Linear’s authorized applications page.

What deariary collects from Linear

Each morning, deariary queries Linear for your activity over the previous day. The result is grouped into five buckets.

Issues completed

Issues that reached a completed or canceled state in the window. Each completed issue carries:

Identifier (e.g., DEA-142) and title
Description, truncated to 400 characters
State (the workspace-configured display name like “Done” or “Shipped”) and stateType (completed or canceled)
Priority label (Urgent, High, Medium, Low, or No priority)
Team and project, if assigned
Labels (free-form tags like bug, tech-debt, security)
Assignee and creator
Estimate (story points, if set)
Created, started, and completed timestamps, converted to your local timezone
URL back to the issue in Linear

A canceled issue is different signal from a completed one. The diary reflects that: “wrapped up” and “shipped” for completion, “dropped” or “won’t-do” for cancellation. The work that did not happen is part of your week too.

Issues created

New issues you filed during the day. These represent intent, not accomplishment. The diary treats them as “you flagged X today” rather than “you finished X.”

Issues in progress

Issues you touched (commented on, reassigned, moved between states) but did not create or close in the window. The diary frames these as “still chipping away” rather than achievements.

Comments

Every comment you wrote, on your own issues and on teammates’ issues. Each comment includes:

The issue identifier, title, and URL for context
Your comment body, truncated to 600 characters
Created timestamp in your local timezone
A direct URL to the comment

Comments are the richest signal Linear provides. A closed issue tells you what shipped. A comment tells you what you decided, what you pushed back on, what you proposed instead. The LLM is instructed to quote or paraphrase comments directly when they capture a decision, a frustration, or an insight. This is where your voice ends up in the diary.

Project updates

Status writeups you posted at the project level. Each carries:

The project name
A health self-assessment (onTrack, atRisk, or offTrack)
The update body, truncated to 1,000 characters
Created timestamp

Project updates are leaned on heavily when present, because they are already first-person narrative. You wrote “this week we shipped the retry logic, next week we start on the Calendar fetcher” yourself. The diary uses your phrasing rather than rewriting it.

Highlight cards

At the end of collection, deariary generates highlight cards: the count of issues you completed, grouped by team. Each card links back to Linear so you can revisit the original tickets from the diary entry.

What deariary does NOT collect

No teammates’ issues you did not touch. Only issues you assigned, created, were subscribed to, or commented on are read.
No teammates’ comments. Only comments authored by you. Discussion threads are filtered to your contributions.
No issue history or audit log. State changes, reassignments, and field edits beyond the current snapshot are not collected.
No reactions or emoji. Thumbs-ups and other reactions on issues and comments are not read.
No initiatives, documents, or pages. Linear’s longer-form content surfaces (Initiatives, Documents, Project Overview) are not accessed.
No views, filters, or saved searches. Your custom views and triage layouts remain private.
No write access. deariary can read your activity and nothing else. It cannot create issues, post comments, change priorities, or modify anything.

From issue identifiers to a readable sprint

Here is what the transformation looks like. Say you had a Friday with two completed issues, one new issue filed, three comments, and a project update.

Linear’s data, simplified, looks something like this:

Completed:
  DEA-142 "Implement retry logic for sync failures" (project: ETL Pipeline, priority: High)
  DEA-138 "Add OAuth token expiry warning email" (project: Notifications)

Created:
  DEA-163 "Handle partial extraction failures gracefully" (project: ETL Pipeline)

Comments:
  DEA-155: "Going with the LaunchDarkly flag. Drop the CBC code path once every connection is re-encrypted."
  DEA-163: "Promise.allSettled per Extract task. Failed sources skip to Transform."
  DEA-160: "Google's OAuth token expires in 1 hour. Need proactive refresh first, then the fetcher."

Project update (ETL Pipeline, health: onTrack):
  "This week: shipped retry logic (DEA-142), started design on partial-failure handling (DEA-163).
   Next week: start the Google Calendar fetcher, pair it with proactive token refresh."

deariary hands this to the LLM alongside any other integration data for that day. The result reads like:

Friday closed out the reliability thread you had been pulling on all week. You shipped the retry logic for sync failures (DEA-142) and the OAuth expiry warning email (DEA-138), then opened DEA-163 to handle partial extraction failures (your note: “Promise.allSettled per Extract task. Failed sources skip to Transform”). On the credential migration, you locked in the LaunchDarkly flag approach, with a plan to drop the CBC code path once every connection is re-encrypted. The project update you posted for ETL Pipeline marked the week as on track: retry logic shipped, partial-failure design started, Google Calendar fetcher next.

Three artifacts (closed issues, comments, project update) became a paragraph that reconstructs the engineering decisions you made that day. The identifiers are anchors you can click back through. The comments are quoted in your own words. The project update sets the frame.

Why comments matter more than completions

Most issue trackers, including Linear, treat closing a ticket as the headline event. But the closed ticket is the artifact of the work, not the work itself. The work is in the discussion: the moment you proposed an approach and someone pushed back, the moment you realized the migration needed a flag, the moment you decided to defer something until next sprint.

Comments capture all of that. And unlike a meeting where the decision evaporates after everyone leaves the room, a Linear comment is a written, timestamped, threaded record of what you thought at that moment.

deariary’s LLM is instructed to lean on comments hard. When a comment captures a decision (“going with the LaunchDarkly flag”), the diary quotes it. When a comment captures a frustration (“the Linear API filter doesn’t expose isMe, so we have to go through viewer.assignedIssues”), the diary preserves it. When a comment captures an insight, the diary keeps it intact.

Six months from now, the closed ticket will tell you what shipped. The comment will tell you why you chose that path.

Project updates as first-person narrative

Project updates are unusual among integration data because they are already prose. You sat down at the end of the week, looked at what your project did, and wrote a paragraph about it. The health indicator (on track, at risk, off track) is your own assessment of how the project is going.

When you post a project update, the diary leans on it as the spine of that day’s entry. The closed issues become supporting detail, the comments become quoted moments, but the project update is the first-person voice that ties the work together. You already did the writing. deariary just makes sure your weekly summary lives in your diary, not just in Linear.

Cancelled tickets are part of the story too

Most task trackers treat cancellation as cleanup: a ticket gets closed without shipping, and the data point disappears. deariary keeps cancelled issues in the picture, but treats them differently from completed ones.

A completed issue gets framed as accomplishment. A cancelled issue gets framed as a decision: you dropped this, you scoped it out, you decided it was not worth doing. That decision is part of how your sprint actually went. Some of the most informative diary entries are the ones where the headline is “you dropped three tickets this week.” That is a sprint where the team changed direction, and the diary remembers it.

Linear alone vs. with other integrations

A Linear-only diary captures what you shipped, what you flagged, and what you discussed. For an engineer, this is a lot. The combination of issue identifiers and your own comments is enough to reconstruct most workdays.

Add other integrations and the engineering picture expands:

Linear only:

You closed DEA-142 (retry logic) and DEA-138 (token expiry warning), opened DEA-163 for partial extraction failures, and posted the weekly ETL Pipeline update. Health: on track.

Linear + GitHub + Slack:

You closed the retry logic ticket (DEA-142) after merging the PR you opened Wednesday (340 lines, three reviewers approved overnight). The OAuth expiry warning ticket (DEA-138) followed: a smaller change, but the email template took longer than the logic. In the engineering channel you talked through the LaunchDarkly approach for the encryption migration with Kenji before posting the decision in the DEA-155 thread. By 5pm you had the weekly ETL Pipeline update written and marked on-track, with the Google Calendar fetcher queued for Monday.

The first reads like a sprint summary. The second reads like a workday with the connective tissue intact: the GitHub PR behind the closed ticket, the Slack thread before the comment, the timing of when the project update went out. The diary stops being a list of artifacts and becomes a record of how the day actually moved.

On the Free plan you can connect one integration, which is enough to try Linear on its own. Upgrading to Basic (up to 5 integrations) lets you layer Linear with GitHub, Slack, your calendar, and your time tracker. See pricing on deariary.com for details.

When the sprint goes quiet

Some days you do not touch Linear. You were heads-down in code, deep in a meeting, or just thinking. The board does not move. No comments, no closed tickets, no project update.

On those days, deariary has no Linear data to include. Other connected integrations carry the day instead: GitHub records the commits, Slack records the discussions, the calendar records the meetings. The sprint resumes the next time you write a comment or close a ticket.

Quiet weeks in Linear are often the most informative ones to look back on. They mark the gap between when a problem was framed and when it was solved, the design week before the implementation week, the planning days that made the shipping days possible. The diary records that gap honestly, without inventing activity that did not happen.

Setting it up

Connecting Linear to deariary takes about a minute:

Go to app.deariary.com
Open Settings and find the Integrations section
Click Linear and authorize read-only access to your workspace
Pick the teams you want included from the team picker

The next morning, your Linear activity from the previous day appears in your diary entry.

You can change which teams are synced at any time, or disconnect Linear entirely. Disconnecting revokes the OAuth token and deariary discards it.

What surprised us

We have been running deariary with Linear connected since the integration shipped. Three things stood out.

Comments age better than issue titles. A closed ticket titled “Implement retry logic for sync failures” tells you what shipped. The comment you left explaining why you chose exponential backoff over a fixed delay tells you why. Six months later, the title is forgettable. The comment is the part you actually want to read back.

Project updates are diary entries that already exist. Once a week, you write a paragraph about your project’s state. That paragraph belongs in your diary, not just in Linear’s project view. Connecting Linear means the writing you do for your team becomes the writing you do for yourself, automatically.

Cancelled tickets tell you about the team’s judgment. A sprint where two tickets shipped and three got cancelled is not a failed sprint. It is a sprint where the team got better at saying no. The diary’s framing of cancellations as decisions rather than failures changed how we read our own weeks.

Your Linear workspace already records what you build, what you discuss, and what you decide. deariary turns that record into a diary that preserves the sprint, not just the artifacts of it. The identifiers become anchors, the comments become your voice, and the week becomes something worth re-reading after the next ten sprints have happened.

Connect Linear to deariary