Build your own front door.
Funal runs the rest.

# Setup prompt: install the Funal site tag

You are installing the Funal site tag on a business's marketing website. The
tag connects the site to Funal's ad-click attribution and journey tracking:
the ad click, page views, form submissions, and the eventual booking join
into one identity.

## What you need from the human before starting

1. Their Funal write key. It starts with fnl_wk_. If YOU have Funal's MCP
   server connected, fetch it yourself with the track_write_key tool (it
   also returns the exact snippet). Otherwise the human gets it from the
   Funal team. Never invent one.
2. Which website platform they use (Wix, Webflow, or other).
3. If their forms live on a hosted form tool with its own domain (FormCrafts,
   Typeform, etc.): which one.

## Install

Add this to the site's global <head>, on ALL pages, with their real write
key in data-write-key:

    <script async src="https://go.funal.link/t.js" data-write-key="THEIR_WRITE_KEY"></script>

The write key namespaces every event to their organization. It is public by
design (like a Segment write key) but revocable: if it ever leaks or gets
spammed, rotate it (track_write_key with rotate:true) and update the
snippet. Events whose click attribution proves a different org are dropped
by the server, so a wrong key means silently lost data: copy it exactly.

go.funal.link is Funal's shared link domain and works for every org. If the
human has a custom link domain configured in Funal (looks like
go.their-brand.com), swap it in for go.funal.link here and in every URL
below; otherwise do not ask, just use the default. Keep data-write-key
either way.

- Wix: Settings -> Custom Code -> Add Custom Code -> paste, apply to All
  Pages, load in Head.
- Webflow: Site Settings -> Custom Code -> Head Code -> paste -> Save and
  publish.
- If their call-to-action links out to a hosted form tool, add the tool's
  domain to the tag: data-decorate="formcrafts.com" (comma-separate several).

## If they use a hosted form tool

In the form builder, add two hidden fields named exactly click_id and
link_variant, each prefilled from the URL parameter of the same name. The
tag decorates the CTA link so those parameters arrive on the form URL; the
hidden fields carry them through the form's own webhooks back to Funal.

If the form tool redirects back to the site after submit with the
visitor's email as a query parameter (FormCrafts thank-you pages often
do), add data-identify-param="email" (the actual parameter name) to the
script tag. The tag then hashes that one parameter's value in the browser
(SHA-256; the raw email is never sent) and ties the visitor's session to
their lead. Only the named parameter is ever read, and only when this
attribute is present.

## Optional JavaScript API

The tag exposes window.funal for pages that know more than the tag can
observe. Add the queue line so calls made before the tag loads still work:

    <script>window.funal=window.funal||function(){(funal.q=funal.q||[]).push(arguments)}</script>

    funal('page')                                  // SPA route change
    funal('track', 'quiz_completed', { score: 12 }) // custom moment
    funal('identify', { email: userEmail })         // hashed in-browser

track names are stored namespaced (custom:quiz_completed). identify never
sends the raw email — it is hashed before any network call. Most installs
need none of this; the tag's automatic behavior covers normal sites.

## Verify (do not skip)

1. Open any page of the site with ?click_id=brief-test-123&link_variant=a
   appended to the URL.
2. In the browser console, confirm localStorage has _fnl_cid =
   "brief-test-123" and _fnl_anon = "c_brief-test-123".
3. Confirm the tag loaded: fetch https://go.funal.link/t.js and expect
   HTTP 200 with JavaScript.
4. Confirm the beacon sink accepts and namespaces: POST to
   https://go.funal.link/t with body
   {"writeKey":"THEIR_WRITE_KEY","events":[{"name":"page_viewed","anonymous_id":"a_brief_test"}]}
   and expect HTTP 202 with {"accepted":1,"dropped":0}. accepted:0 almost
   always means the write key is wrong or was rotated; re-check it.
5. If forms are native to the site: submit a test entry and confirm the
   submission contains hidden click_id / link_variant / anonymous_id fields.
6. Report each check's result to the human, then delete the test entry if
   one was created.

The tag is safe to install twice (it runs once) and never blocks or alters
the site; a failed network or blocked script is a silent no-op.

# Setup prompt: connect Funal MCP to this coding agent

You are connecting Funal's MCP server to the agent environment you are
running in (Claude Code, Cursor, Codex, or another MCP client). Funal
exposes the business's working graph (records, search, analytics,
forms, workflows) as MCP tools, scoped to the business's organization.

## What you need from the human before starting

1. Their Funal API key. It is issued during onboarding; if they do not have
   one, they should ask the Funal team. Treat it like a password.
2. Which agent they run: Claude Code, Cursor, Codex, or something else.

## Connect

Endpoint (Streamable HTTP): https://funal-api.alex-boquis.workers.dev/mcp
Auth: an "Authorization: Bearer <API key>" header on every request.

- Claude Code:

      claude mcp add --transport http funal \
        https://funal-api.alex-boquis.workers.dev/mcp \
        --header "Authorization: Bearer THEIR_KEY"

- Cursor: add to .cursor/mcp.json (project) or ~/.cursor/mcp.json (global):

      { "mcpServers": { "funal": {
        "url": "https://funal-api.alex-boquis.workers.dev/mcp",
        "headers": { "Authorization": "Bearer THEIR_KEY" } } } }

- Codex: add to ~/.codex/config.toml (Codex speaks stdio, so bridge the
  HTTP endpoint with mcp-remote):

      [mcp_servers.funal]
      command = "npx"
      args = ["-y", "mcp-remote",
        "https://funal-api.alex-boquis.workers.dev/mcp",
        "--header", "Authorization: Bearer THEIR_KEY"]

- Any other client without native Streamable HTTP support: use the same
  mcp-remote bridge as Codex.

## Verify (do not skip)

1. Restart or reload the agent so it picks up the new server.
2. Confirm the tool list includes atoms_list, atoms_search, and search.
3. Call atoms_count with kind "client". Any number, even 0, proves auth
   and org scoping are live. A 401 means the key is wrong or revoked; stop
   and tell the human.
4. Report the connected tool count and the atoms_count result to the human.

Never echo the API key back into chat output, logs, or committed files;
config files holding it (~/.cursor/mcp.json, ~/.codex/config.toml) should
stay out of version control.

# Setup prompt: build a front door on Funal

You are building the visitor-facing screens for a business that runs on
Funal: an application, a quiz, a booking page, or all three in one flow. The
business owns the design. Funal is the backend: it writes the questions,
qualifies the answers, offers real calendar time, keeps the record, and
follows up after the booking. Nothing of Funal's renders on the page.

## What you need from the human before starting

1. Their Funal organization id (starts with org_) and which form to build
   against. If YOU have Funal's MCP server connected, find both yourself
   with form_list and scheduling_targets. Use the form that is already
   active. Do not create or activate a form unless the human asks.
2. Their designs (a Figma file, screenshots, or a description).
3. Nothing else. The visitor flow needs NO API key. Never put a Funal API
   key in browser code, in a NEXT_PUBLIC_ variable, or in git.

## Read the reference first

Fetch https://funal.ai/docs/api.md and read all of it. Endpoint shapes there
are taken from the source code. Follow them exactly.

## Build in this order

1. Prove the API before styling. With plain fetch calls:
   - GET the form. Note its opener, contact fields, booking target, and
     the interview length.
   - Run the interview: POST /next with turn, answers, known, and a stable
     random anonymous_id, until done is true. Turn 1 (the opener) is yours
     to render; the server never sends it. Pass known back unchanged.
   - POST /submit. Read action (book or nurture), the reflection, and the
     token that unlocks booking.
   - Read availability for the form's booking target with days=14.
   - Make a test booking (see Test safely).
2. Then draw it from the designs:
   - A progress indicator from the interview length ("question 3 of about
     6"; closers are only asked when needed, so never show an exact count).
   - A waiting state between questions and a processing screen on submit.
     Each is a model call that takes one to a few seconds. No streaming.
   - Back (drop later answers, step turn back, call /next again) and resume
     (GET /draft with the stored anonymous_id on load).
   - A date picker that disables days with no openings, in the visitor's
     own timezone.
   - A confirmation screen that uses the booking's action token to show the
     join link, an add-to-calendar link, and reschedule and cancel.
3. Add tracking: install the Funal site tag (see the tracking setup prompt
   on https://funal.ai/docs), call funal('page') on each step, and pass the
   tag's click_id, link_variant and anonymous id on submit so the record
   keeps its attribution.

## Rules

- Always pass duration explicitly on availability and booking calls.
- On a 409 from booking, refetch availability and ask again.
- Treat interview, days, actionToken and meetingUrl as optional in
  responses, and fall back without crashing when one is absent.
- Error bodies are { error, code? }. Show a retry on a network error.

## Test safely

- Only ever test with an email ending in @qa.funal.test.
- Pass dryRun: true on every test booking. A dry run makes no calendar
  event and returns no action token, so reschedule and cancel need one real
  booking to verify. Ask the human before making a real one, and cancel it
  after.
- Tell the human the ids of any test records you created so they can be
  removed.

## Verify (do not skip)

1. A full interview runs against the real form, start to done, with no
   mock data.
2. Submit returns a record id and an action, and the right end state shows.
3. The picker shows real openings and a dry-run booking returns success.
4. No Funal API key appears anywhere in the built browser bundle.
5. Report each check to the human, with the test record ids.