Where does a creative-direction brief belong in Linear?

On the Project. The brief synthesis becomes the project description (markdown). The four axis positions become labels with a prefix-colon convention. The rejection list becomes a section in the project description or a pinned issue. Issues created within the project inherit the label-level traceability so views and filters can pull cross-project work answering the same brief.

Why labels instead of a custom field?

Linear does not expose custom fields the way Jira does. Labels are the primary structured-tagging primitive, and Linear's filter and view system is built around them. The prefix-colon convention (tone:professional, aesthetic:editorial-restrained) gives labels the queryable shape that custom fields give in Jira while staying inside Linear's native concepts. The naming convention is what makes the labels useful at scale.

How does cycle planning consume the brief?

Cycle planning answers one question per project: which briefs is this cycle serving? The cycle review then answers the inverse: did the issues in this cycle answer the briefs they claimed to serve? Linear's cycle is a time-boxed unit, similar to a scrum sprint, and the brief-aware cycle review borrows the same direction-grading prompt agile teams use during sprint review.

What is the most common Linear-specific failure of this integration?

Labels added but never used in views. The team configures the label taxonomy, applies labels to a few issues, then never builds the views that make the labels load-bearing. Six weeks later, half the issues have no labels and the team has lost the cross-project axis visibility the convention was supposed to provide. The fix is to build the views first, then enforce label hygiene; without the views, the labels are decorative.

Integration · Linear

RampStack skills in Linear.

Briefs as Projects. Axes as labels with a prefix-colon convention. Cycle planning that names which briefs are being served.

Linear works through Projects, Issues, Labels, Cycles, and Views. The integration uses each one for the role it plays in the team's workflow. The Project carries the brief in its description. Labels are how axis positions become structured tags Linear can filter on. Cycles are when the team grades direction adherence. Views are how the team surfaces cross-project work answering one brief.

The shape

Brief into Linear primitives.

The Project carries the brief description. Labels carry the axis positions. Issues land inside the Project and inherit project-level visibility. Views slice the issue list by axis label across projects.

The Project carries the brief. Labels carry axis positions. Issues inside the project receive labels during refinement. Views filter by label across projects.

The mapping

Brief artifacts to Linear primitives.

Brief artifact	Linear primitive	Notes
Project name and description	Project name and description	Markdown supported in description
Tone axis position	Workspace label: tone:[position]	Created at workspace level for cross-team reuse
Aesthetic axis position	Workspace label: aesthetic:[position]	Same prefix-colon pattern
Relationship axis position	Workspace label: relationship:[position]	Same prefix-colon pattern
Sensory axis position	Workspace label: sensory:[position]	Same prefix-colon pattern
Rejection list	Project description heading: Won't do	Or pinned issue if the list is long
Inspiration references	Project description: Inspiration heading	URL list with one-sentence notes
Direction-status per Issue	Label: status:aligned / status:drift / status:review	Same prefix-colon convention

The prefix-colon convention is what makes the labels useful at scale. Without it, the workspace ends up with a flat list of labels (Professional, Editorial Restrained, Peer) that cannot be filtered by axis. With it, the team builds views like “all issues with any tone:* label” or “Professional tone work this cycle” directly in Linear's filter UI.

Create labels at the workspace level, not per-team, so the same axis vocabulary is available across every team. If a team needs a team-specific label, that is fine, but the axis labels stay global.

Templates

Copy these into the workspace.

Project description template

Paste this into the description of every brief-bound Project. Linear renders markdown so the headings hold.

# Brief synthesis

[One paragraph in present tense describing what
this combination produces in practice.]

# Axis positions

- Tone: [position] because [one-sentence rationale]
- Aesthetic: [position] because [one-sentence rationale]
- Relationship: [position] because [one-sentence rationale]
- Sensory: [position] because [one-sentence rationale]

These positions correspond to the four axis labels
applied to every issue inside this project.

# Won't do

- [specific phrasing, structure, or visual move
  this brief excludes]
- [next item]
- [next item]

# Inspiration references

- [URL] - [one sentence on what specifically resonates]
- [URL] - [next reference]

# Open questions

- [anything still unresolved that downstream issues
  will need answered]

Label naming convention

Create these labels at the workspace level once. They are reused across every project that adopts the framework.

Tone (4 labels)
  tone:professional
  tone:conversational
  tone:playful
  tone:provocative

Aesthetic (4 labels)
  aesthetic:editorial-restrained
  aesthetic:polished-standard
  aesthetic:controlled-maximalist
  aesthetic:expressive-maximalist

Relationship (4 labels)
  relationship:authority
  relationship:peer
  relationship:companion
  relationship:coach

Sensory (3 labels)
  sensory:functional
  sensory:considered
  sensory:resonant

Direction status (3 labels)
  status:aligned
  status:drift
  status:review

Color the four axis label groups distinctly so a
glance at the issue list shows axis coverage. Status
labels stay neutral so they do not compete visually.

Issue template

Save this as the default issue template for the team. The Context section is what makes the issue brief-aware without re-stating the brief in every description.

Title: [outcome-focused, no implementation detail]

Context

This issue serves the [brief name] project.
It answers the brief on the [axis] axis by
[specific manifestation, e.g., "using Considered
sensory pacing in the empty state"].

Acceptance

- Visible behavior: [the user-facing change]
- Direction: passes the rejection list
- Quality: [tests, accessibility, performance floor]

Out of scope

- [paste the relevant lines from the brief's
  rejection list]

Labels (set during refinement)

- The four axis labels inherited from the project
- status:aligned (default after direction review)

Saved views to build

Create these as saved views at the workspace level the first day the labels go live. Without the views the labels are decorative.

View 1: All Professional-tone work this cycle
  Filter: label = tone:professional
          AND cycle = current
          AND status != Canceled

View 2: Drifted issues, surfaced for review
  Filter: label = status:drift
          AND status != Done

View 3: Cross-project Editorial Restrained work
  Filter: label = aesthetic:editorial-restrained
          AND status = "In Progress"
  Group: by project

View 4: Issues missing axis labels (hygiene)
  Filter: NOT label IN (tone:*)
          AND project IS NOT NULL
          AND status != Canceled
  (Use Linear's filter UI; the label-prefix wildcard
   syntax depends on your workspace's label setup.
   If wildcards are not supported in your workspace,
   build this view as the union of the four explicit
   tone labels and a "no tone label" filter.)

Cycle planning prompt

Open every cycle planning meeting with this prompt. Cycle review borrows the sprint-review prompt from the agile integration page.

Cycle planning opening

1. Which projects (briefs) is this cycle serving?
   Name them. If more than three, the cycle is
   overcommitted; cut to three.

2. For each named project: read the brief synthesis
   and rejection list aloud (60 seconds each).

3. Pull issues into the cycle. Each issue must:
   - Belong to one of the named projects
   - Carry the four axis labels inherited from the project
   - Have an Acceptance criterion that names the axis
     position it answers

4. Issues that do not satisfy step 3 either get
   rewritten or deferred to a future cycle.

Failure modes

Where the Linear integration goes wrong.

Labels added but never used in views. The team configures the prefix-colon labels, applies them to a few issues, and never builds the saved views that make the convention load-bearing. Six weeks later half the issues are unlabeled and the team has lost the cross-project visibility the convention promised. Build the views first, then ask the team to keep labels current.

Issues created outside any project. Quick issues filed from the inbox land without a project, never inherit the axis labels, and bypass the brief entirely. Add a workspace-level convention that every issue belongs to a project, even if the project is “Operational” for non-brief work, and build a hygiene view that surfaces orphaned issues.

Project description goes stale. The brief is in the project description on day one, but four months in the description still describes the original framing while the team has been making conscious adjustments without updating it. Schedule a quarterly project description audit; if the brief has drifted in practice, update the doc to match (or rewrite the brief and propagate the change).

Cycle reviews skip direction grading. Linear cycle reviews tend to focus on velocity and completion. Without the brief-grading prompt borrowed from the agile integration, the cycle review measures throughput and the brief drifts in silence.

Composition

Which skills feed the Linear integration.

The brief itself comes from creative-direction. Issues that produce voice copy consume brand-voice. Issues that produce identity work consume brand-identity. Conversion-focused work consumes landing-page-copy. The dependency chain is identical to the agile and Jira integrations; this page just translates it into Linear's vocabulary.

Continue reading.

For Linear platform mechanics (project structure, label configuration, view filters, cycle settings), Linear's official documentation is the source of truth. Every primitive used above is a built-in feature of the Standard plan or higher.

Frequently asked questions.

Where does a creative-direction brief belong in Linear?: On the Project. The brief synthesis becomes the project description (markdown). The four axis positions become labels with a prefix-colon convention. The rejection list becomes a section in the project description or a pinned issue. Issues created within the project inherit the label-level traceability so views and filters can pull cross-project work answering the same brief.
Why labels instead of a custom field?: Linear does not expose custom fields the way Jira does. Labels are the primary structured-tagging primitive, and Linear's filter and view system is built around them. The prefix-colon convention (tone:professional, aesthetic:editorial-restrained) gives labels the queryable shape that custom fields give in Jira while staying inside Linear's native concepts. The naming convention is what makes the labels useful at scale.
How does cycle planning consume the brief?: Cycle planning answers one question per project: which briefs is this cycle serving? The cycle review then answers the inverse: did the issues in this cycle answer the briefs they claimed to serve? Linear's cycle is a time-boxed unit, similar to a scrum sprint, and the brief-aware cycle review borrows the same direction-grading prompt agile teams use during sprint review.
What is the most common Linear-specific failure of this integration?: Labels added but never used in views. The team configures the label taxonomy, applies labels to a few issues, then never builds the views that make the labels load-bearing. Six weeks later, half the issues have no labels and the team has lost the cross-project axis visibility the convention was supposed to provide. The fix is to build the views first, then enforce label hygiene; without the views, the labels are decorative.