linear-discipline
Always-on Linear session discipline and one-time soft nudge for untracked repos. Use whenever non-trivial work is happening in a…
Bootstrap or extend Linear project tracking the right way — methodology, not API CRUD. Use when the user asks to set up Linear tracking, track this project in Linear, add this repo to Linear, backfill history, get ready to track, or consents after a soft-nudge from
$ npx -y skills add tjcages/linear --skill linear-setup --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/linear-setupContext preview
The summary Claude sees to decide when to auto-load this skill.
Bootstrap or extend Linear project tracking the right way — methodology, not API CRUD. Use when the user asks to set up Linear tracking, track this project in Linear, add this repo to Linear, backfill history, get ready to track, or consents after a soft-nudge from
name: linear-setup version: 1.0.2 description: >- Bootstrap or extend Linear project tracking the right way — methodology, not API CRUD. Use when the user asks to set up Linear tracking, track this project in Linear, add this repo to Linear, backfill history, get ready to track, or consents after a soft-nudge from linear-discipline. Anchors to North Star, backfills Done with evidence, wires blockedBy, installs per-repo discipline. NOT for one-off issue create/comment — Linear MCP handles that.
Chat rules: [RESPONSE.md](./RESPONSE.md). Auth: [AUTH.md](./AUTH.md). Full method: [METHODOLOGY.md](./METHODOLOGY.md).
Probe Linear MCP. On failure → AUTH.md steps for this agent; **stop**. Never invent API calls.
Follow **in sequence**. Early gates exist because getting them wrong corrupts live workflows.
Search Linear by repo name **and** ask the user. Never assume blank slate.
README-as-vision is usually enough — say the call out loud. Question 5 (why track?) picks the shape — see METHODOLOGY goal→shape table.
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.
CHANGELOG > roadmap > git log. Feature-level default; per-release for launched packages. Done only with evidence. Doc “done” ≠ proof — corroborate (§4.8).
Titles ≤8 words. Descriptions ≤3 sentences or ≤5 bullets. Comments ≤3 lines. Screenshots over prose (§10).
Real `blockedBy`/`blocks`. Surface UI-only items early (§11). Add README as Linear project document.
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.
Status updates at milestone/health moments only. `atRisk` before dates slip.
Rubric ≥16/20 with no load-bearing 0, or full §26 audit.
Point user to always-on (if missing) via `finish linear-tracking install`. Optional Cursor weekly health: [AUTOMATION.md](./AUTOMATION.md). One next action.
A proven methodology for building and tracking features, projects, and issues across numerous builds.
Always-on Linear session discipline and one-time soft nudge for untracked repos. Use whenever non-trivial work is happening in a…
Finish Linear tracking pack install after skills are present: write always-on rules (Linear = default source of truth every…
Proven methodology for building and tracking features, projects, and issues in Linear. Use when the user wants to set up Linear…
Health-check Linear projects for slipping dates, stale In Progress, and orphan issues. Use when the user asks for a Linear health…
Sync, audit, or rescue an existing Linear project against repo reality. Use when the user asks to sync Linear, reconcile…