Linearに大きなタスクを分割してIssueを作成する

ユーザーが大きなタスクをLinearにIssueとして登録したい場合、タスクを分割して複数のIssueを作成してください。分割する際は新しいプロジェクトを作成し、そのプロジェクト内にフラットなIssueを作成します。Issue間の関係は、階層構造ではなくblockedByリレーションで表現します。

作成したIssueはLinearを経由してLLM Agentにアサインされます。

プロンプトに特定の意図（例：「3つのIssueに分割して」「Aを先にやってからBを作成して」など）が加えられている場合は、その意図をタスク分解と依存関係の設定に反映しつつ、以下の手順を順に実行してください。

制約

<important>

• タスクを分割する際は、新しいLinearプロジェクトを作成する。
• 各Issueは独立した同等のフラットな単位として作成する。sub-issueや親子関係は作らない。
• Issue間の依存関係は、必ず blockedBy リレーションで表現する。
• ユーザーが承認するまで、プロジェクト・Issueの作成を実行しない。
• 以下の手順を一つずつ順番に実行する。

</important>

実行手順

<procedure>

以下の手順で、大きなタスクを分割してLinearにIssueを作成してください。

1. 入力の整理

   ユーザーから以下の情報を確認する。情報が不足している場合は、ユーザーに確認を取る。

   • タスクの概要（タイトル・目的）
   • 作成するプロジェクト名
   • Linearのチーム（Team）
   • プロジェクト概要に記載すべき内容（背景、スコープ、制約、達成条件、関連リンクなど）
   • 分割したい作業単位
   • 各作業の依存関係（どのIssueがどのIssueにブロックされるか）

2. タスクの分解

   ユーザーから得た情報に基づき、タスクを意味のある単位に分割する。

   • 各Issueは独立して完了可能な単位にすること
   • 1つのIssueは、diffが500〜1000行程度になるようなPRに対応するサイズにすること
   • 分割したIssue間の依存関係を明確にすること

3. 作成内容の確認

   ユーザーに以下を提示し、承認を得てから作成を実行する。

   • 作成するプロジェクト名とプロジェクト概要（背景、スコープ、制約、達成条件、関連リンク）
   • 作成するIssueの一覧（タイトルと説明）
   • 各Issue間の依存関係（blockedBy で表現）
   • 所属チーム

4. プロジェクトの作成

   承認を得たら、Linear MCP serverを使ってプロジェクトを作成する。

   # Linear MCP server を使って project を作成する例（mcp_call_tool で実行）
   # Linear project create のスキーマに従って引数を指定する
   

   • プロジェクト名、所属チーム、プロジェクト概要を設定する
   • プロジェクト概要には個別Issueの詳細を書かず、背景・スコープ・制約・達成条件・関連リンクなどを記載する
   • 作成後にプロジェクトIDを記録する

5. Issueの作成

   作成したプロジェクト内に、Linear MCP serverを使ってIssueを作成する。各Issueは単独で見てもself-containedで分かる形にし、以下を含める。

   • タイトル
   • 目的（なぜやるか）
   • 背景
   • 作業内容
   • 受け入れ条件
   • 制約
   • 関連リンク
   • 該当ファイルや行
   • プロジェクトのリンク
   • 依存関係の確認手順
     • 作業前にプロジェクト内のIssueを確認する
     • 自身の blockedBy に設定されているIssue（前段のタスク）を読み、どのような内容かを把握する
     • 自身を blockedBy に設定しているIssue（後段のタスク）を読み、後段で何を行うためには今回のタスクで何が必要かを把握する
     • 前段・後段のタスク内容を踏まえて、今回のタスクの作業内容と受け入れ条件を調整する

   # Linear MCP server を使って issue を作成する例（mcp_call_tool で実行）
   # Linear issue create のスキーマに従って引数を指定する
   

   • 各Issueを個別に作成する
   • 作成するIssueに作成したプロジェクトを紐付ける
   • 作成後に各IssueのID（identifierまたはUUID）を記録する

6. blockedByリレーションの設定

   作成したIssue間で依存関係がある場合は、必ずblockedByリレーションで設定する。

   • 前提となるIssueを、後続のIssueの blockedBy に設定する
   • blockedBy の方向に注意する

7. 結果の報告

   ユーザーに以下を報告する。

   • 作成したプロジェクトの名前とURL
   • 作成したIssueのタイトルとURL
   • 設定したblockedByの一覧
   • 次に行うべき作業（あれば）

</procedure>

依存関係の表現

<decision-criteria name="dependency-expression">

状況	表現方法	理由
Issue A が Issue B の完了を待っている	Issue B を Issue A の blockedBy に設定	B が完了するまで A が進めないという関係を表現
同じ Issue が複数の Issue にブロックされている	複数の blockedBy リレーションを設定	複数の依存関係を並列で表現
特に依存関係がない	blockedBy を設定しない	依存関係がない場合は無理に作らない

</decision-criteria>

例

<example name="split-issue">

入力

「ユーザー認証機能を作りたい。大きなタスクなので分割してIssueを作成してほしい。」

プロジェクト

• プロジェクト名: ユーザー認証機能
• 概要:
  • なぜやるか: 現在の認証は管理画面のみで、一般ユーザー向けログインがない
  • 背景: 新規サービス公開に向けて、メール/パスワード認証とソーシャル認証が必要
  • スコープ:
    • やること: メール/パスワードログイン、ログイン画面UI、認証APIの実装・テスト、フロントエンド連携
    • やらないこと: SSO、管理画面認証の改修、パスワードリセット
  • 制約: 既存の管理画面認証基盤を流用し、SSOは今回のスコープ外
  • 達成条件: 一般ユーザーがログインし、セッションを維持できる状態になる
  • 関連リンク: https://example.com/requirements/auth

分割結果

1. ログイン画面のUI作成
2. 認証APIの実装
3. 認証APIのテスト作成
4. フロントエンドと認証APIの連携

Issueの記載例（認証APIの実装）

• 目的: 一般ユーザーがメール/パスワードでログインできるAPIを提供する
• 背景: 新規サービス公開に向けて、メール/パスワード認証が必要
• 作業内容:
  • src/auth/login.ts にログインエンドポイントを実装する
  • パスワードハッシュの検証処理を追加する
• 受け入れ条件: /api/login が正しい認証情報で200を返し、JWTを発行すること
• 制約: 既存の管理画面認証基盤を流用する。SSOは今回のスコープ外
• 関連リンク:
  • プロジェクト: https://linear.app/project/ユーザー認証機能
  • 要件: https://example.com/requirements/auth
• 該当ファイル: src/auth/login.ts
• 依存関係の確認手順:
  • 作業前にプロジェクト「ユーザー認証機能」内のIssueを確認する
  • 自身の blockedBy に設定されているIssue（前段のタスク）を読み、どのような内容かを把握する
  • 自身を blockedBy に設定しているIssue（後段のタスク）を読み、後段で何を行うためには今回のタスクで何が必要かを把握する
  • 前段・後段のタスク内容を踏まえて、今回のタスクの作業内容と受け入れ条件を調整する

依存関係

• 認証APIのテスト作成は、認証APIの実装にブロックされる
• フロントエンドと認証APIの連携は、ログイン画面のUI作成と認証APIの実装にブロックされる

実行後の状態

• プロジェクト「ユーザー認証機能」を作成
• 認証APIのテスト作成 (blockedBy: 認証APIの実装)
• フロントエンドと認証APIの連携 (blockedBy: ログイン画面のUI作成)
• フロントエンドと認証APIの連携 (blockedBy: 認証APIの実装)

</example>