mcpField
L
linear-pm

linear-pm

github.com/oimiragieo生产力4442 次安装17 周前更新
代码仓库

关于 linear-pm

面向 Agent 的提示驱动型 Linear 项目管理技能，需要设置 LINEAR_API_KEY 并连接互联网。覆盖问题、项目、周期、团队、标签和状态，修改数据的操作需确认。

主要功能

  1. 01管理问题和评论
  2. 02跟踪项目及关联问题
  3. 03规划周期并查看进度
  4. 04查看团队与成员
  5. 05管理标签和工作流状态
  6. 06修改操作需确认

适用场景

  1. 01整理并确定待办问题优先级
  2. 02在冲刺规划中分配问题
  3. 03查看项目问题和周期进度

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/oimiragieo/agent-studio --skill linear-pm

安装后在 Claude Code 中输入/linear-pm确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

commands/
linear-pm.md
hooks/
post-execute.cjs
pre-execute.cjs
references/
research-requirements.md
rules/
linear-pm.md
schemas/
input.schema.json
output.schema.json
scripts/
main.cjs
templates/
implementation-template.md

详细介绍

模式：认知／提示词驱动 - 无独立实用脚本；通过 Agent 上下文使用。

Linear PM 技能

概述

此技能提供全面的 Linear 项目管理功能，并采用渐进式披露，以优化上下文使用。

上下文节省：约减少 92%

  • 直接 API 模式：完整 API 文档约需 15,000 个 token
  • 技能模式：元数据约需 300 个 token，按需加载

要求

  • 已设置 LINEAR_API_KEY 环境变量
  • 可连接互联网，以访问 Linear API

工具集

工具集描述
issues创建问题、更新问题、添加评论、更改状态
projects项目管理及问题关联
cycles冲刺／周期管理与规划
teams团队结构与成员管理
labels标签与工作流状态管理

按类别划分的工具

问题操作（变更需确认）
工具描述确认
list-issues按状态、负责人、标签等筛选并列出问题否
get-issue获取问题的详细信息否
create-issue创建问题，并设置标题、描述和团队是
update-issue更新问题字段（状态、负责人、优先级）是
add-comment为问题添加评论是
search-issues按文本查询搜索问题否
assign-issue将问题分配给团队成员是
set-priority设置问题优先级（紧急、高、 中、低）是
add-label为问题添加标签是
项目操作
工具描述确认
list-projects列出团队的所有项目否
get-project获取项目详情和元数据否
project-issues获取项目中的所有问题否
create-project创建新项目是
update-project更新项目详情是
周期操作（冲刺）
工具描述确认
list-cycles列出团队的周期否
current-cycle获取当前活动周期否
cycle-issues获取特定周期中的问题否
cycle-progress获取周期完成情况指标否
团队操作
工具描述确认
list-teams列出工作区中的所有团队否
get-team获取团队详情否
team-members列出团队成员否
标签与状态操作
工具描述确认
list-labels列出团队的所有标签否
list-states列出工作流状态（待办列表、待办、进行中、已完成）否
create-label创建新标签是

安全

  • 切勿在日志或输出中泄露 LINEAR_API_KEY
  • API 密钥应仅拥有必要的最小权限
  • 所有会修改数据的工具都需要确认

错误处理

  1. 验证 API 密钥：检查是否正确设置了 LINEAR_API_KEY
  2. 检查 API 速率限制：GraphQL 每小时 1500 次请求；REST 每小时 500 次请求
  3. 验证查询语法：确保 GraphQL 查询格式正确
  4. 检查团队/Issue ID：确认 ID 存在且可访问

Agent 集成

  • planner：项目管理和待办事项优先级排序
  • developer：开发期间的 Issue 跟踪

常见工作流

Sprint 规划
  1. current-cycle - 获取当前 Sprint
  2. list-issues --state Backlog - 获取待办事项
  3. update-issue --cycle-id ... - 将 Issue 分配到 Sprint
Issue 分类
  1. list-issues --state Backlog - 获取未规划的 Issue
  2. set-priority --issue-id ... --priority 2 - 设置优先级
  3. add-label --issue-id ... --label bug - 添加分类标签
项目跟踪
  1. list-projects --team-id ... - 获取所有项目
  2. project-issues --project-id ... - 获取项目 Issue
  3. cycle-progress --cycle-id ... - 检查 Sprint 进度

相关链接

铁律

  1. 始终在进行任何 API 调用前验证是否已设置 LINEAR_API_KEY——如果密钥缺失或已过期，Linear API 会返回带有通用错误消息的 401 错误；提前验证可以生成清晰且可采取行动的错误信息。
  2. 绝不在按标题搜索之前创建重复的 Issue——Linear 不会自动去重 Issue；不经搜索就运行两次此技能会创建重复的工作项，干扰团队跟踪。
  3. 始终在转换 Issue 状态时使用状态 ID（而不是状态名称）——状态名称区分大小写、依赖区域设置，且会随团队重命名状态而改变；ID 则保持稳定。
  4. 绝不在没有筛选条件的情况下获取团队的所有 Issue——不受限制的团队查询会返回数千个 Issue，耗尽 API 速率限制，并产生无法使用的上下文信息。
  5. 始终在会话期间缓存团队和项目信息——团队 ID 和项目键在会话期间不会改变；每次操作都重新获取会浪费 API 配额并拖慢工作流。

反模式

反模式失败原因正确做法
创建 Issue 前不检查是否重复重复的 Issue 会分散跟踪记录；团队速度指标会失真创建前使用标题筛选器搜索（issues 查询中的 filter.title.eq 字段）
在状态转换中使用状态名称区分大小写；团队重命名状态时会失效；存在区域设置问题使用 workflowState { id } 查询获取稳定 ID；通过 ID 转换状态
不加筛选条件地获取团队的所有 Issue结果数以千计；触发速率限制；输出无法使用在 GraphQL 查询中按 state、assignee、cycle 或 label 筛选
每次操作都重新获取团队/项目元数据多次发出相同的 API 调用；浪费速率限制配额；执行缓慢在会话开始时获取一次团队和项目 ID；后续调用均重复使用
忽略分页游标只返回第一页；遗漏的 Issue 会导致报告不完整使用 pageInfo { hasNextPage, endCursor }，并持续分页，直到 hasNextPage: false

记忆协议（必须遵守）

开始前： 阅读 .claude/context/memory/learnings.md

完成后：

  • 新模式 -> .claude/context/memory/learnings.md
  • 发现的问题 -> .claude/context/memory/issues.md
  • 做出的决定 -> .claude/context/memory/decisions.md

假定任务会中断：如果没有记录在记忆中，就视为没有发生。

评论

支持 Markdown