Linear项目管理Skill：用自然语言驱动 Linear 的问题、项目与团队工作流
- 一句话定位：把 Linear 的问题、项目、文档和团队协作能力接入 Codex，通过 Linear MCP 服务器用自然语言完成读、建、改的完整闭环。
- 核心能力：覆盖问题管理、项目与团队、文档与协作三大类工具集，支持冲刺规划、错误分类、文档审计、负载平衡等 9 类实用工作流。
- 使用门槛：需要 Linear 工作区权限 + Codex 环境 + 一次 OAuth 授权，安装为三条命令级别的操作。
- 最大差异点：不是"又一个看板工具"，而是把 AI 变成 Linear 里的执行者——先读后写、批量分批、结果可追溯。
- 适合谁用：研发负责人、项目经理、技术团队中的"流程维护者"，以及任何被工单整理和状态同步消耗大量时间的人。
该技能叫什么？如何下载安装 AI 技能提升开发效率？
这个技能的中文名是 Linear项目管理Skill，英文名是 linear，技能 ID 为 12033。它的官方简短描述是"在 Codex 中管理 Linear 问题"，完整定位是：在 Linear 中管理问题、项目和团队工作流，当用户想在 Linear 中读取、创建或更新工单时使用。
它解决的核心问题是**"工具在 Linear，脑子在对话里"的割裂感**。传统做法是：你在和 AI 讨论完需求拆解后，还要切到浏览器，一个个手动建工单、填优先级、打标签、拉进周期。这个技能把这段重复劳动收回到对话中——AI 直接调用 Linear MCP 服务器提供的工具，替你完成读取与写入。
安装前提
根据技能详情，使用前需要满足两个先决条件：
- Linear MCP 服务器必须通过 OAuth 连接并可访问；
- 确认访问相关的 Linear 工作区、团队和项目（否则会出现"连上了但看不到数据"的情况）。
一键安装步骤
技能详情给出了明确的接入流程，按顺序执行即可：
第一步：添加 Linear MCP 服务器
codex mcp add linear --url https://mcp.linear.app/mcp
第二步：启用远程 MCP 客户端
两种方式任选其一：在 config.toml 中设置 [features] rmcp_client = true，或者运行时执行：
codex --enable rmcp_client
第三步：使用 OAuth 登录
codex mcp login linear
第四步：重启 Codex
详情特别提示：成功登录后用户需要重启 Codex，然后再次尝试时即可继续步骤 1 的正式工作流。
Windows / WSL 用户注意：如果在 Windows 上遇到连接错误，可以改为让 Linear MCP 通过 WSL 运行，配置形如：
{"mcpServers": {"linear": {"command": "wsl", "args": ["npx", "-y", "mcp-remote", "https://mcp.linear.app/sse", "--transport", "sse-only"]}}}
如何验证是否生效
安装完成后，最轻量的验证方式是提一个自然语言请求，例如"列出我的 Linear 团队"或"显示分配给我的未完成问题"。如果技能能正常返回团队列表或问题清单，说明 MCP 连接与 OAuth 授权都已生效；如果任何 MCP 调用因"未连接"而失败，就回到上面的步骤 0 重新配置。至于账号套餐、工作区席位等商业信息，请以 Linear 官方说明为准。
该技能的主要功能和特点
技能详情提供了三组工具集，这是它"能做什么"的边界，也是它区别于普通对话式助手的底气：
问题管理类
list_issues、get_issue：列出与查看问题详情，是构建上下文的第一步；create_issue、update_issue：新建与更新工单，可填写优先级、标签、截止日期等字段；list_my_issues：只把"我的问题"捞出来，适合每日站会前的自查；list_issue_statuses：读取状态定义，避免自造一个 Linear 里不存在的状态；list_issue_labels、create_issue_label：读取并新建标签，让"智能标签"这类工作流真正落地。
项目与团队类
list_projects、get_project、create_project、update_project：项目维度的读与写，支撑"发布规划"场景；list_teams、get_team：确认团队键（team key），这是创建问题时的必填标识；list_users：获取成员列表，用于负载分析与重新分配。
文档与协作类
list_documents、get_document、search_documentation：全文检索文档，支撑"文档审计"；list_comments、create_comment：读评论与补评论，让状态更新留在工单里而不是聊天群里；list_cycles：读取周期（Cycle），支撑冲刺规划与回顾。
和普通工具比强在哪？
- 先读后写：强制"先 list/get/search 构建上下文，再 create/update"，避免 AI 不看现状就乱写；
- 批量有逻辑：批量操作前要求解释分组逻辑，减少误伤；
- 标识符确认：调用工具前先确认问题 ID、项目 ID、团队键，降低"建错项目"的概率；
- 内置 9 类工作流范式：冲刺规划、错误分类、文档审计、团队负载平衡、发布规划、跨项目依赖、自动化状态更新、智能标签、冲刺回顾，拿来即用。
如何使用该技能？
技能详情规定了一套不可跳过的顺序工作流，这是使用它的正确姿势：
步骤 0：检查 MCP 是否就绪。 如果调用失败并提示 Linear MCP 未连接，先按上一节完成安装与 OAuth 登录。
步骤 1：澄清目标与范围。 先说明你要做的是问题分类、冲刺规划、文档审计还是负载平衡，并确认团队/项目、优先级、标签、周期和截止日期。
示例输入：
“帮我梳理一下『支付团队』这个周期里所有高优先级但还没人认领的 bug，按用户影响排序，把前 3 个移到进行中，并各加一条说明评论。”
步骤 2：选择工作流并确定工具。 AI 会判断需要 list_issues 拉数据、list_users 看归属、update_issue 改状态、create_comment 补评论，并在调用前跟你确认团队键或问题 ID。
步骤 3：按逻辑分批执行。 先读取构建上下文，再创建或更新并填齐必填字段；涉及批量变更时，会先解释分组逻辑（比如"按优先级分两批，P0 先动"）。
步骤 4：总结结果并提议下一步。 输出会指出剩余的缺口或障碍，例如"还有 4 个问题缺标签"“2 个问题没有估算”，并建议追加问题、改标签、重新分配或补跟进评论。
预期输出形态：一段结构化的执行报告——做了什么变更、影响了哪些工单、还剩哪些待办，以及建议的下一步动作。它不会只回你一句"已完成"。
提升成功率的三个提示（来自技能的生产力建议）：把相关修改合并成批次；尽量用自然语言查询，例如"显示约翰本周在做什么"；在新请求里引用先前讨论过的问题，让上下文自动延续。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| Linear项目管理Skill（linear） | AI 通过 Linear MCP 直接读写项目数据 | 问题/项目/文档/评论全链路工具，9 类预设工作流 | 需 Codex 环境 + Linear MCP + OAuth 授权，三条命令级安装 | 冲刺规划、错误分类、负载平衡、文档审计、冲刺回顾 | 优势：自然语言驱动、先读后写、可批量；不足：强依赖 MCP 连接稳定性与工作区权限 |
| Linear 官方网页/客户端手动操作 | 原生项目管理界面 | 全部原生功能，交互直观 | 无额外门槛，登录即用 | 日常看板维护、精细字段编辑 | 优势：功能最全、零学习成本；不足：重复性操作全靠手工，批量整理耗时 |
| Jira + 内置 AI 能力 | 老牌企业级项目管理平台 | 工作流配置、报表、与研发工具链集成 | 需部署与权限配置，工作流定制成本较高 | 大型组织、复杂审批流 | 优势：生态成熟、可定制性强；不足：配置复杂，轻量团队容易"工具过重" |
| GitHub Issues / Projects + 代码助手 | 与代码仓库深度绑定的任务管理 | 问题跟踪、看板、与提交/PR 关联 | 仓库级开通，几乎零成本 | 开源项目、小团队研发协作 | 优势：与代码零距离；不足：项目管理层能力（周期、里程碑、负载）相对薄弱 |
怎么选：如果你的团队已经在用 Linear，这个技能是"给现有工具装一个 AI 执行层"，边际成本最低；如果项目管理需求本身很轻，GitHub Issues 足够；如果组织需要复杂审批与合规报表，Jira 仍是稳妥选择。具体价格与套餐差异请以各家官方说明为准。
该技能的典型应用场景与实际体验情况
场景一：研发负责人的冲刺规划
痛点：每两周手动翻一遍 Backlog，挑优先级、估点、拉进新周期，至少半天。使用方式：让技能"审查目标团队的开放问题，按优先级挑出顶部项目，创建 Q1 性能冲刺周期并完成分配"。实际体验：上手不难，关键是先把团队键和目标说清楚；效果取决于 Backlog 数据本身是否干净，脏数据会被如实放大成"待清理项"。
场景二：QA 与值班同学的错误分类
痛点：线上问题堆积，谁严重谁不严重靠感觉。使用方式：让技能"列出关键/高优先级错误，按用户影响排序，把顶部项目移到进行中"。实际体验：这类读取 + 小批量更新的任务最稳，风险低；注意批量更新要分批，避免撞上 Linear API 的速率限制。
场景三：技术写作者与文档负责人做文档审计
痛点：API 文档更新滞后，没人系统盘过缺口。使用方式：搜索文档（例如 API 认证相关章节），然后为缺口或过时部分批量创建标记为"文档"的问题，并附上详细修复说明。实际体验：搜索类工具（search_documentation）配合 create_issue 的组合效率很高；建议先小范围试跑一批，确认标签和模板符合团队习惯。
场景四：项目经理做团队负载平衡与状态同步
痛点：谁手上活儿多全靠猜，周报靠翻记录。使用方式：让技能按受让人分组统计活跃问题，标记高负载者并建议或执行重新分配；或者找出"陈旧更新"的问题，根据当前状态补一条状态评论。实际体验：list_users + list_issues 的组合能快速出结论；重新分配属于写操作，建议先让 AI 给建议、人工确认后再落库。
通用体验总结：上手难度低（会说话就会用），但效果上限由"你把需求说得多清楚"决定。务必带上团队、项目、优先级、截止日期这些约束条件；同时留意速率限制，频繁列表查询时尽量复用过滤条件。
该技能能为用户带来的价值
效率层面：把"讨论 → 拆解 → 建单 → 打标 → 拉周期 → 补评论"这条链路从多次页面切换压缩成一次对话。批量创建与批量更新是把分钟级手工操作变成秒级指令的关键，冲刺规划和错误分类这类周期性工作收益最明显。
门槛层面：新人不熟悉 Linear 的字段体系（状态、标签、周期、估算）也能快速产出规范工单——技能会主动确认必填字段和标识符，相当于内置了一位"流程守门人"。
质量层面：强制"先读后写"和"批量前解释分组逻辑"，把 AI 最容易犯的"凭空创建、重复创建、改错对象"三类错误挡在前面；步骤 4 的缺口总结还会主动暴露"缺标签""缺估算"这类隐性债务。
长期价值：当工单数据持续被结构化沉淀，冲刺回顾、负载分析、依赖梳理才有可靠输入。技能详情中的"冲刺回顾"工作流正是把这种沉淀转成改进动作的出口——生成上一周期报告，标注完成与延后工作，并为反复出现的模式开讨论问题。流程越跑越顺，是这个技能真正的复利所在。
常见问题 FAQ
Q1：怎么安装？一定要用命令行吗？
按技能详情，标准路径是三条命令：codex mcp add linear --url https://mcp.linear.app/mcp 添加服务器、在 config.toml 设置 [features] rmcp_client = true 或加 --enable rmcp_client 启用远程客户端、codex mcp login linear 完成 OAuth 登录，最后重启 Codex。Windows 用户若遇连接错误，可改用 WSL 方式运行。是否提供图形化入口请以 Codex 官方说明为准。
Q2：这个技能收费吗？
技能本身在详情中没有给出任何价格信息，属于接入层能力；但 Linear 作为商业产品，其账号与席位可能涉及订阅费用，具体请以 Linear 官方说明为准。
Q3：登录成功了，但读不到数据怎么办？
优先排查三件事：OAuth 授权是否覆盖了目标工作区；当前账号对该团队/项目是否有访问权限；目标项目是否已被归档。技能详情的故障排除建议还包括刷新令牌、清除浏览器 cookies 后重新运行 OAuth、确认已启用 API 访问。另外要确认团队选择正确——选错团队是最常见的"数据缺失"原因。
Q4：适合谁用？小团队有必要吗？
适合研发负责人、项目经理、技术团队里负责流程维护的人。小团队同样受益：工单少的时候手工维护尚可，但一旦进入"每周几十个问题"的节奏，批量打标、状态同步、负载查看就会明显吃时间。如果你的团队本来不用 Linear，那这个技能不会替你创造需求——它解决的是"已经在用、但用得累"的问题。
Q5：和直接手动操作 Linear、或者换用 Jira / GitHub Issues 相比怎么选？
判断标准是"你现在的工具是不是瓶颈"。已经在用 Linear 且痛点在于重复操作，选这个技能，边际成本最低；项目管理需求本身很轻、强依赖代码仓库，GitHub Issues 更省事；组织需要复杂工作流与合规报表，Jira 更稳。技能详情的故障排除里也提示要留意 Linear API 速率限制——批量操作记得分批、善用具体过滤条件，这决定了它在高频使用下的实际体验。