mcpField
L
linear-setup

linear-setup

github.com/tjcagesDevelopment1039 installsUpdated 13w ago
Repository

About linear-setup

A guided skill for bootstrapping Linear tracking from a project's goals, repository history, and roadmap. It emphasizes checking existing work before writes and installing tracking rules in agent instructions.

Key features

  1. 01Verifies Linear MCP access first
  2. 02Checks for existing tracking before changes
  3. 03Builds milestones and issue structure
  4. 04Backfills work using repository evidence
  5. 05Installs tracking rules in agent instructions

Use cases

  1. 01Creating a Linear project from a repository
  2. 02Extending existing tracking conservatively
  3. 03Recording completed work from changelogs and git history

MCP support

Probes Linear MCP before making changes and stops if access fails. It uses Linear to set up and maintain project tracking.

Install

Copy the command and run it in a terminal.

$npx skills add https://github.com/tjcages/linear --skill linear-setup

After installing, type/linear-setupin Claude Code to confirm it loaded.

Bundled files

References and scripts installed along with SKILL.md.

ALWAYS_ON.md
AUTH.md
AUTOMATION.md
EXAMPLES.md
METHODOLOGY.md
RESPONSE.md

Details

From the project README

Linear setup

Chat rules: RESPONSE.md. Auth: AUTH.md. Full method: METHODOLOGY.md.

Step 0 — auth

Probe Linear MCP. On failure → AUTH.md steps for this agent; stop. Never invent API calls.

Operating order

Follow in sequence. Early gates exist because getting them wrong corrupts live workflows.

1. Already tracked? (§1a)

Search Linear by repo name and ask the user. Never assume blank slate.

  • Nothing → fresh bootstrap; continue.
  • Exists → STOP. Enumerate issues/milestones/labels/docs/status updates → summarize → per-category yes/no before any write. Extend conservatively. Scan repo for unmirrored roadmap docs (§4.7).
2. North Star (§1b)

README-as-vision is usually enough — say the call out loud. Question 5 (why track?) picks the shape — see METHODOLOGY goal→shape table.

3–4. Type + structure (§2–§3)

Suggested types: Product / Tool / Drop / Marketing. Milestones 1:1 with real phases. Separate engineering / launch / rollout tracks. Dates only with a real signal. Prefer §17 if shape is unclear.

5. Backfill (§4)

CHANGELOG > roadmap > git log. Feature-level default; per-release for launched packages. Done only with evidence. Doc “done” ≠ proof — corroborate (§4.8).

Writing (tickets)

Titles ≤8 words. Descriptions ≤3 sentences or ≤5 bullets. Comments ≤3 lines. Screenshots over prose (§10).

6. Wire (§4, §10, §11)

Real blockedBy/blocks. Surface UI-only items early (§11). Add README as Linear project document.

7. Install discipline (§5)

Write the tracking protocol into always-loaded agent instructions (CLAUDE.md / AGENTS.md / .cursor/rules/) with real team/project/milestone names. Bootstrap is not done without this.

8. Honesty (§6, §9)

Status updates at milestone/health moments only. atRisk before dates slip.

9. Done check (§18, §26)

Rubric ≥16/20 with no load-bearing 0, or full §26 audit.

After setup

Point user to always-on (if missing) via finish linear-tracking install. Optional Cursor weekly health: AUTOMATION.md. One next action.

Comments

Markdown supported