Bootstrap or extend Linear project tracking with evidence-based backfill, milestones, dependencies, and repository discipline.
Real-world examples not captured yet
This skill shows a gallery of live HTML demos (CDN libraries welcome — GSAP, Three.js, etc.) rendered inline via srcdoc.
Skill markdown
# Linear setup Chat rules: [RESPONSE.md](./RESPONSE.md). Auth: [AUTH.md](./AUTH.md). Full method: [METHODOLOGY.md](./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](./AUTOMATION.md). One next action.
More from tjcages
- Linear DisciplineKeep Linear tracking honest during development with search-before-create, lifecycle updates, and close-the-loop discipline.
- Linear Finish InstallComplete Linear tracking installation by writing always-on rules and verifying Linear MCP authentication.
- Linear MethodologyRoute Linear tracking work through a methodology for setting up, syncing, monitoring, and maintaining honest project data.
- Linear MonitorHealth-check Linear projects for slipping dates, stale in-progress work, orphan issues, and tracking anti-patterns.
- Linear SyncAudit and rescue an existing Linear project by reconciling its issues, milestones, dependencies, and tracking protocol with repository reality.