# Breaking Down Linear Issues

> Linearに大きなタスクを複数のIssueに分割して作成する際に使用。新しいプロジェクトを作成し、その中にフラットなIssueを作成し、依存関係はblockedByリレーションで表現する。

- Skill: `syou6162/breaking-down-linear-issues` (Agent Skill)
- Install (CLI): `npx skillmds@latest add syou6162/breaking-down-linear-issues`
- Raw SKILL.md: https://api.skillmd.com/api/skills/syou6162/breaking-down-linear-issues/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: syou6162 (https://skillmd.com/u/syou6162)
- Updated: 2026-09-10
- Page: https://skillmd.com/skills/syou6162/breaking-down-linear-issues

---


# 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を使ってプロジェクトを作成する。

   ```bash
   # 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（後段のタスク）を読み、後段で何を行うためには今回のタスクで何が必要かを把握する
     - 前段・後段のタスク内容を踏まえて、今回のタスクの作業内容と受け入れ条件を調整する

   ```bash
   # 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>