linear-issue-style

name

linear-issue-style

description

Enforce caveman-lite prose style on every Linear issue description written or updated via the Linear MCP tools. Descriptions must be succinct: no filler, no hedging, no marketing recap. Keep articles and full sentences; drop everything else. Applies to ALL Linear issue create/update operations — no user keyword required. Triggers automatically when about to call: - mcp__gemini_ai_Linear__save_issue - mcp__gemini_ai_Linear__create_comment (if comment is issue-description-like) Also triggers on phrases like "make this Linear issue shorter", "caveman-lite the issue", "trim the description".

Linear issue style — caveman lite, always

All Linear issue descriptions MUST be caveman-lite. This is a blocking rule, not a preference.

What caveman-lite means here

• Keep articles (a/an/the) and full sentences — it's a Linear issue, not a shell prompt
• Drop filler words: just, really, basically, actually, simply, essentially, clearly
• Drop hedging: I think, it seems, probably, might be worth, perhaps
• Drop pleasantries: "this is a great opportunity to", "we could consider"
• Drop marketing recap: don't restate the summary at the end
• Drop transitional throat-clearing: "With that said", "That being said", "Moving on"
• Short synonyms (use ≠ utilize, fix ≠ implement a solution for)
• Technical terms stay exact

Structure rules

Use this shape unless the issue genuinely doesn't fit:

## Summary
One paragraph, 2–3 sentences. Problem + proposed action.

## Current code (or Current behavior)
File path + line number. Minimal quote. What it does.

## Proposed code (or Proposed behavior)
Code block or short description. No restating "this is better because".

## Measured impact (if applicable)
Table. Before / After / Delta only.

## Edge cases handled (if applicable)
Bullet list. One line per case. Input → outcome.


One line: repo + branch + command.