How to Create Issue Templates in Linear (Bugs, Features, and Spikes)
Inconsistent issues are expensive. A bug report without reproduction steps costs an engineer twenty minutes of back-and-forth. A feature request without a problem statement turns into a debate in planning. Templates fix this at the source by giving every issue type a predictable structure and sensible default properties.
Linear supports issue templates at the workspace and team level. Templates can prefill the description and set properties like status, priority, labels, and assignee, and they can include sub-issues. This guide shows how to design templates that people actually use, and how to roll them out without adding friction.
Working in Linear? Turn your spec into dependency-ordered tickets.
Paste the feature or spec. Vantage pulls out the requirements and breaks them into tickets, ordered by what blocks what, ready to groom with your team.
How this works
- We save what you typed. No AI runs on this page.
- You create a free account.
- Vantage builds a PRD and dependency-ordered tickets from it inside your own workspace.
Why ask for an account? We’re a small team, and a full generation runs a multi-step AI pipeline that costs us real money. So we tie it to a free account instead of running it anonymously. You also get to keep the result and edit it.
Your text is only used to create your project, and it stays private to your account. If you don’t sign up, we delete it after 7 days. Privacy policy
Step-by-step guide
Decide which templates you need
Start small. Most teams need three or four templates: a bug report, a feature or improvement, a spike for time-boxed research, and possibly a chore for maintenance work. Look at the last 50 issues your team created and group them by type. If a type is rare, it does not need a template.
- Review recent issues and group them by type
- Pick the three or four most common types
- Identify the information that is most often missing for each type
Choose workspace or team scope
Templates can live at the workspace level, where every team can use them, or at the team level, where they apply only to that team. Put shared formats such as bug reports at the workspace level so they stay consistent. Keep team-specific templates, such as a data team's pipeline change request, at the team level.
Create the template and write the description
Go to Settings, then Templates under the workspace or the relevant team, and create a new issue template. Write the description as a set of headings with short prompts underneath, so the person filling it in knows exactly what to write. Keep prompts concrete: 'Steps to reproduce (numbered)' is better than 'Details'.
- Open Settings and navigate to Templates for the workspace or team
- Create a new issue template and give it a clear name
- Add headings with one-line prompts under each
- Keep the template short enough to fill in within two minutes
Set default properties
Templates can set properties on the issue when it is created. For a bug template, apply a 'bug' label and a default priority your team agrees on, or leave priority unset if triage should decide. For a spike, add a 'spike' label and a small default estimate to signal the time box. Defaults reduce manual clicks and make filtering reliable later.
- Add the label that matches the issue type
- Set a default status, such as Triage or Backlog
- Decide whether priority should be set by default or during triage
- Add an estimate default for time-boxed work like spikes
Add sub-issues for repeatable checklists
If a type of work always involves the same steps, add sub-issues to the template. A 'new integration' template might create sub-issues for API client, settings UI, documentation, and QA. This turns tribal knowledge into a checklist that appears every time, without copying from an old issue.
Set team defaults where it helps
Linear lets you choose default templates for issues created by team members and, separately, for issues created by people outside the team. A good pattern is a structured request template for non-members, so cross-team asks arrive with context, and a lighter default for members who already know the conventions.
Roll out and iterate
Announce the templates in your team channel with one example of a well-filled issue. After a few weeks, review issues created from each template and remove any section that is consistently left blank. A template that asks for information nobody provides is noise.
Common mistakes
Templates that are too long
A twelve-section bug template gets skipped. People will create a blank issue instead. Keep each template to the four or five sections that genuinely change how fast the work gets done.
Using templates instead of triage
Templates improve inputs but do not prioritize. You still need a triage step where someone reviews new issues and decides what happens next.
Never revisiting templates
Teams change how they work. A template written a year ago may ask for fields that no longer matter. Review templates at least twice a year.
Tips
Include a 'How to verify' section in feature templates so QA criteria are written before work starts.
Link to your bug severity definitions directly in the bug template description.
Use a non-member default template to structure requests coming from sales, support, or other teams.
Name templates by issue type, not by team, so people can find the right one quickly.
How Vantage helps
Templates keep individual issues consistent, but the bigger gap is usually between the PRD and the tickets. Vantage generates tickets directly from PRD requirements with acceptance criteria and dependencies included, then pushes them to Linear, so every ticket traces back to the requirement it implements.