1
セッションをまたいだパターンを見つける
あなたのチームは数週間にわたって ここから明確な示唆が得られます: このプレイブックには、破壊的な操作の前に外部キー依存関係を確認するステップがありません。スタンドアロンのテーブルだけを操作した 2 つのセッションは成功し、そうではなかった 2 つのセッションは失敗しました。
!db-migration プレイブックを使っています。カラム名の変更やインデックスの追加は問題なく処理できましたが、他のテーブルから参照されているカラムを削除しようとしたところ、直近 2 回のセッションはマイグレーションの途中でクラッシュしました。各セッションを開いて、失敗したポイントを確認します。このケースでは、セッション 3 と 4 がどちらも同じステップでエラーになっています:2
Improve Playbook タブをセッションリンク付きで開く
app.devin.ai にアクセスし、入力ボックスの下にある Advanced をクリックします。Improve Playbook タブを選択します。プレイブックのドロップダウンから
!db-migration を選び、session multi-dropdown から 4 つすべてのセッションを選択します — 成功したものと失敗したものの両方です。成功したセッションも含めることで、プレイブックがうまく機能している部分だけでなく、どこで破綻しているかも Devin が把握できます。このプロンプトが効果的な理由は次のとおりです:- 具体的な失敗を特定している — 「たまに失敗する」ではなく「外部キー制約」
- 成功と失敗を対比している — Devin はセッションのトランスクリプトを比較し、どこで分岐したかを確認できる
- 具体的な修正案を列挙している 一方で、あなたが見落としている問題を Devin が挙げられる余地も残している
3
プレイブックの差分をレビューする
Devin は 4 つすべてのセッションのトランスクリプトを読み、失敗が成功と分岐した箇所を特定し、ピンポイントな修正を提案します。出力はプレイブックのチェンジログのような見た目になります:プレイブックは自動的に保存されます。何かおかしな点があれば、同じセッション内で返信します — たとえば「破壊的なマイグレーションを実行する前に #database Slack チャンネルに通知するステップも追加して」といった具合です。
4
新しいマイグレーションで修正を検証する
現在の Devin セッションから離れる必要はありません。プレイブックの更新が保存されたら、同じセッションを使って、以前失敗したのとまったく同じシナリオに対して更新済みプレイブックをテストする標準の Devin セッションを起動します:このセッションが成功すれば、修正は有効です。新たなエッジケース
(たとえば循環する外部キー参照) に当たった場合は、そのセッションを
Improve Playbook タブに再度入力して、もう一度改善サイクルを回してください。

