At 08:45 you have the whole project in one page, ordered by what blocks other people: the failing pipeline, the commits behind it, and the two MRs approved and unmerged since Friday.
It is 08:40 and main is red. Nine merge requests are open, two of them approved and sitting unmerged since Friday, and the failing pipeline is on a commit whose message is “fix”.
A companion assembles the answer from four places at once: the open MRs with their pipeline status and reviewers, the pipelines on main, the commits behind the failure, and the issues that reference any of it.
01
What does the morning triage look like when it is done for you?
One page at 08:45: the open merge requests with their pipeline status and reviewers, the failing pipeline named, the commits behind it, and the issues that reference any of it. Ordered by what blocks other people.
The two approved-and-unmerged MRs surface immediately, because approval state is part of what the integration reads. So does the MR whose target branch has moved on since it was opened.
02
Reviewing a diff without opening nine tabs
The merge request diff comes back file by file with each patch.
A companion reads the changed functions, then walks the repository tree and reads the files that call them, which is the part a diff never shows.
The result is a draft note on the MR: what changed, what it touches, the two places worth a second look. Reading widely before writing anything is the same habit as the research workflows.
03
Which questions cross the boundary of GitLab?
Whether the customer who reported the bug has been told it is fixed.
Whether the incident doc matches the postmortem issue. Whether a dependency’s changelog explains the failing pipeline. Those live in a mail client, a wiki and a vendor’s site.
A companion signed in as you reads all three and then writes the GitLab issue with the answer in it. GitLab Duo, as of this writing, is administered inside the instance and inherits its permission model.
04
See which pipeline is red and rerun it
Listing pipelines, listing runners and triggering one on a ref are tool calls, which answers the morning question of what is red and whether a rerun clears it. Retrying a single job, cancelling a run and reading a job log happen in the GitLab tab, with the companion driving.
Project deletion exists and is as destructive as it sounds, so it waits for your confirmation. So does issue deletion, which GitLab itself restricts to owners.
Yes. GitLab is a native integration. A companion works projects, issues and notes, merge requests including the file-by-file diff, approvals and merges, branches, tags, commits, repository files, labels, members and pipelines. Every write is staged for your approval.
It drafts the review. A companion reads the MR diff patch by patch, walks the repository to read the callers the diff leaves out, and writes a note covering what changed and what deserves a closer look. Posting, approving and merging are separate approved steps.
Yes, on a given ref, and it asks first. Retrying a single job, cancelling a run and reading a job log happen in the GitLab tab you are signed into, driven by the companion.
Describe the pass once and save it as a routine: unlabelled issues, stale open ones, issues whose linked MR merged. A companion lists the project’s real labels before proposing any, so triage uses your taxonomy. See operations for scoping.
Both are native integrations, so one companion reads a merged merge request and closes the Linear issue it resolves without you copying identifiers between tabs. Download Strawberry free and connect both; paid plans start at $20 a month.
GitLab Strawberry