The short version. Linear can require fields when an issue is created through a form template, and it can require a priority on the way out of Triage. Beyond those two, it does not gate a status change on whether a field is filled — the write path stays open by design. LineGuard adds that: a rule that watches for any transition you name, checks the fields you care about, and reverts the issue with a comment explaining what was missing. Then it logs it.
At creation, yes. A Linear form template can require any of customer, label group, priority, title and due date, and Linear follows up to collect anything missing before the issue is created. Standard (non-form) templates do not support required fields.
No. The one status gate Linear ships covers priority on the way out of Triage, and there is no equivalent for estimate on any boundary. Estimate is not among the fields a form template can require either. This is the specific gap LineGuard fills.
Yes — this exact one Linear does natively. Team settings has a Require explicit prioritization option for Triage, which requires a priority to be set when moving issues out of Triage. You do not need a third-party app for it. It is also the only requirement of its kind Linear ships: there is no equivalent for estimate, assignee or labels, and no such setting on any other status boundary.
In one case, yes: priority, on the way out of Triage, via the team setting above. Everywhere else, no — Linear's status configuration has no general notion of a disallowed transition or a precondition on one. That is a deliberate design position rather than an omission: Linear keeps the write path open so that typing fast and moving on stays fast.
With a rule alongside Linear rather than inside it. LineGuard watches for the transition, checks the fields you named, and if one is empty it puts the issue back and comments saying what was missing. It corrects rather than prevents, because Linear delivers a change after it has been committed.
More than most people assume, and it is worth knowing before you install anything. As of the check above:
Two honest answers to a good part of the searches that land here: if a form at the front door is what you need, use a form template, and if you need a priority set before an issue leaves Triage, turn on the team setting. Neither needs us.
Linear does gate one transition on one field — the Triage prioritisation setting above — and that is worth dwelling on, because it shows the idea is not foreign to Linear. What it has not done is generalise it. There is no way to name a different field, or a different boundary: the status configuration carries no general notion of a disallowed transition or a precondition on one, and the docs describe no field validation on a status change.
Read that as a deliberate design position rather than an omission. Linear optimises for typing fast and moving on, and putting a validator in front of every write — the app, the API, the Slack integration, the branch automation — would slow the paths people value most. The one exception proves the rule: Triage is the one place where a human is already expected to stop and make a decision, so a gate there costs nothing. Linear's own directory carries an Automations category for the rest: policy that only some teams want belongs beside the tracker, not inside it.
Two near misses are worth naming, because they are the things people try next:
Requiredness is not really a property of a field — it is a property of a field at a moment. An estimate matters when work is finishing; a priority matters when the issue leaves Triage; an assignee matters when it enters In Progress. Linear agrees with the principle, incidentally: the one requirement it ships is attached to a transition rather than to a field, and it picked the moment rather than the form. Ask for all of them at creation and people either type something to get past the form or file the thought somewhere else entirely. We wrote the longer argument in required fields are the smallest part of workflow hygiene.
This is why LineGuard attaches requirements to transitions rather than to fields, and why it is a complement to form templates rather than a replacement for them. A form is the right tool for intake. A rule is the right tool for a boundary.
One shape, applied to the fields Linear already has:
When an issue enters or leaves a status (or a specific field changes), if the fields you name are empty — or match some other condition you set — then put the issue back and comment on it saying what was missing.
Note that estimate and assignee are two of the four, and neither is in the set a form template can require. That overlap is small on purpose.
area group.cause group.Each is a trigger, a condition, and a consequence. The consequence is the part that decides whether the rule survives contact with the team: a rule that only reports gets ignored, and a rule that reverts silently is indistinguishable from a bug — which is why the comment matters as much as the revert.
If the set you have in mind is really one agreement — everything that reaches Done must satisfy these four things — that is a definition of done, and it is worth writing as one.
Worth being direct, because it follows from how Linear's webhooks work: they arrive after a change is committed. LineGuard cannot stop a change from happening. It sees the result and reverses it, usually within a couple of seconds, which means there is a brief window where the invalid state is real.
For workflow hygiene that window is nothing. For anything where a few seconds of wrong state would cause actual harm — a payment approval, an access grant — do not use this, or anything else built on webhooks, as the only safeguard. The upside of correcting rather than preventing is coverage: it applies to every write path, including the ones you forgot existed — the API, Slack, and the pull request that merged at 2am.
The free plan runs three rules on one team with seven days of audit history, with no feature gates — every trigger, condition and action is included. It is deliberately enough to answer the only question worth answering first: pick the one constraint your team already agreed to in writing and already fails to follow, turn on that single rule, and watch the log for two weeks. Either it stops firing, or you have learned something a retro would not have told you. Plans and limits.
Not a workspace admin? Send it to the person who is.
Related: Triage rules in Linear · Enforcing a definition of done in Linear · Workflow automation in Linear