トリアージ用プレイブックを作成する
自動化には、あなたのチームがバグをどのようにトリアージするのかを Devin に伝える Playbook が必要です。単に「バグを直す」と書くのではなく、エンジニアが実際に従う具体的な手順を示してください。まず、
!triage のテンプレート Playbookを複製し、自分たちのスタック向けにカスタマイズします。あるいは、Settings > Playbooks に移動し、マクロ !triage-bug を使った新しい Playbook を作成します。以下はその一例です:Playbook が具体的であればあるほど、Devin によるトリアージの品質は向上します。チームが実際に用いているパターン — エラーログの規約、テストフレームワーク、ブランチ命名ルール — を反映させてください。効果的な Playbook の書き方については Playbook ドキュメント を参照するか、Advanced Devin を使って Playbook を自動生成することもできます。自動化トリガーを設定する
バグにラベルが付けられたときに自動で実行されるように、playbook を Linear に接続します。
- Settings > Integrations > Linear に移動します（まだ連携していない場合は、先に連携を設定してください — セットアップガイド）
- Synced playbook labels で Add playbook をクリックし、
!triage-bugを選択します — これにより、Linear の 「Devin Playbooks」 ラベルグループに対応するラベルが作成されます - Automation triggers までスクロールし、Add trigger をクリックします:
- Teams: バグが起票されるチームを選択します（例: 「Engineering」）
- Labels:
Bug（またはチームでバグ報告に使っているラベル）を選択します - Playbook:
!triage-bugを選択します
- トリガーを保存します
Bug ラベルを追加したとき）のみ発動し、すでに条件を満たしているチケットには発動しません。これにより、既存のバックログ全体に対して誤って Devin を起動してしまうことはありません。playbook のラベルを Linear と自動同期するには、Linear ワークスペースで Manage workspace labels が All members に設定されている必要があります（Linear の Settings > Security にあります）。それが有効になっていない場合は、Linear 上でラベルを手動で作成する必要があります。
バグにラベルを付けて、Devin が調査する様子を見てみましょう
エンジニアが次のように Linear のチケットに
Bug ラベルを付けると:ENG-487: ユーザーが /contact のお問い合わせフォームを送信すると 500 エラーが表示される。先週金曜日のデプロイ以降に発生し始めた。スタックトレースはDevin は自動的にセッションを開始し、あなたのトリアージ用プレイブックに従います:src/lib/forms.ts内のvalidateEmail()を指している。
- チケットを読む — タイトル、説明、Linear 上のコメントをすべて取得
- コードベースを検索する —
src/lib/forms.ts、src/routes/contact.tsのルートハンドラ、およびフォームバリデーションのテストを特定 - 最近の変更を確認する —
git log --since="last Friday" -- src/lib/forms.tsを実行し、メールの正規表現をリファクタしたコミットを見つける
ループを洗練させる
いくつかトリアージを回したら、Devin がうまくできている部分と、よりガイダンスが必要な部分に基づいて、この仕組みを洗練させていきます。実際のセッションに基づいてプレイブックを改善する。 Devin が一貫して何かを見落としている場合（例: ログを確認しない、関連サービスを見逃すなど）、その手順を
!triage-bug プレイブックに追加します。Advanced Devin を使って過去のセッションを分析し、プレイブックを自動的に改善したり、すべてのセッションで Devin が従うべきパターン用に Knowledge エントリを作成できます。たとえば、「まずエラートラッキングダッシュボードを必ず確認する」や「auth サービスのログは Datadog ではなく CloudWatch にある」といったルールです。準備ができたら修正用プレイブックを追加する。 Devin のトリアージを信頼できるようになったら、!fix-bug のような 2 つ目のプレイブックを作成し、さらに踏み込んだ内容にします — 修正の実装、リグレッションテストの追加、PR の作成まで行います。別のラベルにマッピングして、チームが「何が問題かだけ教えてほしい」のか「修正まで任せたい」のかを選べるようにします: