RampStack skills in Linear.

Visual demonstration

What this looks like in Linear.

# Linear MCP, called via the agent runtime
mcp.linear.create_project({
  team: "RAMP",
  name: "Phase 3: Identity",
  description: "Refreshed logo, color, type, imagery direction.",
  cycles: [{ name: "Week 3" }, { name: "Week 4" }]
})

mcp.linear.create_label({
  team: "RAMP",
  name: "phase:identity",
  color: "#7c3aed"
})

# Populate initial issues from cadence-pattern output

CLI alternative

No widely-adopted Linear CLI. The MCP is sufficient.

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.

Templates

Copy these into the workspace.

# 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]

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.

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)

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 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.

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.

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.