Linear

Linear 技能概览

Linear 技能是做什么的

Linear 是一款面向工作流的技能，用来管理 Linear 里的 issues、projects、initiatives、labels 和 team updates。它特别适合希望把 Linear 用得更稳、更可控的用户，而不只是套一个通用提示词：既能创建和更新工作项，也能查询状态，并保持项目运营的一致性。

什么时候适合用这个 Linear 技能

如果你需要一份实用的 Linear 使用指南，尤其在意“先发现再创建”、状态维护规范，或者可重复的团队工作流，那么这个 Linear 技能很合适。它也适合那些需要在已有 Linear workspace 里少猜测、少试错地执行任务的 agents。

它的不同之处

这个技能不只是一个自然语言助手。它包含面向工具的操作指引、当 MCP 不可用时的兜底路径，以及基于仓库脚本的更复杂操作支持。对于既想要快速动作、又想要更深度自动化的场景来说，这是一个更强的 Linear 安装选择。

如何使用 Linear 技能

安装并确认工具路径

先用仓库里的 skill 命令安装 Linear 技能，然后确认当前可用的是哪种后端。这个技能默认会在可用时使用 mcp__linear，但也可以通过 Bash 回退到 linear CLI。若你只快速看仓库的一部分，优先读 SKILL.md，因为它解释了工具可用性以及会影响真实执行的安全规则。

把模糊目标变成可执行提示词

好的 Linear 使用方式，从具体输入开始：team key、item type、目标 project 或 issue key、期望状态，以及相关 labels 或 priority。不要只说“整理一下项目”，而要下达明确动作，例如：“为 ENG 创建一个 Linear issue，分配到 Phase 6A，设为 priority 2，添加 backend 和 bug 标签，并补上 acceptance criteria。” 细节越充分，匹配越准确，来回追问也越少。

先读这些文件

如果想要快速走完 Linear 安装和使用流程，先浏览 SKILL.md、README.md、CLAUDE.md、api.md 和 troubleshooting.md。然后再查看 scripts/create-issue-with-project.ts、scripts/create-project-update.ts、scripts/create-initiative-update.ts，了解精确参数和校验行为。如果你打算做自动化，还要检查 scripts/linear-ops.ts 和 scripts/linear-api.mjs。

实用工作流建议

建议把这个技能用于“先发现后创建”的流程：创建之前先检查是否已有对应的 projects 或 issues，更新前先确认状态名称，创建工作内容时优先使用信息更完整的 markdown 描述。涉及安全敏感操作时，遵循仓库里的 secret 处理模式，不要在输出或上下文里暴露 LINEAR_API_KEY。如果 MCP 缺失，也不要停下来——按技能文档里写的 CLI 路径继续。

Linear 技能常见问题

这比普通的 Linear 提示词更好吗？

是的。普通提示词可以应付一次性的请求，但 Linear 技能加入了可安装的工作流规则、后端回退逻辑，以及能让重复使用更稳定的脚本。对于需要在 issue 创建、状态更新和 project management 之间保持一致行为的场景，这一点尤其重要。

使用 Linear 技能一定要有 MCP 吗？

不需要。MCP 是受支持的，但在 MCP tools 不可用时，这个技能明确支持通过 Bash 走 CLI 路径。这样一来，Linear 技能在不同环境里更便携，也不容易因为工具接入问题而直接失败。

Linear 技能适合新手吗？

总体来说适合，只要你能说清 workspace 的基本信息：team key、issue key、project 名称，以及你想要的结果。新手真正容易卡住的，通常只是请求过于模糊。这个技能最适合那些能提供足够结构化信息、从而做出清晰 Linear 安装/使用判断的场景。

什么情况下不该用它？

如果你只需要对 Linear 做高层解释，或者任务并不涉及真实的 workspace 变更、查询或项目跟踪，就不该用这个技能。另一个不太匹配的情况是：你希望完全不用操心任何上下文，却又不提供 team、project 或 issue 信息。

如何改进 Linear 技能

补齐缺失的 workspace 信息

最大的质量提升，来自一开始就把具体的 Linear 对象和约束说清楚：team key、project 名称、issue key、目标状态、assignee、priority 和 labels。好的输入像这样：“把 ENG-123 更新为 In Review，添加 frontend 标签，并留一条简短评论说明阻塞原因。” 像“往前推进一下”这种模糊说法，只会迫使技能去猜。

不只写意图，也要写输出要求

如果你想让 Linear 使用效果更好，要明确你期望的产物：issue description、project update、initiative update 还是 comment。若你要新建 issue，请附上 acceptance criteria 或简短模板。若你要 project update，请给出 markdown 大纲，以及你希望体现的状态信号，例如 onTrack、atRisk 或 offTrack。

注意常见失败模式

最常见的失败原因是歧义：project 名称不完整、缺少 team key，或者想更新状态却没有 state ID 或 state name。另一个常见问题是还没先发现就直接要求创建。这个技能的表现通常是先搜索，再在确认目标不存在时创建。

在第一次结果基础上继续迭代

如果第一次结果已经接近，但还不够准确，不要把整个请求重说一遍，而是补上缺失的约束。比如加上“沿用现有 project description 风格”、“匹配团队的 label 分类体系”或“把更新控制在 120 词以内”。这种迭代方式比泛泛改写更能提升 Linear 技能的实际效果，也更接近真实 project management 的需求。