linear-pm

モード：認知／プロンプト駆動型 - 単独のユーティリティスクリプトはありません。エージェントのコンテキストを通じて使用します。

Linear PM スキル

概要

このスキルでは、コンテキストの使用を最適化するために段階的開示を採用し、Linear の包括的なプロジェクト管理機能を提供します。

コンテキストの節約：約92％削減

• 直接 API モード：API ドキュメント全体で約15,000トークン
• スキルモード：メタデータ約300トークン＋必要に応じた読み込み

要件

• 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 は 1 時間あたり 1500 リクエスト、REST は 1 時間あたり 500 リクエストです
3. クエリ構文を検証する：GraphQL クエリが正しい形式であることを確認します
4. チーム／Issue ID を確認する：ID が存在し、アクセス可能であることを確認します

エージェントとの連携

• planner：プロジェクト管理とバックログの優先順位付け
• developer：開発中の Issue 追跡

一般的なワークフロー

スプリント計画

1. current-cycle - 現在のスプリントを取得
2. list-issues --state Backlog - バックログ項目を取得
3. update-issue --cycle-id ... - Issue をスプリントに割り当てる

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 ... - スプリントの進捗を確認

関連情報

• Linear 公式 API ドキュメント：https://developers.linear.app/docs/graphql/working-with-the-graphql-api
• Linear GraphQL エクスプローラー：https://studio.apollographql.com/public/Linear-API/home
• Linear Webhook ドキュメント：https://developers.linear.app/docs/graphql/webhooks

鉄則

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 が重複すると追跡が分散し、チームのベロシティ指標が歪みます	作成前にタイトルフィルター（filter.title.eq フィールドを使う issues クエリ）で検索します
遷移に状態名を使う	大文字と小文字を区別します。チームが状態名を変更すると壊れ、ロケールの問題も発生します	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

中断されたことを前提としてください：メモリに記録されていなければ、実行されていないものとします。