Linear project template
A description should tell someone who was not in the conversation four things. These are the following: what the work is, how big it is, why we are doing it, what is still undecided.
Duration, Impact and either Verbatim or Non-customer drivers are
required. Everything else is optional. Standing bugs and debt projects use the
short shape described in
Work tracking in Linear.
Every project needs an initiative
Attach one before anything else. A project with no initiative doesn't appear on the roadmap, and neither does any issue inside it. Pick by the test:
| Initiative | Test |
|---|---|
| Inference | Does a customer hit it with an API key to get tokens back? |
| VMs | Is it about handing someone a machine? |
| Serverless GPU | Is it a job that starts and finishes? |
| Clusters | Is it about hardware we own, before Atlas can list it? |
| Atlas | Is it "what do we own, and can Hydra allocate from it"? |
| Admin | Would this exist even if we sold something other than GPUs? |
| UX | Is the problem that someone cannot get their work done, rather than that something is broken? |
| Tooling | Would a customer ever ask for this? If no, it belongs here. |
| Commercial | Is it about selling and proving, rather than building? |
One initiative per project. If the work genuinely spans two, it's two projects. Full definitions are in Work tracking in Linear.
Skeleton
One or two sentences on what this is. If it absorbed or replaced another
project, say so here.
## Duration
**M**
* Services touched: 3 (gateway, db, dashboard)
* Schema change: yes
* Third-party dependency: no (reason)
* Unresolved decision: yes (what is undecided)
* Existing partial implementation: yes (what exists, and where)
A paragraph justifying the letter.
## Impact
What changes for the customer, or for us, when this ships.
## Roadmap context
Which projects this depends on or overlaps with, and which open questions from
the initiative bear on it.
## Verbatim
> The customer's own words.
## What is actually missing
The gap between the code today and what this needs. Cite files and lines.
## Milestones
1. **First slice.** What it includes.
2. **Second slice.** What it includes.
## Work
* `service`: what changes here
* `db`: schema or migration
* `dashboard`: view or flow
* `wiki`: what needs documenting
## Non-customer drivers
*None recorded yet. Internal requesters and strategic assertions go here
(human-authored, not generated).*
<!-- lyceum:signals -->
<!-- /lyceum:signals -->
Notes on the sections
Summary. Linear's summary field is separate from the description and shows in list views. Put the finding in it, not the title again.
Duration. Always the same five bullets in the same order, so they can be
compared across projects. The letter is S, M, L or unsizeable. unsizeable
means the scope hasn't been decided, not that the work is large. If the project
reads two ways, write out both readings and mark it unsizeable.
Impact. When no signal is linked, say the project was scoped from the initiative and the name alone, otherwise it gets read as customer-driven later.
Verbatim. Quote the customer rather than paraphrasing. If all we have is a paraphrase, or the account is unidentified, say so.
Milestones. Each one shippable. State the condition on any slice that's conditional.
Non-customer drivers. Internal requests and strategic bets, written by a person. Keep the placeholder when it's empty.
Signals block. Generated from linked customer signals. Don't edit inside the comment markers, and keep it at the bottom.
Labels
Feature or Primitive on planned work, one or the other. Neither on bugs and
debt projects. Topic labels are optional and additive.