---
title: "Dock + Linear: agent-drafted sprint retros with attributed engineering lead"
excerpt: "Point a coding agent at Linear cycles and GitHub PRs and let it draft the retro. The draft lands in Dock with eng-lead sign-off, full attribution, and a pointer back to every issue it read."
author: mei
category: Use Cases
date: "2026-05-30"
---

Sprint retros stall because nobody wants to write the first draft. A coding agent can read the cycle in Linear, the merged PRs in GitHub, and the on-call pages, then propose the retro in Dock. The engineering lead reviews three rows, edits the language, and signs off. The cycle closes the same afternoon instead of slipping a week. The retro is a Dock doc with attribution, not a Slack thread that scrolls away.

Linear and GitHub stay the system of record for the raw data. Dock is the system of record for what the agent interprets. Each Dock row carries a pointer back to the platform record, agent identity, decision, reviewer, and timestamp. The agent re-fetches platform data via fresh API reads when it needs current state.

## The retro draft surface

| Theme | Cycle evidence | Agent reading | Proposed action | Eng-lead sign-off |
|---|---|---|---|---|
| Velocity dropped 22% | Linear cycle ENG-Q2W4 (38 → 30 pts) | Two reviewers OOO mid-cycle; PRs queued 3 days | Add backup reviewer rotation | Approved, Priya |
| Flaky test budget exceeded | GitHub PR #4188, #4201, #4214 reruns | Same fixture leak across three suites | Triage week before next cycle | Approved with edit, Priya |
| Incident from missing migration gate | PagerDuty SEV-2 2026-05-22 | Deploy ran before backfill finished | Add migration gate to deploy doc | Defer to runbook review |

Three to seven themes per cycle is typical. Each row links to the Linear cycle URL, the PR numbers, and the agent's reasoning trace. Editing the proposed action edits the row; the platform records are never touched.

## One worked workflow

The agent runs Friday at 4pm against the closed cycle. It pulls the Linear cycle summary, the merged PRs from GitHub with review latency, and any incidents tagged to the cycle window. It clusters evidence into themes, drafts the retro doc, and routes to the engineering lead. The lead reviews in Dock, edits two themes, approves one as-is, and defers the third to next week's runbook review. The retro is published to the eng channel before the day ends. Patterns Mei has covered in [Dock for project management](/blog/dock-for-project-management) and the [Cloud 2.0 for product](/blog/cloud-2-0-for-product) write-up apply: the agent proposes, the human decides, the row remembers both.

## Why this matters

A retro that ships Friday is worth more than a perfect retro that ships next Wednesday. The eng lead reads three rows instead of writing three pages. The team sees the evidence the agent used, not just the conclusion. When the next cycle starts and somebody asks why review rotation changed, the row points back to ENG-Q2W4 and the decision is legible. This is the [agent collaboration primer](/blog/agent-collaboration-primer) in practice for engineering. The agent's reasoning is attributed under its [agent identity](/blog/agent-identity), so a future audit knows which version of which model drafted which theme.

## Try it

Connect Linear and GitHub via OAuth, point a coding agent at last cycle, and let it draft. Engineering teams adjacent to this pattern usually want [Dock for DevOps](/blog/dock-for-devops) and the [agent identity lifecycle](/blog/agent-identity-lifecycle) on day one.

## FAQ

**Does the agent write to Linear?** No by default. Linear stays read-only. The retro lives in Dock. If the lead wants action items as Linear issues, the agent proposes them and the lead clicks create; the issue ID is written back to the Dock row.

**What if the agent misreads the cycle?** The reviewer edits the row. The original draft and the edit are both retained, so the next cycle's agent learns from the correction. Linear's GraphQL surface is documented at [linear.app/developers](https://linear.app/developers) and the agent re-queries on every run rather than caching stale state.

**How long should the retro itself take?** Atlassian's playbook suggests [45 minutes to 3 hours for a sprint retro](https://www.atlassian.com/team-playbook/plays/retrospective). With a Dock draft in hand, the live meeting trends toward the lower bound because the evidence is pre-clustered.

**Who owns the published retro?** The engineering lead, attributed. The agent is the drafter, attributed. Dock keeps both on the row so the audit trail survives staff turnover.