| name | breaking-down-linear-issues |
| description | Linearに大きなタスクを複数のIssueに分割して作成する際に使用。新しいプロジェクトを作成し、その中にフラットなIssueを作成し、依存関係はblockedByリレーションで表現する。 |
| compatibility | Requires Linear MCP server (https://mcp.linear.app/mcp) |
Linearに大きなタスクを分割してIssueを作成する
ユーザーが大きなタスクをLinearにIssueとして登録したい場合、タスクを分割して複数のIssueを作成してください。分割する際は新しいプロジェクトを作成し、そのプロジェクト内にフラットなIssueを作成します。Issue間の関係は、階層構造ではなくblockedByリレーションで表現します。
作成したIssueはLinearを経由してLLM Agentにアサインされます。
プロンプトに特定の意図(例:「3つのIssueに分割して」「Aを先にやってからBを作成して」など)が加えられている場合は、その意図をタスク分解と依存関係の設定に反映しつつ、以下の手順を順に実行してください。
制約
- タスクを分割する際は、新しいLinearプロジェクトを作成する。
- 各Issueは独立した同等のフラットな単位として作成する。sub-issueや親子関係は作らない。
- Issue間の依存関係は、必ず
blockedBy リレーションで表現する。
- ユーザーが承認するまで、プロジェクト・Issueの作成を実行しない。
- 以下の手順を一つずつ順番に実行する。
実行手順
以下の手順で、大きなタスクを分割してLinearにIssueを作成してください。
-
入力の整理
ユーザーから以下の情報を確認する。情報が不足している場合は、ユーザーに確認を取る。
- タスクの概要(タイトル・目的)
- 作成するプロジェクト名
- Linearのチーム(Team)
- プロジェクト概要に記載すべき内容(背景、スコープ、制約、達成条件、関連リンクなど)
- 分割したい作業単位
- 各作業の依存関係(どのIssueがどのIssueにブロックされるか)
-
タスクの分解
ユーザーから得た情報に基づき、タスクを意味のある単位に分割する。
- 各Issueは独立して完了可能な単位にすること
- 1つのIssueは、diffが500〜1000行程度になるようなPRに対応するサイズにすること
- 分割したIssue間の依存関係を明確にすること
-
作成内容の確認
ユーザーに以下を提示し、承認を得てから作成を実行する。
- 作成するプロジェクト名とプロジェクト概要(背景、スコープ、制約、達成条件、関連リンク)
- 作成するIssueの一覧(タイトルと説明)
- 各Issue間の依存関係(
blockedBy で表現)
- 所属チーム
-
プロジェクトの作成
承認を得たら、Linear MCP serverを使ってプロジェクトを作成する。
- プロジェクト名、所属チーム、プロジェクト概要を設定する
- プロジェクト概要には個別Issueの詳細を書かず、背景・スコープ・制約・達成条件・関連リンクなどを記載する
- 作成後にプロジェクトIDを記録する
-
Issueの作成
作成したプロジェクト内に、Linear MCP serverを使ってIssueを作成する。各Issueは単独で見てもself-containedで分かる形にし、以下を含める。
- タイトル
- 目的(なぜやるか)
- 背景
- 作業内容
- 受け入れ条件
- 制約
- 関連リンク
- 該当ファイルや行
- プロジェクトのリンク
- 依存関係の確認手順
- 作業前にプロジェクト内のIssueを確認する
- 自身の
blockedBy に設定されているIssue(前段のタスク)を読み、どのような内容かを把握する
- 自身を
blockedBy に設定しているIssue(後段のタスク)を読み、後段で何を行うためには今回のタスクで何が必要かを把握する
- 前段・後段のタスク内容を踏まえて、今回のタスクの作業内容と受け入れ条件を調整する
- 各Issueを個別に作成する
- 作成するIssueに作成したプロジェクトを紐付ける
- 作成後に各IssueのID(identifierまたはUUID)を記録する
-
blockedByリレーションの設定
作成したIssue間で依存関係がある場合は、必ずblockedByリレーションで設定する。
- 前提となるIssueを、後続のIssueの
blockedBy に設定する
blockedBy の方向に注意する
-
結果の報告
ユーザーに以下を報告する。
- 作成したプロジェクトの名前とURL
- 作成したIssueのタイトルとURL
- 設定した
blockedByの一覧
- 次に行うべき作業(あれば)
依存関係の表現
| 状況 | 表現方法 | 理由 |
|---|
| Issue A が Issue B の完了を待っている | Issue B を Issue A の blockedBy に設定 | B が完了するまで A が進めないという関係を表現 |
| 同じ Issue が複数の Issue にブロックされている | 複数の blockedBy リレーションを設定 | 複数の依存関係を並列で表現 |
| 特に依存関係がない | blockedBy を設定しない | 依存関係がない場合は無理に作らない |
例
入力
「ユーザー認証機能を作りたい。大きなタスクなので分割してIssueを作成してほしい。」
プロジェクト
- プロジェクト名: ユーザー認証機能
- 概要:
- なぜやるか: 現在の認証は管理画面のみで、一般ユーザー向けログインがない
- 背景: 新規サービス公開に向けて、メール/パスワード認証とソーシャル認証が必要
- スコープ:
- やること: メール/パスワードログイン、ログイン画面UI、認証APIの実装・テスト、フロントエンド連携
- やらないこと: SSO、管理画面認証の改修、パスワードリセット
- 制約: 既存の管理画面認証基盤を流用し、SSOは今回のスコープ外
- 達成条件: 一般ユーザーがログインし、セッションを維持できる状態になる
- 関連リンク: https://example.com/requirements/auth
分割結果
- ログイン画面のUI作成
- 認証APIの実装
- 認証APIのテスト作成
- フロントエンドと認証APIの連携
Issueの記載例(認証APIの実装)
- 目的: 一般ユーザーがメール/パスワードでログインできるAPIを提供する
- 背景: 新規サービス公開に向けて、メール/パスワード認証が必要
- 作業内容:
src/auth/login.ts にログインエンドポイントを実装する
- パスワードハッシュの検証処理を追加する
- 受け入れ条件:
/api/login が正しい認証情報で200を返し、JWTを発行すること
- 制約: 既存の管理画面認証基盤を流用する。SSOは今回のスコープ外
- 関連リンク:
- 該当ファイル:
src/auth/login.ts
- 依存関係の確認手順:
- 作業前にプロジェクト「ユーザー認証機能」内のIssueを確認する
- 自身の
blockedBy に設定されているIssue(前段のタスク)を読み、どのような内容かを把握する
- 自身を
blockedBy に設定しているIssue(後段のタスク)を読み、後段で何を行うためには今回のタスクで何が必要かを把握する
- 前段・後段のタスク内容を踏まえて、今回のタスクの作業内容と受け入れ条件を調整する
依存関係
- 認証APIのテスト作成は、認証APIの実装にブロックされる
- フロントエンドと認証APIの連携は、ログイン画面のUI作成と認証APIの実装にブロックされる
実行後の状態
- プロジェクト「ユーザー認証機能」を作成
- 認証APIのテスト作成 (
blockedBy: 認証APIの実装)
- フロントエンドと認証APIの連携 (
blockedBy: ログイン画面のUI作成)
- フロントエンドと認証APIの連携 (
blockedBy: 認証APIの実装)