Skip to main content
これを手動で設定したくない場合は、このページへのリンクを Devin セッションに貼り付けて、必要な設定をすべて行うよう依頼してください。
1

フラグをリリースしたときにクリーンアップを予約する

enable_new_checkout の裏側で新しいチェックアウトフローをデプロイしたところです。本番環境ではすでに有効になっていますが、古いコードを削除する前に 1 週間は監視したいと考えています。後で忘れてしまうチケットを作成する代わりに、今このタイミングで一度きりの Devin セッションをスケジュールしておきましょう — コンテキストを覚えているうちに行うのが最適です。スケジュール作成ページ を開き、タイプを One-time に設定します。監視期間が終わった後の日付 (例: 次の金曜日の午前 9 時) を選択します。セッションが実行されて PR が用意されたときにチームへ通知が届くよう、Slack チャンネル を選択します。次に、以下のプロンプトを貼り付けます:
2

プロンプトを十分に具体的にする

フィーチャーフラグは思わぬ場所に隠れていることがあります — 設定ファイル、テストフィクスチャ、コメント、環境変数などです。プロンプトにコンテキストを多く含めるほど、クリーンアップ結果の精度が上がります。次の内容を含めてください:
  • フラグの仕組み — どこで定義され、どのようにチェックされるか (例: React では useFeatureFlag('name')、バックエンドサービスでは isEnabled('name'))
  • 触ってほしくないもの — フラグフレームワーク自体と、個別のフラグの違い (例: “src/lib/featureFlags/ は変更しないでください — そこがフレームワークです”)
  • 古いコードと新しいコードの場所 — 例: “古いチェックアウトは src/pages/checkout/legacy/ にあり、新しいフローは src/pages/checkout/v2/ にあります”
  • クリーンアップの範囲 — フラグを参照しているコメント、ドキュメント、.env ファイル、CI 設定も合わせてクリーンアップするかどうか
このレベルの詳細を含んだプロンプトであれば、Devin は参照箇所を 1 回のパスですべてたどれるため、後追いのスイープは不要になります。
3

PR が作成されたらレビューする

スケジュールされたセッションが実行されると、Devin はコードベース全体でフラグの利用箇所をすべてたどり、有効なコードパスを残し、無効なパスとデッドコードを削除し、テストをクリーンアップしてから PR を作成します。準備ができるとメール通知が届きます。典型的な PR は次のようになります:
マージする前に、古いパスから残しておくべきビジネスロジックがないか念のため確認してください — エラーハンドリング、分析イベント、エッジケース向けのフォールバックなどが”無効”ブランチの中に存在していることがあります。