Engineering Daily Sync

At a glance

As an engineering lead, the user switches between GitHub, Linear, email, and a stack of project docs all day. By day they handle requirements, technical specs, and the incident that just landed. By night they catch up on what the team shipped today, where the project stands, what new Issues came in, and which PRs are waiting on review.

These tasks aren't hard. They're just tedious. And they get interrupted by more urgent work — the daily report doesn't get written, GitHub Issues don't get synced to Linear, important PRs get buried in notifications, and by the time the lead notices, the problem has been sitting for a day or two.

The user doesn't want another chatbot that waits for them to ask it something. They want an AI assistant that genuinely fits into the engineering workflow: it watches the project's progress continuously, handles the information organization and system syncing on its own, and only finds them when there's something they need to judge.

Problem 1: Re-organizing the same dev progress every day

When the lead wants to know what the team shipped today, they used to open GitHub first:

• Pull the day's commits
• Judge which feature each commit belongs to
• Find which core modules were touched
• Check whether there's any risk or leftover concern
• Then stitch it all into a daily report

If the day is busy, this gets pushed to the next day. Sometimes the lead skips several days running and ends up reconstructing from memory and scattered chat history.

The realization: this kind of work is exactly what AI should be doing. The actual time sink isn't the technical judgement — it's collecting scattered records and reorganizing them into something a human can read.

To make this routine disappear, the lead sets up a scheduled scenario in OpenLoomi — see the next section.

In OpenLoomi: A scheduled daily report

PD Daily Sync is the first scenario the lead creates. Every night at 10 PM, OpenLoomi automatically pulls the day's commits, identifies the major code changes, and generates a structured engineering report. It helps answer the most basic but also most important questions:

• What did the team actually move forward today?
• Which modules changed?
• What issues or risks came up?
• What's still pending follow-up?

A few minutes later, two artifacts land — ready to read, share, or archive:

• The daily engineering report
• The issue sync summary

After the report is generated, it also gets sent to the team email automatically. There's no longer a need to remind anyone to fill in their daily report, and no need to scroll through commits manually. Before the next workday starts, the team already has a structured, complete progress record waiting.

The lead wires up the daily digest as a runnable task in OpenLoomi Desktop — PD Daily Track, instruction Output what OpenLoomi released today and send it to my email., Plan = Daily at 21:00. Execution history records every run, so any drift shows up immediately.

When the run finishes, OpenLoomi writes the markdown brief and renders it right next to the task. The lead can scan the Overview, Highlights, and the commit list in one pass:

The same brief is dispatched to the team inbox a moment later. No separate reminder, no manual copy-paste — Loomi sends through the Gmail connector, so the message lands under the team's own account with the same Highlights and commit list rendered into the body. The next workday starts with a structured, complete progress record waiting:

Problem 2: GitHub Issues and Linear are always out of sync

The codebase uses GitHub for code and technical issues, and Linear for task scheduling and sprint management. In theory, each system has its own job.

In practice, there's a clear gap between them. When a new Issue lands in GitHub, someone has to manually copy it into Linear. This isn't just an extra copy-paste — the bigger problem is that context gets lost in transit:

• Which PRs and commits are linked to this Issue?
• What has the comment thread already discussed?
• How do you reproduce the bug?
• Which project does it belong to?
• What priority should it have?

If only the title and body get copied, the Linear ticket becomes a "task shell" without background. The next person who picks it up still has to go back to GitHub to understand what was reported.

A continuous sync in OpenLoomi addresses all of this — see the next section.

In OpenLoomi: A scheduled issue sync

PD Issue Sync is the scenario that handles this. It runs every hour, continuously checking for new GitHub Issues from the day. But it doesn't just copy content — it understands the issue and adds context first, then writes to Linear.

A few guardrails keep the sync from drifting off:

• Source-URL dedup — when Loop sees an issue whose source URL already maps to a Linear ticket, it updates the existing ticket in place instead of creating a duplicate. The next morning, Linear stays one-to-one with GitHub.
• Per-repo overrides — different repositories can map labels, milestones, and project fields onto Linear's priority / project fields their own way. New labels still need explicit approval before they're created.
• Tracked every run — each sync cycle records which repos were processed, which issues were enriched, and which were already up to date. Any drift between the two systems shows up in the next day's Tracking panel, not in the user's inbox.

The sync is wired up the same way as the daily digest — Issues Sync lives in OpenLoomi Desktop with the instruction Sync melandlabs/openloomi github issues to linear, Plan = Daily at 21:00, plus the hourly cron Loomi runs against fresh issues. Execution history records every pass.

When the cycle finishes, Linear stops looking like a task shell. GitHub on the left, Linear on the right — every ticket already tagged with the originating [GH #xxx] reference, and the Linked PR / comments / repro context Loomi pre-threaded. The lead can prioritize and assign straight from Linear:

Problem 3: PRs are found at the wrong time

One thing in particular keeps breaking focus: PR review. Keeping GitHub open to check for new review requests used to be standard practice. When multiple PRs landed at once, going through each one meant:

• What actually changed this time?
• Did CI pass?
• Which requirement or issue is it linked to?
• Which files are risky?
• Were tests added?
• Has something similar been discussed in the past?

That meant spending significant time gathering context before any reviewing could begin.

Worse — the lead either keeps interrupting other work to check GitHub, or misses important PRs because they didn't check notifications.

In OpenLoomi: An event-driven trigger

So PR review isn't designed as a scheduled task. It's made an event-driven scenario inside OpenLoomi Loop. OpenLoomi only finds the user when one of these happens:

• A PR is assigned to the user
• They're @-mentioned in a PR
• A PR has a CI failure that needs attention

When that happens, a review_pr decision card arrives.

Before the PR is opened, OpenLoomi has already done the first round of prep work. It doesn't post comments on the user's behalf — it lays out the judgement basis and the draft comments, then hands over the decision.

The card offers one of four mutually exclusive actions, and the choice determines whether — and how — those draft comments end up on GitHub:

• APPROVE — accept the drafts as-is and post the comments to GitHub
• EDIT — jump into chat, refine the comments ("drop the third one, shorten the first, emphasize the concurrency risk here"), and post them to GitHub when they look right
• LATER — park the review for the next focus block; no comments are posted yet
• SKIP — dismiss this review with an audit entry; no comments are posted

When EDIT is picked, Loop opens a chat thread with the drafts already loaded. The reviewer can ask for targeted revisions — "drop the third one, shorten the first, emphasize the concurrency risk here" — and Loomi regenerates the drafts in place, again waiting for APPROVE before anything reaches GitHub. Every round is recorded, so the assistant gradually learns which drafts the user tends to keep, drop, or rephrase.

The system doesn't replace technical decisions. It handles the most time-consuming part of pre-review: gathering context and doing the first round of analysis.

What this workflow really solves isn't a few automation tasks

At first the goal was simply to save the time spent writing daily reports and syncing issues. But after using it for a while, the realization hits: the real problem isn't that a few automation scripts are missing — it's that engineering information is always scattered across different systems:

• Code and PRs in GitHub
• Tasks and scheduling in Linear
• Notifications and reports in email
• Technical specs in RFCs
• Historical experience and personal judgement possibly in Obsidian notes

In the past, all this information had to be found and pieced together by actively searching. The change OpenLoomi brings is inverting that relationship: instead of constantly searching for information, AI keeps watching the engineering process and comes back with the full context at the right moment.

• If it's routine progress, the daily report gets written automatically.
• If a new issue appears, the info gets enriched and synced to Linear.
• If a PR needs judgement, a decision card arrives with CI results, code summary, risk flags, and draft comments ready.

All that's needed is to focus on the parts that genuinely need experience and judgement.

From "scheduled automation" to a continuously running Loop

To make this work, two kinds of working patterns are configured in OpenLoomi.

One is scheduled execution:

Both tasks run with full tracking enabled, so every action they take and when it happened is visible.

The other is event-driven:

Scheduled tasks fit stable, repeatable work. Event-driven fits work that needs to respond to environmental change on the fly. Together they form an engineering Loop that runs continuously:

Continuously watch → Understand change → Organize context → Propose action → Human confirms → Execute and record

Compared to configuring an isolated workflow, the preference is to have OpenLoomi keep understanding "what's happening with the project right now and what should happen next."

💡 PR review isn't in this table because it isn't a scheduled task — it's an event-driven flow inside Loop's tick. No separate task to wire up; just enable the GitHub source in Loop's settings.

What changed

What OpenLoomi saves isn't just the two hours a week. More importantly, there's no need to keep switching systems, checking notifications, and worrying about what was missed.

How to set this up

The whole configuration isn't complicated. Three connectors cover everything this workflow needs — GitHub for code and reviews, Linear for sprint planning, and Gmail for the daily-digest dispatch. Wire them up from OpenLoomi Desktop, the Claude plugin, or the Codex plugin:

use openloomi-connectors to connect GitHub, Linear and Gmail

Once connected, verification runs via list-accounts. When GitHub, Linear, and Gmail all show active, OpenLoomi picks them up on the next tick and starts the matching scenarios. The Loop status card surfaces reachability right in the chat — every endpoint green means OpenLoomi is ready to drive the scenarios above:

• Every night at 10 PM, the daily report is generated
• Every hour, new Issues are synced to Linear
• Whenever a PR is assigned to the user, @-mentions them, or has a CI failure, the review_pr card surfaces

OpenLoomi's Tracking panel records every execution:

• How many times each task has run
• Which repositories were processed this run
• What reports and tickets were generated
• What actions are still waiting for confirmation
• Whether anything failed or was missed

This way the repetitive work can be handed off to AI while every action it took remains visible.

Related

• Automation — the scheduler behind the daily brief and issue sync
• Loop — the engine that turns GitHub / Linear signals into decision cards
• Connectors — wiring up GitHub and Linear OAuth
• Memory — the team context Loop enriches with
• Attention Agent — where the PR-review bubble lands