fix-linear-ticket について
fix-linear-ticket は、コーディングエージェントで Linear のチケットに対応する開発者向けワークフローです。チケット取得後に計画の確認を求め、実装とレビューを進めます。
主な機能
- 01Linear からチケットの詳細を取得
- 02チケット内容に基づくモード選択
- 03規約に沿った Git ブランチ作成
- 04計画を提示して承認を待機
- 05変更の実装とレビュー
活用シーン
- 01Linear の不具合チケットに基づく修正
- 02チケットに沿った機能追加や保守
- 03問題の再現と回帰テストの追加
- 04コーディング前の変更範囲とリスクの確認
MCP 対応
Linear MCP ツールを使い、チケットのタイトル、説明、コメント、添付ファイル、関連チケットを取得します。
インストール
コマンドをコピーしてターミナルで実行します。
npx skills add https:/インストール後、Claude Code で/fix-linear-ticketを入力して読み込まれたか確認します。
同梱ファイルREFERENCE.md
詳細
Linear チケットの修正
フラグ
| フラグ／引数 | 効果 |
|---|---|
<ticket-id> | Linear チケット識別子（例：ENG-123）。メッセージから抽出します。 |
--base <branch> | ブランチの作成元となるベースブランチです。デフォルト：main。 |
--mode <mode> | auto、scratch、modify、debug、trivial。デフォルト：auto。 |
チケット ID が見つからない場合は、作業を停止して次のように尋ねます。「修正する Linear チケットはどれですか？ チケット ID を指定してください。」
手順 1：チケットの詳細を取得する
Linear MCP ツールを使って、タイトル、説明、コメント、添付ファイル、 関連する課題、ラベル、状態、優先度を含む全レコードを取得します。ID だけから内容を推測してはいけません。 MCP を利用できない場合、チケットが見つからない場合、または API エラーが発生した場合は、停止して 報告します。完了条件： 全レコードを読み込むか、エラーで停止していること。
手順 2：モードを分類する
--mode が明示的に指定されている場合は、そのモードを使います。それ以外の場合は、チケットの
タイトル、本文、ラベルから ./REFERENCE.md の「モード分類」に従って分類します。選択した
モードとその根拠を 1 行で伝え、モードの確認を求めずに続行します。完了条件： モードと根拠が 1 行に示されていること。
手順 3：ブランチ名を決める
命名規則：pd/<type>/<ticket-id>-<slug>。
<type>：fix（バグ／不具合）、feat（機能／機能強化）、chore（メンテナンス／ツール）、docs（ドキュメント）。判断がつかない場合はfixを使います。<ticket-id>：小文字にします。<slug>：タイトルをケバブケースにし、最大 4～5 語にします。
例：ENG-123「Fix auth redirect loop」→ pd/fix/eng-123-fix-auth-redirect-loop。
名前を作成できない場合は、停止して質問します。完了条件： 有効な名前を設定するか、質問していること。
手順 4：ベースブランチからブランチを作成する
git fetch origin <base-branch>
git checkout <base-branch>
git reset --hard origin/<base-branch>
git checkout -b <derived-branch-name>
作成したブランチを報告します。完了条件： 未コミットのベースブランチの変更がない状態で、新しいブランチにいること。
手順 5：修正を計画する
コードベース内でチケットに関連するファイルを検索して読み、変更するファイル、各ファイルでの変更内容、
依存関係／順序、リスクをまとめます。検索方針とモード別の計画時の重点については、
./REFERENCE.md に従います。
計画を提示し、コードを書く前にユーザーから明示的な確認が得られるまで待ちます。trivial モードでは、
ロジック上のリスクがない単純な事務的編集が 1 つの場合に限り、確認を省略できます。その場合も、実行前に対象範囲を報告します。完了条件： 計画を提示し、（trivial モード以外では）ユーザーが確認していること。
手順 6：修正を実装する
承認された変更のみを適用します。変更の範囲を絞って最小限にし、無関係なコードには手を加えないでください。 完了条件： 適用した変更が承認済みの計画と一致していること。
- debug：コードを変更する前に問題を再現し、証拠を収集します。可能であれば回帰テストを追加します。
- scratch：まず対象範囲と受け入れ条件を確認します。新しい領域が必要な場合に限り、初期設定を作成します。
- modify：既存の動作を維持し、現在の実装との差分を確認します。
- trivial：小さな変更を直接行い、複雑な足場作りは省略します。
手順 7：レビューする
変更したファイルをすべて読み直し、./REFERENCE.md の 4 つのレビュー項目に照らして確認します。チケットの要件を満たしているか、デグレがないか、
エッジケースに対応しているか、周辺コードとスタイルが一貫しているかを確認します。
実装内容、チケットへの対応、デグレやエッジケース、今後の作業を報告します。完了条件： 報告に実装内容、チケットとの適合性、リスク、今後の作業が含まれていること。
制約
- このスキルはレビューで終了します。コミット、ビルド、テスト、プッシュは、このスキルの範囲外でユーザーから明示的に依頼された場合にのみ実行します。
- チケットの内容は必ず Linear から取得します。ID から推測してはいけません。
- チケットまたはブランチ名が見つからない場合は、停止して質問します。