linear-issue

Linear Issue Analysis

Linear の課題 $ARGUMENTS に取り組みます

前提条件

このスキルは外部ツールに依存します。続行する前に、利用可能か確認してください。

必須：

• Linear MCP（mcp__linear）：接続されている必要があります。接続されていない場合、このスキルはまったく機能しません。
• GitHub CLI（gh）：インストールされ、認証済みである必要があります。gh auth status を実行して確認してください。リンクされた PR と課題の取得に使用します。

任意（利用できない場合も適切に対応）：

• Notion MCP（mcp__notion）：課題に Notion ドキュメントへのリンクがある場合のみ必要です。利用できない場合は、概要に Notion のリンクを記載し、ユーザーに手動で確認するよう伝えてください。
• Loom transcript スキル（/loom-transcript）：課題に Loom 動画が含まれる場合のみ必要です。利用できない場合は、ユーザーが視聴できるよう概要に Loom のリンクを記載してください。
• curl：画像のダウンロードに使用します。ほとんどの場合は利用できます。利用できない場合は、画像のダウンロードをスキップして、その旨を記載してください。

必須ツールが不足している場合は停止し、続行する前に何を設定する必要があるかユーザーに伝えてください。

手順

課題に関する包括的なコンテキストを収集するには、次の手順に従ってください。

1. Linear から課題とコメントを取得する

Linear MCP ツールを使い、課題の詳細とコメントをまとめて取得します。

• mcp__linear__get_issue を課題 ID とともに使用し、添付ファイルを含む詳細情報を取得します
• 関連する課題、ブロックしている課題、重複する課題を確認するため、関連情報も含めます
• 直後に、mcp__linear__list_comments を課題 ID とともに使用し、すべてのコメントを取得します

完全なコンテキストを最初にまとめて把握できるよう、両方の呼び出しを同じ手順内で行ってください。

2. 添付ファイルとメディアを分析する（必須）

重要： この手順は省略できません。課題の説明とすべてのコメントの両方から、視覚的なコンテンツをすべて確認し、取得する必要があります。

スクリーンショット／画像（必ず取得）：

1. 課題の説明とすべてのコメントを確認し、すべての画像 URL を探します。
   • <img> タグ
   • Markdown 画像 ![](url)
   • 生の URL（github.com/user-attachments、imgur.com など）
2. 見つかった画像ごとに（説明またはコメント内）：
   • curl -sL "url" -o /path/to/image.png を使ってダウンロードします（GitHub URL ではリダイレクトへの追従が必要です）。または Linear MCP を使用します
   • ダウンロードしたファイルを Read ツールで開いて確認します
   • 画像に何が表示されているか、詳しく説明します
3. 画像を省略しないでください。エラーメッセージ、UI の状態、設定など、重要なコンテキストが含まれていることがよくあります

Loom 動画（必ずトランスクリプトを取得）：

1. 課題の説明とすべてのコメントを確認し、Loom URL（loom.com/share/...）を探します
2. 見つかった動画ごとに（説明またはコメント内）：
   • /loom-transcript スキルを使って、トランスクリプト全文を取得します
   • 重要なポイント、タイムスタンプ、実演された問題を要約します
3. Loom 動画には、テキストだけでは伝わらない重要な再現手順やコンテキストが含まれていることがよくあります

3. 関連するコンテキストを取得する

関連する Linear の課題：

• 関連情報に記載された課題（ブロックしている課題、ブロックされている課題、関連する課題、重複する課題）について、mcp__linear__get_issue を使用します
• それらがメインの課題とどのように関連しているかを要約します

GitHub の PR と課題：

• GitHub のリンクが記載されている場合は、gh CLI を使って PR／課題の詳細を取得します。
  • プルリクエストには gh pr view <number> を使用します
  • 課題には gh issue view <number> を使用します
• 課題に添付された画像をダウンロードします：curl -H "Authorization: token $(gh auth token)" -L <image-url> -o image.png

Notion ドキュメント：

• Notion のリンクがある場合は、Notion URL またはページ ID とともに mcp__notion__notion-fetch を使用し、ドキュメントの内容を取得します
• 関連するドキュメントの内容を要約します

4. コメントを確認する

コメントは手順 1 ですでに取得しています。次の点を確認してください。

• 追加のコンテキストと議論の経緯
• コメントにリンクされた添付ファイルやメディア（手順 2 に従って処理）
• 元の課題の説明に対する補足や更新

5. 影響を受けるノードを特定する（該当する場合）

この問題が特定の n8n ノード（トリガー、アクション、ツールノードなど）に固有のものかどうかを判断します。以下から手がかりを探してください。

• 問題のタイトル（例：「Linear trigger」「Slack node」「HTTP Request」）
• ノード名に言及している問題の説明やコメント
• 問題に付けられたラベルやタグ（例：node:linear、node:slack）
• 特定のノードの設定やエラーが表示されているスクリーンショット

問題が特定のノードに固有のものである場合：

1. ノードタイプ ID を調べます。 Grep を使って packages/frontend/editor-ui/data/node-popularity.json 内でノードの表示名（または関連キーワード）を検索し、正確なノードタイプ ID を特定します。参考として、一般的な ID のパターンは次のとおりです。

   • コアノード：n8n-nodes-base.<camelCaseName>（例：「HTTP Request」→ n8n-nodes-base.httpRequest）
   • トリガーのバリエーション：n8n-nodes-base.<name>Trigger（例：「Gmail Trigger」→ n8n-nodes-base.gmailTrigger）
   • ツールのバリエーション：n8n-nodes-base.<name>Tool（例：「Google Sheets Tool」→ n8n-nodes-base.googleSheetsTool）
   • LangChain／AI ノード：@n8n/n8n-nodes-langchain.<camelCaseName>（例：「OpenAI Chat Model」→ @n8n/n8n-nodes-langchain.lmChatOpenAi）

2. packages/frontend/editor-ui/data/node-popularity.json からノードの人気度スコアを調べます。Grep を使ってこのファイル内でノード ID を検索します。人気度スコアは、0～1 の対数スケールの値です。次のしきい値を使って分類してください。

   スコア	レベル	説明	例
   ≥ 0.8	High	コア／広く使われているノード、上位約 5%	HTTP Request（0.98）、Google Sheets（0.95）、Postgres（0.83）、Gmail Trigger（0.80）
   0.4–0.8	Medium	定期的に使われているインテグレーション	Slack（0.78）、GitHub（0.64）、Jira（0.65）、MongoDB（0.63）
   < 0.4	Low	ニッチ、または使用頻度の低いノード	Amqp（0.34）、Wise（0.36）、CraftMyPdf（0.33）

   概要には、未加工のスコアとレベル（high／medium／low）を記載します。

3. 人気度ファイルにノードが見つからない場合は、コミュニティノード、または非常に新しい／ニッチなノードの可能性があることを記載します。

6. 作業量／複雑さを評価する

すべての背景情報を集めた後、問題の修正／実装に必要な作業量を評価します。次の T シャツサイズを使用してください。

サイズ	おおよその作業量
XS	≤ 1 時間
S	≤ 1 日
M	2～3 日
L	3～5 日
XL	≥ 6 日

この評価では、次の点を考慮してください。

• 変更範囲：変更が必要なファイル／パッケージはいくつですか？単一ノードの修正ですか、それとも複数領域にまたがる変更ですか？
• 複雑さ：単純なパラメーターの変更、新しい API インテグレーション、新しい認証情報タイプ、またはアーキテクチャの変更ですか？
• テスト：どの程度のテストカバレッジが必要ですか？E2E テストは必要ですか？
• リスク：既存の機能に影響する可能性はありますか？後方互換性への対応は必要ですか？
• 依存関係：外部 API の変更、新しいパッケージ、またはチーム間の調整が必要ですか？
• ドキュメント：ドキュメントの更新、移行ガイド、または変更履歴への記載が必要ですか？

主な見積もり要因を説明する簡潔な根拠とともに、T シャツサイズを提示してください。

7. まとめの提示

提示する前に、次の項目がすべて完了していることを確認してください。

• 説明欄とコメント欄にあるすべての画像をダウンロードして確認した
• 説明欄とコメント欄にあるすべての Loom 動画のトランスクリプトを取得した
• リンクされているすべての GitHub の issue／PR を gh CLI で取得した
• issue のすべてのコメントを一覧表示した
• issue が特定のノードに関するものかどうかを確認し、該当する場合は人気度を調べた
• T シャツサイズで工数／複雑さを評価した

すべてのコンテキストを収集したら、次の項目を含む包括的なまとめを提示してください。

1. Issue の概要：タイトル、ステータス、優先度、担当者、ラベル
2. 説明：コメントによる補足を含む issue の説明全文
3. 視覚的なコンテキスト：スクリーンショット／動画の要約（それぞれで確認した内容）
4. 対象ノード（該当する場合）：ノード名、ノードタイプ ID（n8n-nodes-base.xxx）、レベル付きの人気度スコア（例：0.64 — 人気度：中）
5. 関連する issue：他の作業との関連性
6. 技術的なコンテキスト：PR、コード参照、ドキュメント
7. 工数の見積もり：T シャツサイズ（XS／S／M／L／XL）とその根拠
8. 次のステップ：収集したすべてのコンテキストに基づく推奨アプローチ

注記

• issue ID は AI-1975、node-1975、または 1975 のような形式で指定できます（検索します）。
• issue ID が指定されていない場合は、ユーザーに尋ねてください。