用途：按一套明确方法论在 Linear 中初始化或扩展现有项目跟踪，而不是直接做 API 增删改查。适合用户提出「设置 Linear 跟踪」「在 Linear 中跟踪这个项目」等请求时使用。
主要能力与流程：先做第 0 步认证，探测 Linear MCP，失败则按 AUTH.md 处理并停止，不臆造 API 调用。随后按顺序执行：第 1 步用仓库名在 Linear 中搜索并询问用户，确认是否已被跟踪，绝不自作主张视为全新项目；若无则新建，若存在则停止并先枚举 issues、milestones、labels、docs、status updates，逐类确认后再谨慎扩展。第 2 步确定 North Star，README 即愿景通常足够，并按「为什么跟踪」选择形态。第 3–4 步确定类型与结构，建议类型为 Product / Tool / Drop / Marketing，里程碑与真实阶段 1:1，分离工程、发布与推广轨道，日期只在有真实信号时使用。第 5 步回填，来源优先级为 CHANGELOG、roadmap、git log，默认特性级，已发布包按版本级，只有证据充分才算完成，文档标注 done 不等于证据。工单写法：标题不超过 8 个词，描述不超过 3 句或 5 个要点，评论不超过 3 行，优先截图。第 6 步接线：建立真实的 blockedBy/blocks 关系，尽早暴露仅 UI 的条目，把 README 作为 Linear 项目文档加入。第 7 步安装纪律：将跟踪协议写入始终加载的代理指令（CLAUDE.md / AGENTS.md / .cursor/rules/），并用真实团队、项目、里程碑名称，未完成此步则初始化不算完成。第 8 步诚实：仅在里程碑或健康度节点写状态更新，日期还没滑就标 atRisk。第 9 步完成检查：评分不低于 16/20 且没有承重项为 0，或做完整审计。
完成后：指引用户通过 finish linear-tracking install 完成始终开启配置，可选 Cursor 每周健康检查见 AUTOMATION.md，并只给出一个下一步动作。
限制：需先通过 Linear MCP 认证，否则停止；不提供具体 API 调用；文档中的评分标准、审计细节与自动化配置仅在引用文件中，本资料未展开；官方文本暂未提供。