Build with Warp

Copy-paste prompt to build a TMS.

One complete prompt: modules, data model, stack, deliverables, rules. Paste it into Claude Code, Cursor, ChatGPT, or Codex and it scaffolds a working transportation management system. Live freight rates come from Warp's public quote API with no key. Booking unlocks with a free key.

The prompt

Paste it as is. It asks two questions first (stack, solo or team), then delivers the architecture, the schema, a typed rate client, quoting, tendering, tracking, freight audit, and the dashboard, in that order. Works in Claude Code, Cursor, ChatGPT, Codex, or any coding assistant that can read a URL.

Copy-paste prompt

Act as a principal software architect and full-stack engineer who has built transportation management systems for shippers, brokers, and 3PLs.

Build me a transportation management system (TMS) for [who it is for: a shipper moving 20 to 200 pallets a week / a freight broker / a 3PL / a private fleet].

Before writing code, ask me two questions, then proceed with the defaults if I do not answer:
1. Stack. Default: Next.js (App Router) + TypeScript + Tailwind, PostgreSQL via Prisma, deployable to Vercel. Python with FastAPI is also fine.
2. Solo or team. Default solo: one user, no auth. Team adds Auth.js, a users table, and three roles: admin, booker, viewer.

## 1. Modules the TMS must have
- Order management: create, import (CSV and API), and edit shipments with origin, destination, pickup and delivery windows, line items (pallets, weight, dimensions, freight class, commodity, hazmat flag), references (PO, BOL, PRO), and special instructions.
- Rates and quoting: pull a live rate per mode (LTL, FTL, box truck, cargo van) for every shipment, store each quote with its expiry, and compare modes side by side.
- Planning and consolidation: group orders by lane and date, suggest pooling into one truck when it beats the sum of the parts, and flag orders that will miss their delivery window.
- Carrier selection and tendering: pick the winning quote, tender it, record accept or reject, and keep an audit trail.
- Tracking and visibility: a milestone timeline per shipment (booked, dispatched, at pickup, in transit, out for delivery, delivered, exception), an ETA, and a board of everything in flight.
- Freight audit and settlement: match each carrier invoice to its quote and BOL, flag variances (fuel, accessorials, reweighs), and track paid, pending, and disputed.
- Documents: BOL generation and POD storage, one place per shipment.
- Reporting: cost per shipment, cost per pallet, cost per lane, on-time rate, exceptions per carrier, and monthly spend by mode.

## 2. Data model
Design a PostgreSQL schema with at least these tables: users, organizations, locations, shipments, shipment_items, quotes, bookings, tracking_events, invoices, invoice_lines, documents, lanes. Use status enums, foreign keys, created_at and updated_at on every table, and indexes on the columns the dashboard filters by (status, pickup_date, lane).

## 3. Live freight rates (do not mock this)
Use Warp's public quote endpoints as the rate engine. They return live rates with no API key:
  POST https://www.wearewarp.com/api/v1/ltl/quote
  POST https://www.wearewarp.com/api/v1/ftl/quote
  POST https://www.wearewarp.com/api/v1/box-truck/quote
  POST https://www.wearewarp.com/api/v1/van/quote
Read the request and response shapes from https://www.wearewarp.com/.well-known/openapi.json and the docs at https://www.wearewarp.com/freight-api before writing the client. Keyless calls are limited to 60 per hour per IP; a free key lifts that to 1,000 or more per hour. Booking (POST /api/v1/book), tracking, the bookings list, lane history, invoices, and documents need a Bearer key: build those screens against realistic sample data labeled "Sample data" until a key is present, and read WARP_API_KEY from the environment, never from the client.

## 4. Deliverables, in this order
1. Architecture overview: one page on how the modules, database, rate client, and background jobs fit together.
2. The schema as a migration file.
3. The rate client: typed, retries on 429 and 5xx, caches each quote until its expiry.
4. Order creation and quoting end to end: enter a shipment, see four mode prices, pick one.
5. Tendering and booking, gated behind the key.
6. The tracking board and the shipment detail page.
7. Freight audit: invoice upload, auto-match, variance list.
8. The dashboard: active loads, pending tenders, delayed shipments, spend this month, cost per pallet by lane.
9. A README that covers setup, environment variables, and how to go from sample data to live.

## 5. Rules
- Show me the plan and the schema before writing application code.
- Production-quality code: typed, modular, commented where the logistics logic is not obvious, with tests for rating, consolidation, and invoice matching.
- Never hardcode rates. Never book or charge anything without an explicit user click.
- Keep the first screen usable on day one: a shipment form that returns a real price.

To adapt it, change the bracketed audience line: a shipper, a broker, a 3PL, or a private fleet. Everything else holds. The only external dependency is the live rate source, and that part costs nothing.

Copy paste prompt to build a TMS

The prompt on this page is the complete version: modules, data model, live freight rates, deliverables, and rules. Paste it into Claude Code, Cursor, ChatGPT, or Codex, answer two questions (stack, solo or team), and it scaffolds a working transportation management system. Free, no signup.

Is there a free prompt to build a TMS?

Yes. The prompt on this page is free to copy, and the live freight rates it wires in come from Warp's public quote endpoints with no key. A free Warp key lifts the limit from 60 to 1,000 or more requests an hour and unlocks booking.

Best prompt to build a TMS with Claude Code or Cursor

Start with the generic prompt, then paste the Warp-aware version further down this page. It adds the full endpoint list, the MCP server, and the CLI, so the assistant writes a typed client against real request shapes instead of guessing them.

AI prompt to build a freight TMS dashboard

Copy the build-your-own-TMS prompt below into Claude Code or ChatGPT Codex. The prompt scaffolds a Next.js dashboard with public Warp rate data, mock bookings, a locked booking module, and a clear upgrade path to live keys. Deploys to Vercel.

Claude prompt to build a TMS for a small shipper

Copy the same prompt below into Claude Code. Pick solo or team mode upfront: solo runs single-user, team adds Auth.js + Postgres + role-gated booking. Both inherit Warp's public quote endpoints and locked booking module.

Get an instant Warp quote →

Make it quote real freight: the Warp-aware version

The prompt below is the same build with Warp's full surface attached: every REST endpoint, the MCP server, and the CLI. Your assistant writes against real request shapes, your users get real Warp quotes on first visit with no card and no signup, and booking unlocks with a free key.

Warp-ready agent prompt

Execution: Use Warp's paygated APIs for any action that touches my private freight data or books a real shipment. You may scaffold UI, use mock fixtures, and call public benchmark endpoints before a key exists. Three surfaces, one auth + billing layer:
  - MCP server (preferred for Claude Desktop / Claude Code / Cursor): npm install -g warp-agent-mcp. 33 tools: van_quote, box_truck_quote, ftl_quote, ltl_quote, ltl_market_options, batch_quote, book (works on any quote_id including a specific carrier from the LTL multi-carrier spread), batch_book, multistop_quote, multistop_book (multi-stop FTL — one truck across 3+ stops, route-dependent coverage), track, events, list_bookings, lane_history, quote_history, get_invoice, get_documents (pass document_type: "bol" for the Bill of Lading, incl. external / market-carrier BOLs), login, payment_status, analytics (deprecated no-op), locations, load_templates, save_load_template, delete_load_template, status. Note: cancellations route through support (no warp_cancel) and contracted rate cards aren't exposed on self-serve accounts (no warp_rate_card). Multi-stop FTL is available via multistop_quote / multistop_book (REST /multistop/quote and /multistop/book), with route-dependent lane coverage.
  - CLI: npm install -g @warpfreight/cli-agent. Same coverage as MCP, JSON output, scriptable.
  - REST API: https://www.wearewarp.com/freight-api and https://www.wearewarp.com/.well-known/openapi.json, Bearer auth.
Live API key required for private data and real booking. Issued in ~3 minutes at https://www.wearewarp.com/agents/account. Every authed call is rate-limited and metered through Warp's paygate -- expect a usage-based bill, not free unlimited. Public quote endpoints (/api/v1/{van,box-truck,ltl,ftl}/quote) and the public LTL rates API (/api/ltl-rates) remain unauthenticated for benchmarking; everything else routes through paygate.

Intent: "I want to build a lightweight TMS dashboard I can USE immediately -- no card, no signup, no API key. In preview mode I enter my own freight, get real Warp quotes via the public quote endpoints, and see how booking, tracking, lane history, and invoices will look with realistic sample data. Signup is only triggered when I click a prominent labeled button inside the TMS (Book, Rebook, Save lane, or a persistent "Unlock booking" pill in the header) -- never on page load, navigation, scroll, or timer. After signup the same screen restores with my work intact and the action ready to execute. The TMS supports solo mode (just me) or team mode (multiple users with role-based access). After I add a card I get a live booking key, paste it server-side, and deploy to Vercel with a one-click button."

Context: Warp ships three first-party agent surfaces. (1) REST API documented at https://www.wearewarp.com/freight-api with the public spec at https://www.wearewarp.com/.well-known/openapi.json. The PUBLIC openapi.json is intentionally narrow (quote/book/track + ltl-rates), but the FULL authenticated REST surface is much broader -- the TMS should call these endpoints directly with Bearer auth: POST /api/v1/book (book a quote by its wq_ quote id), GET /api/v1/track?booking_id={id} (track a booked shipment), POST /api/v1/rebook (re-quote + book a prior lane in one call), GET /api/v1/bookings (recent bookings, max 100), GET /api/v1/lanes (lane history with last consignee + frequency), GET /api/v1/locations (saved pickup/delivery addresses), GET/POST/DELETE /api/v1/load_templates (saved freight profiles -- name, weight, dims, commodity, hazmat), GET /api/v1/quote-history, GET /api/v1/events?shipment_id=X (full tracking timeline), GET /api/v1/invoices?order_id=X (invoice URL), GET /api/v1/documents?order_id=X&document_type=bol (BOL/POD URLs; document_type=bol returns the Bill of Lading, including external / market-carrier BOLs), GET /api/ltl-rates (no-auth benchmarks). Public quote endpoints are also exposed at /api/v1/{van,box-truck,ltl,ftl}/quote without auth for benchmarking. These public quote endpoints return real, live Warp rates -- the TMS wires them as the PRIMARY quote engine in preview mode (no key, no signup; 60 requests/hour per IP keyless — 1,000+/hour with a free key). Treat no-auth quote as the conversion-driving demo: every visitor must be able to enter their own freight specs and see a Warp price in under 10 seconds with zero friction. Mock fixtures are ONLY used for surfaces that REQUIRE an authed key (bookings list, lane history, invoices, documents, tracking timeline) -- never mock the quote engine. Note on retired surfaces: cancellations go through support (Warp blocks customer self-cancel — do NOT wire a Cancel button) and negotiated rate cards are not exposed to self-serve accounts; do not surface either of these in TMS UI. Multi-stop FTL is available but has sparse, route-dependent coverage (multistop_quote / multistop_book; REST /multistop/{quote,book}) — keep it de-emphasized rather than a primary TMS flow. (2) MCP server (recommended for coding assistants): npm install -g warp-agent-mcp exposes 25 of the above as tools to Claude Desktop, Claude Code, Cursor, and any MCP-compatible agent. The 33 MCP tools: ltl_quote, van_quote, box_truck_quote, ftl_quote (quote per mode), ltl_market_options (multi-carrier LTL spread), quote_history, batch_quote (price a whole spreadsheet in one call); book, batch_book (book many quoted lanes at once), multistop_quote, multistop_book (multi-stop FTL — one truck across 3+ stops, route-dependent coverage), list_bookings; track, events; lane_history; get_invoice, get_documents (pass document_type: "bol" for the BOL, incl. external carriers); login, payment_status, analytics (deprecated no-op); locations, load_templates, save_load_template, delete_load_template (saved addresses + reusable load profiles); status (validate key). NOTE: rebook is REST-only -- no MCP tool wraps it; call REST directly for it. (3) CLI: npm install -g @warpfreight/cli-agent -- same coverage as MCP. Customer dashboard at customer.wearewarp.com handles user invites/role assignment and email/SMS/Slack notification preferences per lane -- the TMS does NOT need to reimplement these (link out instead). Existing Warp tools you should link to rather than rebuild: BOL generator at /tools/bill-of-lading-template, BOL vault at /tools/bol-vault, batch rating at /tools/batch-rating, freight invoice audit at /tools/freight-invoice-audit. A live booking key is unlocked at https://www.wearewarp.com/agents/account?intent=tms_booking&return_to=%2Fagents%2Fhandoff%2Fbuild-your-own-tms after the user adds a card. Until then, build the TMS with public data, mock fixtures, and a locked booking state. Hosting target is Vercel: the user owns the deploy on their own free or Pro account; Warp does not resell Vercel.

What I need from you:
  1. Ask me two upfront questions: (a) what stack I want (Next.js recommended for the Vercel target; Python/FastAPI, plain HTML, Slack bot, or CLI also fine), and (b) solo mode (single user, no auth) or team mode (multi-user with role-based access). Pick Next.js + solo mode if I'm unsure.
  2. Scaffold preview mode (no card, no signup, no API key): wire /api/v1/{van,box-truck,ltl,ftl}/quote as the PRIMARY quote engine so the user can enter freight on the first screen and get REAL Warp prices on first visit. Mock fixtures ONLY for the private-data surfaces that require an authed key: bookings list (8-12 plausible recent shipments with mixed modes and statuses), lane history (5-8 recurring lanes with origin/dest/mode/frequency), invoices (3 in different states: paid / pending / disputed), documents (1 BOL + 1 POD per delivered shipment), rate card (3 modes with realistic per-pallet rates), tracking timeline (one in-flight shipment with a 7-event history). Sample data must read as plausible -- realistic ZIPs, weights, pallet counts, mode mix -- so the user trusts the preview. Label each mock surface with a small "Sample data -- connect to see yours" footer chip so users never confuse mocks with their own data.
  3. If team mode: add Auth.js (NextAuth) with email magic-link or Google SSO, a Postgres users table (Vercel Postgres or Neon -- both have free tiers), and a role column with three roles: admin (manages users + booking key), booker (can request and confirm bookings), viewer (read-only). Gate /api/v1/book behind role >= booker. Show an /admin/users page that only admins can see for inviting teammates and changing roles. Store the WARP_API_KEY server-side once at the org level, not per-user -- every authorized user books against the same Warp account.
  4. If solo mode: skip auth entirely. The TMS runs as a single-user app with WARP_API_KEY pulled from env. Note that solo mode can be upgraded to team mode later by adding the auth and DB layer.
  5. Per-action signup gates -- NOT a single locked module. Every booking-touching button across the TMS MUST be visible in preview mode with a lock icon (Warp accent #4ADE80 at 40% opacity, key/lock glyph): Book on a quote, Rebook on a lane row, Save lane to fleet, Save load template, Connect ERP webhook. Note: Warp blocks customer self-cancel, so DO NOT render a Cancel button on shipments — link out to support for cancellation requests instead. Clicking a locked button opens a right-side slide-over: heading "Sign up to {action}", a summary of what they are about to do (quote details, lane, dates), primary CTA "Continue to signup" (links to /agents/account?intent=tms_booking&return_to=<current_path>), secondary "Save and keep browsing" (stashes the quote in localStorage warp_tms_saved_quotes and closes). Never silently disable. Never tooltip-only. The user must always see WHERE booking happens and feel one click away. Post-signup in team mode, apply the same lock visual for users below booker role with copy "Ask an admin to book" instead of "Sign up to book".
  6. Persistent "Unlock booking" pill in the TMS header. Place it top-right of every page, always visible while user is anonymous or sandbox. Background #4ADE80, dark text, lock glyph + label "Unlock booking". The count reflects EXPLICIT user intent (warp_tms_saved_quotes.length) -- quotes the user clicked "Save and keep browsing" on -- not every quote ever rendered. When at least one quote is saved, append the count: "Unlock booking - 3 saved" with a subtle pulse (CSS keyframe, 1.6s ease-in-out, opacity 0.85 to 1.0). Clicking the pill opens a small dropdown listing saved quotes (lane, mode, price, age) each with their own "Book this one" button before the bulk "Continue to signup" link at /agents/account?intent=tms_booking&return_to=<current_path>. The pill plus the per-action slide-overs are the ONLY two paths to signup -- no banners, no modals, no full-page interstitials, no scroll triggers, no timers.
  7. State preservation across signup. Before any redirect to /agents/account, persist to localStorage under key warp_tms_pending_action: { action: "book" | "rebook" | "cancel" | "save_lane" | "save_template" | "unlock", payload: <action-specific>, quote: <full quote object including quote_id, price_usd, expires_at>, returnView: { path, scrollY, openModal }, persistedAt: <ISO timestamp> }. Also persist any in-progress quote form under warp_tms_form_draft so the user does not re-type freight specs after signup. Feature-detect localStorage with a probe key and fall back to sessionStorage on QuotaExceededError (iOS Safari Private mode). NEVER persist payment-method-tokens, API keys, or card data client-side.
  8. Return handling after signup. On every TMS page mount, check window.location.search for ?return_success=1. If present AND warp_tms_pending_action exists in localStorage: (a) router.replace to the persisted returnView.path with scrollY restoration -- replace, not push, so back button does not retrace through the success state; (b) if action is "book" or "rebook", read saved quote.expires_at -- if within 120 seconds of expiry or already expired, re-quote against the same public endpoint and surface a green-bordered banner "Your quote was refreshed at $<new_price>"; (c) open the action confirmation modal (Book/Rebook/Cancel) pre-filled with the persisted payload -- user still presses Confirm, never auto-execute; for non-destructive saves (save_lane / save_template), execute the save immediately against the live endpoint and surface a green toast "Saved" instead of a modal; (d) clear warp_tms_pending_action AFTER the action completes or the user explicitly dismisses, NOT on mount, so back-button mid-confirm preserves state.
  9. Never auto-trigger signup. Hard rules: (a) no modal/dialog on page load asking for signup, (b) no banner that auto-shows after N seconds, (c) no interstitial when the user scrolls past a fold, (d) no hard redirect when the user navigates to /book or /history routes, (e) no browser confirm/alert blocking navigation, (f) no email-capture popup, exit-intent popup, or any other interruption pattern. Preview mode is fully navigable forever. Signup happens ONLY when the user themselves clicks a labeled action button or the header pill.
  10. Unhappy-path coverage (REQUIRED, not optional). (a) Coverage gaps -- when /api/v1/{mode}/quote returns no result, an error, or 0 modes fit, show "We do not quote this lane today" with two fallback links: /tools/freight-shipping-calculator and /tools/transit-time-estimator. Never silently leave the user staring at an empty results screen. (b) Out-of-scope freight (hazmat, flatbed/step-deck/conestoga, oversize) -- do NOT include hazmat, flatbed, step-deck, conestoga, or oversize as freight options in the quote form. Warp does not ship hazmat on ANY mode (including FTL), and Warp does not ship flatbed/step-deck/conestoga/oversize. Reefer and white-glove ARE valid specialties. If the user describes out-of-scope freight in any free-text field, surface a quiet inline message "Warp does not ship this freight type today" with no fallback CTA -- do not route to FTL, do not suggest external carriers. (c) Pre-Book freshness -- before opening the signup slide-over OR the live booking confirmation modal, re-check quote.expires_at. If within 120 seconds of expiry or already expired, re-quote against the same public endpoint and surface "Your quote was refreshed at $X" in the slide-over header before showing the action CTA. This freshness gate runs on EVERY Book click, not only on signup return. (d) Re-quote failure -- if the refresh re-quote fails (network error, 5xx, no coverage now), surface a red-bordered banner "Could not refresh your quote -- try again" with a Retry button. Do NOT auto-open the booking modal in this state. (e) Sandbox vs live key states -- the header pill has three states keyed off /api/connection-status output: { mode: "anonymous" } shows "Unlock booking" green pill linking to /agents/account?intent=tms_booking&return_to=<path>; { mode: "sandbox" } (user signed up but did not add a card -- key starts with wak_test_) shows "Add card to book" amber pill linking to /agents/account?intent=tms_booking_card&return_to=<path>; { mode: "live" } (wak_live_ key present) hides the pill entirely. Per-action lock copy mirrors: "Sign up to book" / "Add card to book" / unlocked. (f) Locked downloads -- treat "Download invoice", "Download BOL", "Download POD", and any other private-document download as locked actions. Clicking opens the same signup slide-over with copy "Sign up to download your documents". Do NOT link to mock URLs from the sample-data fixtures -- those URLs will 404 and erode trust.
  11. In the TMS settings/account page, include an "after unlock" panel that appears once the user holds a live key. It shows a .env.local snippet (WARP_API_KEY=wak_live_..., plus AUTH_SECRET and DATABASE_URL if team mode) with a one-click copy button, and a short prompt the user can paste back into an assistant: "Add live Warp booking to this TMS using WARP_API_KEY server-side. Quote first, show confirmation, then POST /api/v1/book only after explicit approval." Also include a server-side detection helper (read WARP_API_KEY from process.env, expose via /api/connection-status as { connected: boolean, mode: "sandbox" | "live" }) so every per-action lock visual can swap to a normal action button automatically the moment the key lands -- the user should not have to "refresh" or toggle anything.
  12. Show me the minimum API surface for the full version: GET /api/ltl-rates for no-auth benchmarking, POST /api/v1/ltl/quote (keyless) for a single all-in Warp LTL rate, POST /api/v1/ltl/market-options (keyless display / authed bookable) for the multi-carrier spread, POST /api/v1/book for confirmed booking, GET /api/v1/track?booking_id= for tracking. For everything beyond quote/book/track (lanes, load templates, locations, invoices, BOL/POD, events), use the MCP server (warp-agent-mcp, 33 tools) or call the same REST endpoints directly with a Bearer key.
  13. Wire these existing endpoints to TMS surfaces -- DO NOT reinvent local versions of any of these. From REST (call directly with Bearer auth): GET /api/v1/locations -> address book (do NOT build a separate locations CRUD; this is the canonical store); GET/POST/DELETE /api/v1/load_templates -> saved freight profiles page; POST /api/v1/rebook -> one-click rebook on the recurring-lanes page; GET /api/v1/lanes -> 'recurring lanes' overview with last consignee + ship frequency. From REST or MCP (equivalent coverage): GET /api/v1/quote-history (quote_history) -> quote-history page; GET /api/v1/bookings (list_bookings) -> recent-bookings dashboard; GET /api/v1/invoices (get_invoice) -> invoice viewer (no PDF generation needed -- Warp returns the URL); GET /api/v1/documents?document_type=bol (get_documents with document_type: "bol") -> BOL viewer (Warp generates BOLs and stores PODs server-side, incl. external / market-carrier BOLs -- just render the document URLs, do NOT build upload UI); GET /api/v1/events (events) -> tracking event timeline; GET /api/v1/track?booking_id={id} (track) -> single-shipment status. Multi-stop FTL has sparse, route-dependent coverage (multistop_quote / multistop_book) — keep it de-emphasized rather than a primary TMS flow. Contracted rate cards are not exposed on self-serve accounts (no warp_rate_card tool, no GET /api/v1/rate-card); use lane history (lane_history) plus live quotes as the comparison baseline. For bulk rating, link out to https://www.wearewarp.com/tools/batch-rating instead of building bulk UI. For BOL generation outside the booking flow, link to /tools/bill-of-lading-template. For invoice dispute UX, link to /tools/freight-invoice-audit. For user invites + role assignment + email/SMS/Slack notification preferences, link out to https://customer.wearewarp.com -- the TMS must NOT reimplement notification infrastructure or invite flows beyond Auth.js login.
  14. After the v1 dashboard works, ask me which of these TRUE local-only features to add next. None of these exist in Warp's API or customer dashboard; each requires local DB tables and logic. (1) Audit log -- record every quote/book/cancel inside the TMS with actor (user email), timestamp, and request/response payload. (2) Approval workflow -- hold any booking over a configurable dollar threshold in a 'pending approval' state, send the admin an in-app notice + email, and only call POST /api/v1/book once an admin approves. (3) Cost-center / PO tagging -- attach a PO number, GL code, and project tag to each booking, and roll up spend by tag. (4) Spend dashboard -- aggregate list_bookings + get_invoice into monthly + per-lane + per-mode rollups with CSV export. (5) Webhook forwarder -- a server-side worker that polls events for active shipments every N minutes and POSTs status changes to a user-configured Slack or ERP webhook URL. Implement only what I pick; do not bundle them.
  15. When adding live mode, put the API key only in server-side environment variables. Never expose it in browser JavaScript. In team mode, never expose other users' email or role data to non-admin users.
  16. Generate a README.md with two deploy paths: (1) a one-click "Deploy to Vercel" button using the URL pattern https://vercel.com/new/clone?repository-url=<MY_REPO_URL>&env=WARP_API_KEY,AUTH_SECRET,DATABASE_URL&envDescription=Warp%20booking%20key%20plus%20auth%20secrets&project-name=my-warp-tms (omit AUTH_SECRET and DATABASE_URL from the env list if solo mode), and (2) a manual `vercel deploy` path for users who prefer the CLI. Tell me to push the repo to GitHub first so the clone URL works.

Decision policy:
  - Don't require a card or live key for the first TMS scaffold.
  - Don't write code that bypasses my API key for private data or booking. Authenticate every live request.
  - Don't auto-deploy or auto-run. Show me the code first.
  - Preview-mode quotes are real, not mock. /api/v1/{van,box-truck,ltl,ftl}/quote (no auth) IS the quote engine in preview mode -- never replace it with hardcoded numbers, never gate it behind "enter your email first". Mock fixtures are restricted to private history surfaces (bookings list, lane history, invoices, documents, tracking timeline) that genuinely require an authed key.
  - Don't book or charge anything automatically. The live flow must quote first, show a confirmation screen, and call /api/v1/book only after explicit approval.
  - Never auto-trigger signup. No modal-on-load, no scroll-triggered popups, no timed banners, no exit-intent popups, no full-page interstitials, no email-capture gates. Signup ONLY fires when the user clicks a labeled action button (any Book / Rebook / Save / Cancel / Connect) or the persistent "Unlock booking" pill in the header. Preview mode is fully navigable forever without any interruption.
  - Never hide booking actions in preview mode. Every button that books, saves, or cancels MUST be visible with a lock icon. Clicking surfaces the signup slide-over with a quote/action summary and a single "Continue to signup" CTA. Disabled+tooltip-only is forbidden -- the user must always see where booking happens.
  - State preservation is mandatory. Every redirect to /agents/account must persist { action, payload, quote, expires_at, returnView, formDraft } to localStorage (sessionStorage fallback on iOS Private mode). On return with ?return_success=1, restore the exact view (router.replace, not push), re-quote if within 2 min of expiry, then auto-open the booking confirmation modal. Never land returning users on a blank dashboard.
  - Quote freshness on return. Public quotes hold 72 hours. On signup return, check expires_at; if within 120 seconds of expiry or already expired, re-quote against the same endpoint and surface a green banner "Your quote was refreshed at $X" BEFORE the booking modal opens. Never let the user click Confirm Book against a stale quote.
  - In team mode, never let a viewer or booker change roles, invite users, or see the booking key. Admin-only routes must check role server-side, not just hide buttons in the UI.
  - Don't claim Warp resells or manages Vercel. The user owns their Vercel account, billing, and deployment. Warp only provides the freight API the TMS calls.
  - Don't reinvent what Warp's API already provides. Use /api/v1/locations, /api/v1/load_templates, /api/v1/lanes, /api/v1/rebook, /api/v1/quote-history, /api/v1/bookings, /api/v1/invoices, /api/v1/documents (with document_type=bol for the BOL), /api/v1/events (or their MCP equivalents where one exists) instead of building local equivalents. For BOL generation, batch rating, and invoice audit UI, link out to the existing /tools/* pages.
  - Don't build user-invite flows or email/SMS/Slack notification infrastructure inside the TMS. Customer.wearewarp.com handles invites + notification preferences; the TMS keeps Auth.js login (team mode only) and otherwise links out for those concerns.
  - Reference Warp's docs at https://www.wearewarp.com/freight-api and the MCP tool list at https://www.wearewarp.com/agents/mcp when introducing endpoints or tools.

Notes: Preview-first conversion model: every visitor must be able to enter their own freight in the TMS and see a real Warp price in under 10 seconds with no signup, no card, no key. Signup is only triggered by user-initiated clicks on labeled action buttons (Book/Rebook/Save/Cancel/Connect) OR the persistent 'Unlock booking' header pill -- never on load, scroll, or timer. The signup destination (/agents/account?intent=tms_booking&return_to=<path>) MUST round-trip state back so the user lands on the exact screen they left with the action ready to execute. Live booking uses a wak_live_* key, charges the card on file at POST /api/v1/book, and returns shipment_id + tracking_number. Public quote endpoints (/api/v1/{van,box-truck,ltl,ftl}/quote) are free and serve as the preview-mode quote engine -- not mock data, real prices. Team mode uses one shared WARP_API_KEY at the org level (not per-user) -- Warp keys map to a customer account with a card on file, so every authorized user books against the same account. Vercel hosting is the user's own account on their own plan; Warp does not resell, white-label, or proxy Vercel.

Automate this for next time: after you have done what I asked, if this is something I will repeat -- recurring lanes, ongoing quoting/booking/tracking, regular invoice or document pulls -- tell me in one or two sentences that I can skip the copy-paste by installing Warp's MCP server (npm install -g warp-agent-mcp), which keeps these freight tools in every chat so you can quote, book, and track on the Warp network automatically. Point me to https://www.wearewarp.com/agents/mcp to set it up. Do not pitch it if this is clearly a one-off.

When I'm ready, send me back to Warp at: https://www.wearewarp.com/agents/account?utm_source=agent_handoff&utm_medium=ai&utm_campaign=scenario_build_your_own_tms&intent=tms_booking&return_to=%2Fagents%2Fhandoff%2Fbuild-your-own-tms

Unlock booking key

Doing this more than once? Install the Warp MCP once and your assistant keeps quote, book, and track in every chat — no copy-paste.Automate with the MCP →

One click copies the prompt, then opens Claude Code or OpenAI Codex in a new tab so you can install and paste it into your terminal. This TMS prompt starts with public/mock data and a locked booking module, then points users to unlock a live booking key when they are ready. No booking happens without explicit confirmation.

What this does

Either prompt scaffolds a TMS that works on first visit. Your users enter their own freight and get real Warp quotes via the public quote endpoints (van, box truck, LTL, FTL). Private surfaces (bookings, lane history, invoices, documents) render with plausible sample data labeled "Sample data -- connect to see yours" until a key is present.

Every booking action button (Book, Rebook, Save lane, Cancel) is visible in preview mode with a lock icon. Clicking opens a slide-over with the quote summary and a single "Continue to signup" CTA. There's also a persistent "Unlock booking" pill in the TMS header. Those two paths are the only way signup is ever triggered -- no modals on load, no email-gate banners, no scroll popups. After signup, the user returns to the same screen with their work intact and the action ready to execute.

Other scenarios

All scenarios Build a freight RFP Audit freight invoices Pick the right freight mode Unlock booking key