agent handoff

Stop the agent from rebuilding what already works.

This is the buyer handoff layer: product direction, safe edit boundaries, service setup rules, and verification commands in one copyable prompt.

Protects the rails

Billing, webhooks, storage, email, usage, approvals, and delivery are named as preserve zones.

Forces verification

The prompt tells the agent to run setup checks, tests, linting, and build before launch work is accepted.

Keeps scope tight

The buyer fills in audience, paid outcome, workflow, tools, and launch deadline before edits begin.

choose before prompting

Pick paid beta, freemium with upgrade, or lifetime deal before asking the agent to customise the repo. This keeps pricing, checkout copy, usage limits, and onboarding pointed at one commercial path.

View launch flows

one-paste prompt

Give this to your coding agent

You are working inside Toolbound Stack, an agent-ready SaaS boilerplate for launching paid, tool-using AI products.

My product direction:
- Audience: [who this is for]
- Paid outcome: [what they buy]
- Core workflow: [what the app does for them]
- Data sources or tools: [documents, URLs, APIs, email, CRM, Search Console, etc.]
- Launch deadline: [date or "as soon as verified"]

Read first:
- FIRST_RUN.md
- START_HERE.md
- README.md
- AGENTS.md
- CLAUDE.md
- ARCHITECTURE.md
- DOMAIN_GLOSSARY.md
- docs/codebase-map.md
- MONETISATION_FLOWS.md
- docs/agent-readiness-checklist.md
- docs/premium-product-checklist.md
- docs/buyer-handoff/how-this-repo-works-prompt.md
- docs/buyer-handoff/setup-wizard.md
- docs/buyer-handoff/connectors/README.md

Preserve these existing product rails:
- Stripe Checkout and signed webhook verification.
- Postgres purchase, release, and workflow records.
- Resend transactional emails.
- R2 release download delivery.
- Usage limits, cost metadata, citations, approval gates, and workflow logs.
- Existing commands: npm run setup:check, npm run test, npm run lint, npm run build, npm run verify.

Before editing:
1. Run npm run setup:check.
2. Pick the closest monetisation flow from MONETISATION_FLOWS.md: paid beta, freemium with upgrade, or lifetime deal.
3. Run the SEO and agent-readiness audit from docs/agent-readiness-checklist.md if the task touches public pages, routing, metadata, or launch copy.
4. Map my product direction to the closest existing customisation brief in docs/recipes/. If none fits, use docs/recipes/add-new-workflow.md.
5. State the product customisation plan in 5 bullets or fewer.
6. List the files you expect to edit.
7. Flag whether any billing, auth, webhook, database, email, usage-limit, or citation code is involved.
8. Make the smallest change that gets the product closer to a paid launch.

Service setup rules:
- Never ask me to paste API keys into source files.
- Use .env.local for live keys.
- Update .env.example only when adding a new variable name.
- Use official APIs, SDKs, or CLIs before browser automation.
- Follow docs/buyer-handoff/connectors/ for Stripe, Resend, Postgres, Cloudflare, and Google Search Console.
- Follow docs/agent-readiness-checklist.md before changing public SEO, robots, sitemap, llms.txt, structured data, or route indexing.

Verification rules:
- For product UI or logic changes, run npm run test and npm run lint.
- For launch or infrastructure changes, run npm run setup:check and npm run verify.
- If a command fails, explain the exact blocker and fix it before continuing.

Current job:
Turn this boilerplate into one specific paid SaaS product for the audience above, keeping the purchase-to-handoff flow working.