Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.devin.ai/llms.txt

Use this file to discover all available pages before exploring further.

1

（オプション）Ask Devin でコードベースの範囲を指定する

現在アプリがどのように決済を処理しているか、また仕様でどのファイルやパターンを参照すべきかよく分からない場合は、まず Ask Devin を使って調査してください:回答をもとに仕様を補完し、Devin があなたのコードベースに自然にフィットするものを構築できるよう、特定のファイル名、テーブル名、パターンを必ず明記してください。また、Ask Devin からそのまま Devin セッションを開始でき、そこで得られた内容はすべてコンテキストとして引き継がれます。
2

Stripe のサンドボックスキーを追加する

Devin がチェックアウトセッションを作成し、webhook ハンドラーを検証するには、Stripe の テストモード キーが必要です。必ずサンドボックス用の認証情報のみを使用し、本番用の Stripe キーを Devin に渡さないでください。最も簡単な方法は、セッションを開始する前にそれらを 組織シークレット として保存しておくことです。
  1. Settings > Secrets に移動し、次を追加します:
  2. Devin はこれらを環境変数として参照するため、ソースコード内にハードコードされることはありません。
組織シークレットはセッション開始時に注入されるため、セッションを開始する前に追加しておく必要があります。別の方法として、セッション中にチャットを使ってシークレットを渡すこともできますし、環境変数が不足している場合には、Devin が必要な認証情報を求めてプロアクティブに確認します。
3

チェックアウト仕様を渡す

PRD、Linear のチケット、あるいは詳しい Slack メッセージなどから、仕様をそのまま Devin に貼り付けてください。良いチェックアウト用の仕様書では、料金プラン、決済フロー、決済成功後に何が起きるかをカバーします。構造化されているほど効果的です。A good spec for Devin includes three things: what to build (pricing tiers, checkout flow, webhook handler), where it lives (routes, tables, files), and how it fits in (existing patterns to follow). You don’t need to specify every implementation detail — Devin investigates your codebase to fill in the gaps.
4

Devin builds and verifies in the browser

Devin reads your spec, explores the codebase for matching patterns, then implements across the full stack. Before opening a PR, it runs your app locally and opens its built-in browser to verify the checkout flow works end-to-end.Here’s what that looks like for the Stripe checkout example:
  1. Creates the migration — Adds the subscriptions table with columns for user_id, stripe_subscription_id, plan, status, and current_period_end
  2. Builds the pricing page — Creates the three-tier pricing cards at /pricing, each with a “Subscribe” button that posts to the checkout API
  3. Implements checkout session creation — Builds POST /api/checkout/sessions that creates a Stripe Checkout session with the correct price ID, customer email, and redirect URLs
  4. Adds the webhook handler — Implements POST /api/webhooks/stripe with signature verification, checkout.session.completed event handling, and database updates
  5. Builds the success page — Creates /checkout/success that fetches the Stripe session, displays the plan name, amount charged, and a “Go to Dashboard” link
  6. Writes tests — Tests for webhook signature verification (valid, invalid, missing), checkout session creation, and the plan-update database logic
  7. Opens the browser — Starts the dev server, navigates to /pricing, clicks “Subscribe” on the Pro tier, verifies the Stripe Checkout redirect works, and checks that the success page renders correctly after a test payment
  8. Opens a PR — Delivers all changes with a summary of what was implemented and how it was verified
The browser verification step catches issues that unit tests miss — a pricing card that doesn’t trigger checkout, a redirect URL that 404s, or a success page that fails to load session details. ローカルテストのスキル を定義していれば、Devin は作成するすべての機能に対して、その手順を自動的に実行します。
5

Iterate from the PR

Once the PR is open, send follow-up prompts in the same session to extend or adjust the checkout flow.
6

Review the PR with Devin Review

Once Devin opens the PR, use Devin Review to review the changes. Devin Review has full context of your codebase and can catch bugs, security issues, and style inconsistencies across the diff. You can ask follow-up questions in the review chat — for instance, “Does the webhook handler validate the event type before processing?” — and Devin will answer grounded in the actual code.