This walkthrough covers the integration engine where we started. For your team’s jobs, queries, and services, start with the verification overview and agree on a test scope.
A 4-minute screen-recording of three integrations (Stripe → Clerk → Resend) lands here soon. Until then, the prose below walks the same flow with the exact tables and pickers you'll see in your IDE.
You type something like ./fetchsandbox help me add stripe to my app. The ./fetchsandbox prefix is the dispatch signal: it bypasses agent autonomy and guarantees the brain is consulted. The skill reads your repo, proves the contract against a stateful sandbox, walks the code with you, and closes with a structured ship-recap. Seven steps, in this exact order:
Confirm what you're trying to do. If your prompt was vague, a 4-option picker offers concrete paths.
Read your repo. Find existing SDKs, env files, framework, language mix. Deterministic: runs a Python script, returns JSON.
Speak about the integration SHAPE: what's wired, what isn't: using tables with file:line citations. Never prose paragraphs.
Call the deterministic guide() router. Surface its brain.yaml discovery questions via AskUserQuestion picker: domain-aware, not generic.
Hand off to fs-prove-payments / fs-prove-email / fs-prove-auth. Run one workflow against the sandbox. Stream the proof table back.
Read your actual code. Speak about what you got RIGHT before naming gaps. For each gap, propose via fs-propose-changes: diff + rationale, gated by a picker.
Recap warnings filtered by your discovery answers. Close with a three-table ship-recap: what landed / contract proven / before-deploy checklist.
Every transition between steps is gated by an AskUserQuestion picker. You're never silently moved forward. The skill never writes files without your confirmation. Power-user mode: hit Enter on the default option to blast through quickly.
We never use "type yes to continue" or "paste a number to choose". Prose prompts get scrolled past, especially when your terminal is busy. Every decision point fires a native AskUserQuestion modal: radio buttons, descriptions, escape hatch.
Used for discovery. 2-3 brain questions in one form. Power users blast through with defaults.
When proposing several file changes, each one is a tab in a single picker: review per-file, approve or skip.
Before proposing a diff, if the change hinges on an architectural fork (where to fetch the data, which auth model), the skill picks for it first.
At end-of-phase transitions. Options are context-derived from your session's findings: never generic 'continue'.
Result: you can scroll back through the session and immediately see where decisions were made. Each picker is a checkpoint you (not the skill) controlled.
When the skill says a workflow passed, you get a table with specifics: and the sandbox URL is a real, clickable receipt anyone can verify. From a real Stripe session today:
| Workflow | Result | Steps | Duration | Webhooks |
|---|---|---|---|---|
| accept_payment (happy) | ✅ Passed | 6/6 | 147ms | 2/2 verified |
What this proves: the full Stripe contract: POST /create-payment-intent → confirm → capture → payment_intent.succeeded webhook → mark_order_paid — all ran end-to-end. The two webhook events were signature-verified, not just emitted.
Each step in the workflow has a method, path, response code, and duration. Each webhook has a signature-verify result. The sandbox run is bookmarkable: share the URL with a reviewer who can audit what happened without trusting your screenshot.
Most API testing tools have two failure modes. They lie — "✅ all tests passed" when the scenario didn't actually run. Or they bail: "couldn't test this" and quit. We do the third thing.
Asked the sandbox to run accept_payment with scenario=payment_declined. Got back: succeeded. Both runs passed identically. Instead of pretending or quitting, the skill said:
Scenario payment_declined didn't materialize
| Asked for | Got | Why |
|-------------------|----------------------|--------------------------------------------------|
| payment_declined | succeeded (terminal) | Curated workflow has deterministic steps: |
| | | the scenario param was accepted but the |
| | | happy-path test card overrode it. |
How to actually exercise the payment_failed branch:
| Method | Command |
|---------------------|------------------------------------------------------------------|
| CLI forward + decline | stripe listen --forward-to localhost:8000/webhook |
| | then drive PaymentIntent through /checkout with card 4000...0002 |
| Synthetic trigger | stripe trigger payment_intent.payment_failed |Calibrated middle ground. Run it. Name the gap precisely. Prescribe the exact commands that close it. The skill knows its limits and tells you what to do next.
When you add a second integration to a repo that already has one, the skill reads BOTH and wires them properly. When you add a third, it reads all three. From three sessions we ran on the same repo today:
Empty repo + 'help me add stripe'. The skill scaffolds payment-intent + webhook handler, proves accept_payment against the Stripe sandbox.
Repo now has Stripe. 'help me add clerk': the skill SEES the existing Stripe code, proposes JWT verify on /create-payment-intent, wires user_id into Stripe PaymentIntent metadata. Sandbox can't prove sessions_expired (enumerated workflow limit), so the skill writes a local pytest covering three failure modes instead.
Repo now has Stripe + Clerk. 'help me add resend': the skill sees BOTH. The receipt-send uses user_id pulled from the Stripe PaymentIntent's metadata (Clerk put it there in session 2), fetches the email from the orders service Clerk's webhook handler provisions, and only fires on payment_intent.succeeded. Three integrations chained.
No isolated testing tool can demo this. Each spec proven against its own sandbox; the user_id flowing from Clerk → Stripe metadata → Resend lookup is the kind of brownfield composition real codebases need. We reason about the repo state as a whole, not one SDK at a time.
Every session closes with a three-table ship-recap. Standalone: a reviewer reads it without ever opening your chat session.
| # | Change | Location | Status |
|---|---------------------------------------------------|------------------------------|------------|
| 1 | Add @clerk/nextjs to workspace deps | package.json:17 | ✅ Applied |
| 2 | Wrap app in <ClerkProvider> + sign-in header | web/app/layout.tsx (new) | ✅ Applied |
| 3 | Gate /checkout(.*) via clerkMiddleware | web/middleware.ts (new) | ✅ Applied |
| 4 | JWT verify dep, user_id on PI metadata, webhook | server/main.py | ✅ Applied || Workflow | Result | Timeline |
|-----------------------------------|-----------------------------------|----------------|
| user_signup (happy path) | 4/4 ✓: 2/2 webhooks verified | e2481acf0a |
| sessions_expired (failure path) | 1/2: covered locally by pytest | e2481acf0a || Item | Where | Note |
|-----------------------------------|-------------------|-----------------------------------|
| CLERK_JWT_ISSUER | prod env (server) | JWKS auto-derived |
| CLERK_WEBHOOK_SECRET | prod env (server) | Endpoint signing secret |
| JWT key rotation policy | Clerk dashboard | Quarterly per compliance note |
| pytest server/tests/ | local CI | Confirms failure-path contract |Copy this block into a PR description and a reviewer has everything they need: what changed, what was proven, what's still needed before deploy. The skill writes the documentation you would have skipped.
Install in 30 seconds. Type help me add <X> to my app in your IDE. Pick from the catalog. Brownfield-safe: won't break what's already wired.