The short version. Almost every team has a definition of done written down somewhere. Linear does not read it. An issue moves into Done because someone dragged it there, and nothing checks whether the things the team agreed on are actually present. Enforcing the definition means putting a check on that one boundary — and then, more usefully, counting how often the check was needed.
One clause of it, yes: a team setting requires a priority before an issue leaves Triage. Nothing checks anything at the Done boundary, though — you can name a Done status and write the definition into a template's description, but nothing stops an issue reaching Done with no estimate, no assignee and no label.
Statuses you define per team, templates that can carry the definition as text, a setting that requires a priority before an issue leaves Triage, auto-close and auto-archive for stale work, and pull request automations that move a linked issue to Done when the PR merges. One real check, at one boundary, on one field.
Because the agreement is enforced by memory, and memory is unevenly distributed. It holds while someone is watching, then a release week arrives and the person who cared is on leave. The failure is never a decision to abandon it — it is an absence of anything that notices.
Put a check on the boundary the definition is about. A rule watches for issues entering Done, tests the conditions the definition names, and if one fails it returns the issue and comments explaining which. LineGuard does this and records every evaluation, so you can see how often the definition was being broken.
Whether the definition is becoming true. Each rule reports how often it ran and how often it caught a problem; the gap between them is your compliance number. A rule that stops firing over a quarter is the outcome you want — the enforcement made itself unnecessary.
Not through disagreement. Nobody votes to stop estimating. What happens is that the definition is enforced by attention, and attention is the scarcest thing on a team shipping software. It holds for a quarter because someone reads the board every morning and asks the awkward questions. Then that person goes on leave during a release week, three issues go to Done to clear the column, and the norm has changed without anyone deciding it should.
By the time it surfaces, it surfaces as a second-order problem: the velocity chart is fiction because half the completed issues have no estimate. Nobody can tell which bugs were caused by what, because the root-cause label is empty on most of them. The retro concludes that the team should be more disciplined, which is exactly the intervention that already failed.
The useful framing is that a definition of done is a constraint without an enforcement point. It names a boundary — the moment work is called finished — and then relies on every person crossing that boundary to remember it, every time, under deadline. That is not a discipline problem. It is a missing check.
More than nothing, and worth using before you add anything:
What none of these does is test anything at the moment an issue becomes Done. The Triage setting shows Linear is willing to gate a transition — it just gates that one, on that one field. Beyond it the status configuration carries no notion of a precondition, and the write path is deliberately open, which is a large part of why the app feels as fast as it does.
Worth its own section, because it is the most common way a definition of done gets bypassed by a team that genuinely believes it is following one.
Linear's GitHub integration can update a linked issue's status from pull request events. The documented default is that opening a PR moves the issue to In Progress and merging it moves the issue to Done. It is configurable per team, across drafted, opened, review requested, ready for merge and merged, and you can target different statuses depending on which branch received the merge.
This is a good feature and most teams should use it. But notice what it means for a definition of done: the most frequent path into Done is not a person looking at the issue and deciding it is finished. It is a merge button, pressed in a different tool, by someone thinking about the diff. There is no moment in that flow where anyone is prompted to remember that Done requires an estimate.
It also means that any enforcement which only covers the Linear UI covers the minority of cases. A check has to sit on the state change itself, wherever the change came from — the app, the API, Slack, or a merge at 2am.
Take the definition you already have and read it as a list of conditions on one transition. A typical one decomposes cleanly:
cause is empty, and the issue is a bug.area label group is empty.Each is a trigger, a condition and a consequence. In LineGuard the consequence is to return the issue to where it came from and comment on it, naming the missing fields and mentioning whoever made the change. Conditions nest with AND and OR, which matters as soon as the real rule is "everything reaching Done needs an estimate, and a bug also needs a root cause".
A note on how many to write: fewer than you want to. The temptation is to encode the whole handbook at once, which produces a board that fights everyone on Monday morning and gets switched off by Wednesday. One rule, on the constraint the team already agreed to and already fails, is the version that survives.
The enforcement is the smaller half. The record is the useful half.
Every evaluation is logged: which rule, which issue, whether the conditions matched, what each action did. Per rule you get how often it ran and how often it guarded — caught an actual problem — over 7, 30 and 90 days. That second number is a measurement of your process that you could not otherwise get: it is the count of times the team's own agreement was about to be broken.
Watching it fall is the point. A rule that guarded thirty times in its first month and twice in its fourth has not become less necessary — it has done its job, and you have evidence rather than an impression.
For what this looks like with real numbers, Gallabox runs nine rules across a nine-stage pipeline, and thirty days of counting showed the distribution was wildly uneven: a couple of rules doing nearly all the work and several almost never firing. That is one team over one month rather than a benchmark, but the shape of the finding — that you cannot guess which of your rules matter — is the part that generalises.
Pick the single clause of your definition of done that you are most confident is being broken, and write only that rule. Watch the audit log for two weeks. Either it barely fires, in which case you were wrong and that is worth knowing cheaply, or it fires constantly, in which case you have just turned an argument about discipline into a number.
The free plan runs three rules on one team with seven days of history, no card, no feature gates. Plans and limits.
Not a workspace admin? Send it to the person who is.
Related: Required fields for Linear · Triage rules in Linear · Workflow automation in Linear