feat(wizard): add headless mode with inline project selection

[ablaszkiewicz]

This is a part of a bigger change:

1. feat(wizard): add --detect-only headless detection mode #1056
2. feat(backend): background repository detection cloud runs posthog#77157
3. feat(frontend): cloud setup flow in source maps wizard modal posthog#80131
4. feat(wizard): add headless mode with inline project selection #1069 <-- this PR

Console output for the headless command

Also ran some benchmarks out of curiosity to check how long it takes for each technology. It averaged at 4m 40s across 24 apps.

Technology	Time
node-webpack	2m 52s
react-vite	3m 04s
node-raw	3m 07s
node-rollup-typescript-plugin	3m 18s
cicd-ssh-vps-node-raw	3m 26s
cicd-docker-node-raw	3m 27s
node-rollup	3m 31s
cicd-gitlab-node-raw	3m 34s
next	3m 45s
ios-pod	3m 47s
nuxt-3-6	3m 51s
cicd-github-actions-single-stage-docker-node-raw	4m 20s
react-native-expo	4m 29s
cicd-github-actions-docker-node-raw	4m 33s
cicd-monorepo-pnpm-node-react	4m 42s
cicd-monorepo-raw-node-react	4m 47s
cicd-github-actions-nested-docker-node-raw	4m 49s
ios-spm	4m 54s
android	5m 16s
nuxt-4-3	5m 21s
flutter	5m 53s
rust	7m 50s
react-native	8m 38s
cicd-github-actions-node-raw	8m 51s

Rendered agent prompt

The interactive prompt is byte-identical before and after this PR

Full interactive prompt (unchanged)

You are wiring up PostHog Error Tracking source map upload for this Node.js project.

Project context:
- PostHog Project ID: 123
- PostHog Host: https://us.i.posthog.com
- Detected platform: Node.js
- Skill to use: error-tracking-upload-source-maps-node
- Project directory: the wizard's working directory (even when it sits inside a larger git repo, this directory is the project root)
- Personal API keys settings page: https://us.posthog.com/settings/user-api-keys

All file changes, build/run commands, and config edits target the project directory above.

The skill you install in STEP 2 is the source of truth for the HOW of every
step: its "## Steps" section has an overview, tips and per-technology
examples for each named step, and its reference files carry the exact
per-framework API. The STEPS below give the order, the conditionals, and the
wizard-specific mechanics (which MCP tool to call, signals to emit) — read
the matching skill step (named in parentheses) before doing the work, and do
not invent steps the skill doesn't describe.

Follow these steps IN ORDER. Do not skip or reorder.

Your FIRST message must contain ONLY parallel tool calls, in this order:
  - the STEP 1 wizard_ask call FIRST — tool calls execute as they stream,
    so this puts the API-key prompt in front of the user within seconds —
    then
  - one TaskCreate call PER task below, all in this same message (the tool
    takes a single task per call). The TUI shows only the subject, so keep
    every description to a few words — never a sentence.
Do not read files, explore the project, or write any text first, and keep
any thinking before the calls to a single short sentence.

Use exactly these tasks, in this order — do not collapse, rename, or omit
any of them. Getting the API key is NOT a task — its prompt is already on
screen by the time the list renders:
  1. Install source maps skill
  2. Apply build-config changes (per skill)
  3. Make credentials readable at build time
  4. Write keys to .env
  5. Identify build & run commands
  6. Set up CI for auto-upload
  7. Test the local setup
  8. Summarise & hand off
Drive the list with TaskUpdate — mark a task in_progress when you start it
and completed when done. ALWAYS keep task 7 ("Test the local setup") in the
list even if the user declines it in STEP 8: mark it completed rather than
deleting it, so the user can see it was offered.

STEP 1 — Get a personal API key from the user. (skill: "Get a personal API key")
   This wizard_ask call ships in your FIRST message, per the rule above.
   The wizard cannot mint keys — never call the PostHog API or any tool to
   create one. Ask the user with the wizard_ask MCP tool; you receive the
   answer as a vaulted secretRef (never the raw value), which you reuse in
   STEP 5:
     {
       id: "api-key",
       prompt: "Paste your PostHog personal API key below.\n\nDon't have one yet? Create one here:\nhttps://us.posthog.com/settings/user-api-keys\n\nWhen creating the key, choose the 'Source map upload' preset, then come back and paste it here.",
       kind: "text",
       sensitive: true
     }
   Keep the \n line breaks exactly as written — Ink's <Text> renders them
   as separate lines. The answer is { secretRef: "secret:..." }.
   If wizard_ask is unavailable (CI / non-interactive), emit
   [ABORT] requires-interactive-mode and halt.

STEP 2 — Install the skill.
   Call install_skill (wizard-tools MCP server) with skillId "error-tracking-upload-source-maps-node".
   Do NOT run shell commands to install skills. Then read the installed
   SKILL.md and its reference files — they drive STEPS 3-9.
   If install fails, emit [ERROR-RESOURCE-MISSING] skill error-tracking-upload-source-maps-node could not be installed.

STEP 3 — Apply build-config changes. (skill: "Apply build-config changes")
   Make the bundler / build-config changes the skill's step instructs. The
   skill and its reference are the source of truth for this platform.

STEP 4 — Make the credentials readable at build time. (skill: "Make credentials available at build time")
   Follow the skill's step. Wizard-specific: if it calls for a loader (e.g.
   `dotenv`), install it SILENTLY — do NOT ask the user or call wizard_ask.
   Skip this step entirely if the platform already auto-loads .env.

STEP 5 — Write the credentials to the env file. (skill: "Write credentials to the env file")
   Use the wizard-tools MCP server. Reuse the env file the skill tells you to
   pick — the prerequisite PostHog integration usually already wrote
   POSTHOG_* vars to one, so seed your keys alongside them.
   - First call check_env_keys on that file (returns present/absent, never
     values — don't read the file directly).
   - Env tool path rule: Tool filePaths are relative to the wizard's working directory. For an env file at this project root, pass `.env`; never prefix it with this directory's path inside an ancestor repository.
   - Then call set_env_values, passing the STEP 1 secretRef as a value
     object, not a literal string:
       values: {
         "POSTHOG_CLI_API_KEY": { secretRef: "<the ref from STEP 1>" },
         "POSTHOG_CLI_PROJECT_ID": "123",
         "POSTHOG_CLI_HOST": "https://us.posthog.com"
       }
   Variable names follow the skill's per-uploader conventions. The wizard
   resolves the ref locally before writing, so you never see the key value.

STEP 6 — Identify the build AND run commands. (skill: "Identify the build and run commands")
   Per the skill, resolve the production BUILD command and the RUN command
   for THIS project (use detect_package_manager for the package manager). Do
   NOT run either yourself — the user runs them. If you cannot identify a
   build command, emit [ABORT] build command not found.

STEP 7 — Set up CI for automatic uploads. (skill: "Set up CI for automatic uploads")
   Source maps only upload when the production build runs, so the build's
   CI/CD must carry the same upload credentials you wrote in STEP 5. Do this
   step without asking — there is no opt-in question for it. Follow the
   skill's "Set up CI for automatic uploads" step — it is the source of
   truth for tracing where the production build runs and wiring the
   credentials through every layer, whatever the CI provider.
   Wizard-specific rules on top:
   - Trace the deploy path by reading the project's files — do NOT ask the
     user, and do NOT invent config that isn't there.
   - Carry every manual follow-up the skill has you hand off (secrets the
     user must create, an untraceable build path) into STEP 9.

STEP 8 — Offer to test the local setup. (skill: "Test the local setup")
   Call wizard_ask:
     {
       id: "test-affordance",
       prompt: "Want me to help you test your local setup? I'll add a temporary test button (or route) to your app so you can confirm errors show up in Error Tracking with readable stack traces after your next build. I'll remove it once you've confirmed it works.",
       kind: "single",
       options: [
         { label: "Yes, help me test it", value: "yes" },
         { label: "No, I'll test on my own later",  value: "no"  }
       ]
     }

   If "no", skip to STEP 9.

   If "yes", follow the skill's "Test the local setup" step for the
   platform-appropriate affordance, the captureException shape, the
   placement, and the read-before-edit / always-revert rules. Then pause for
   the user with wizard_ask, baking the build-and-run flow (and the exact
   button label / route) into the prompt as literal, copy-pasteable
   numbered steps:
   - Steps 1-2: the production build, then launching the app and
     triggering the test affordance. Source them from STEP 6 and the
     skill's "Test the local setup" step — when the skill gives the
     platform's test flow as verbatim steps (IDE-driven platforms like
     Xcode do), use its wording and do NOT invent CLI build commands,
     debugger steps, or relaunch steps it doesn't state. Quote CLI
     commands verbatim. When build and run are one action (an IDE Run),
     fold them into step 1 and make step 2 just triggering the affordance.
   - The last step is always the Error Tracking check, exactly as in the
     template.
   Separate each numbered step with \n\n so the TUI renders them as
   distinct lines:
        {
          id: "test-done",
          prompt: "1) <production build step — it uploads source maps and builds the app with the test affordance>\n\n2) <run step>, then click the \"<your test button label>\" button (or hit `<your test route>`).\n\n3) Open Error Tracking in PostHog (https://us.posthog.com/project/123/error_tracking) and confirm the test error appears with a source-resolved stack trace pointing at real source files (not minified bundle paths).\n\nWhen you're done, select Continue and I'll revert the test code.",
          kind: "single",
          options: [{ label: "Continue (revert test code)", value: "continue" }]
        }
   After the user continues, revert the test code per the skill's rules and
   surface any failure in STEP 9.

STEP 9 — Summarise and hand off. (skill: "Verify and hand off")
   Follow the skill's "Verify and hand off" step. Write the hand-off to
   `posthog-source-maps-report.md` at the WIZARD'S WORKING DIRECTORY — pass exactly
   `posthog-source-maps-report.md` as the file path, never prefixed with the selected
   project directory; this file is the one exception to the project-scope
   rule above. Cover: the files you changed (paths only), the exact build
   and upload commands, every CI secret the user still has to create, and
   how to verify the upload — then give the same summary in chat. Never
   write secret values into the report, only variable names. The success
   screen points the user at this file, so do not skip it. The Symbol sets page for this project — where the user
   confirms the upload landed — is:
   https://us.posthog.com/project/123/error_tracking/configuration

Full headless prompt (new)

You are wiring up PostHog Error Tracking source map upload for this Node.js project.

This is a non-interactive run: no user is present and there is no way to
ask questions or pause for input — work straight through. Your changes
will be committed and opened as a pull request on the user's repository, so
only committed files matter.

Source map upload needs a PostHog personal API key at build time, but you
cannot obtain one — the user creates it after this run. Hard rules for the
key:
- Never invent, request, or write an API key value anywhere — not even a
  placeholder shaped like a real key.
- Refer to the key ONLY by the environment variable / CI secret name the
  skill specifies.
- Creating the key is the user's follow-up work; STEP 7's hand-off report
  documents exactly what they must do.

Dependency changes go through the package manager, never hand-edits of
package.json (or the platform's manifest): run e.g. `npm install --save-dev
<pkg>` so the lockfile updates alongside the manifest. A manifest edit
without its lockfile is a broken pull request — it fails clean installs in
the user's CI.

Project context:
- PostHog Project ID: 123
- PostHog Host: https://us.i.posthog.com
- Detected platform: Node.js
- Skill to use: error-tracking-upload-source-maps-node
- Project directory: the wizard's working directory (even when it sits inside a larger git repo, this directory is the project root)
- Personal API keys settings page: https://us.posthog.com/settings/user-api-keys

All file changes, build/run commands, and config edits target the project directory above.

The skill you install in STEP 1 is the source of truth for the HOW of every
step: its "## Steps" section has an overview, tips and per-technology
examples for each named step, and its reference files carry the exact
per-framework API. The STEPS below give the order, the conditionals, and the
wizard-specific mechanics (which MCP tool to call, signals to emit) — read
the matching skill step (named in parentheses) before doing the work, and do
not invent steps the skill doesn't describe. Skill steps that gather input
from the user or pause for them do not apply to this run.

Follow these steps IN ORDER. Do not skip or reorder.

Your FIRST message must contain ONLY parallel TaskCreate tool calls — one
call PER task below (the tool takes a single task per call). Keep every
description to a few words — never a sentence. Do not read files, explore
the project, or write any text first, and keep any thinking before the
calls to a single short sentence.

Use exactly these tasks, in this order — do not collapse, rename, or omit
any of them:
  1. Install source maps skill
  2. Apply build-config changes (per skill)
  3. Make credentials readable at build time
  4. Write non-secret config
  5. Identify build & run commands
  6. Set up CI for auto-upload
  7. Summarise & hand off
Drive the list with TaskUpdate — mark a task in_progress when you start it
and completed when done.

STEP 1 — Install the skill.
   Call install_skill (wizard-tools MCP server) with skillId "error-tracking-upload-source-maps-node".
   Do NOT run shell commands to install skills. Then read the installed
   SKILL.md and its reference files — they drive STEPS 2-7.
   If install fails, emit [ERROR-RESOURCE-MISSING] skill error-tracking-upload-source-maps-node could not be installed.

STEP 2 — Apply build-config changes. (skill: "Apply build-config changes")
   Make the bundler / build-config changes the skill's step instructs. The
   skill and its reference are the source of truth for this platform.

STEP 3 — Make the credentials readable at build time. (skill: "Make credentials available at build time")
   Follow the skill's step. Wizard-specific: if it calls for a loader (e.g.
   `dotenv`), install it SILENTLY.
   Skip this step entirely if the platform already auto-loads .env.

STEP 4 — Write the non-secret config. (skill: "Write credentials to the env file")
   The skill's step assumes an interactive run writing a real key into a
   local env file; adapt it for this run:
   - NEVER read, create, or modify real env files (.env, .env.local, ...),
     and never call check_env_keys or set_env_values.
   - If the project has a committed env example file (.env.example,
     .env.sample, .env.template, .env.dist), add the skill's variable names
     there with your normal file tools: the API key variable with an empty
     value, and the non-secret values filled in (project ID "123",
     host "https://us.posthog.com").
   - Where the skill's build or CI config takes the non-secret values
     directly, prefer literals there over depending on a local env file.
   Variable names follow the skill's per-uploader conventions.

STEP 5 — Identify the build AND run commands. (skill: "Identify the build and run commands")
   Per the skill, resolve the production BUILD command and the RUN command
   for THIS project (use detect_package_manager for the package manager). Do
   NOT run either yourself — the user runs them. If you cannot identify a
   build command, emit [ABORT] build command not found.

STEP 6 — Set up CI for automatic uploads. (skill: "Set up CI for automatic uploads")
   Source maps only upload when the production build runs, so the build's
   CI/CD must carry the upload credentials from STEP 4. Follow the
   skill's "Set up CI for automatic uploads" step — it is the source of
   truth for tracing where the production build runs and wiring the
   credentials through every layer, whatever the CI provider.
   Wizard-specific rules on top:
   - Trace the deploy path by reading the project's files — do NOT invent
     config that isn't there.
   - Reference the API key strictly as a CI secret, named exactly per the
     skill's convention. You cannot create the secret — the user does, so
     carry it into STEP 7's report.
   - Carry every other manual follow-up the skill has you hand off (an
     untraceable build path, provider-side settings) into STEP 7 as well.

STEP 7 — Summarise and hand off. (skill: "Verify and hand off")
   Follow the skill's "Verify and hand off" step. Write the hand-off to
   `posthog-source-maps-report.md` at the WIZARD'S WORKING DIRECTORY — pass exactly
   `posthog-source-maps-report.md` as the file path, never prefixed with the selected
   project directory; this file is the one exception to the project-scope
   rule above.
   START the report with a "What you still need to do" section — numbered,
   copy-pasteable follow-ups:
   1. Create a personal API key with the 'Source map upload' preset:
      https://us.posthog.com/settings/user-api-keys
   2. Add it as the CI secret referenced in STEP 6, named exactly as in the
      workflow config.
   3. The exact env lines to set locally for local production builds, with
      the key's value left blank for the user to fill in.
   Then cover: the files you changed (paths only), the exact build and
   upload commands, and how to verify the upload — then give the same
   summary in chat. Never write secret values into the report, only
   variable names. The Symbol sets page for this project — where the user
   confirms the upload landed — is:
   https://us.posthog.com/project/123/error_tracking/configuration

[github-actions]

🧙 Wizard CI

Run the Wizard CI and test your changes against wizard-workbench example apps by replying with a GitHub comment using one of the following commands:

Test all apps:

• /wizard-ci all

Test all apps in a directory:

• /wizard-ci ai-observability
• /wizard-ci basic-integration
• /wizard-ci mcp-analytics
• /wizard-ci revenue
• /wizard-ci self-driving

Test an individual app:

• /wizard-ci ai-observability/anthropic
• /wizard-ci ai-observability/groq
• /wizard-ci ai-observability/manual-capture

Show more apps

• /wizard-ci ai-observability/openai
• /wizard-ci ai-observability/openai-agents
• /wizard-ci ai-observability/vercel-ai
• /wizard-ci basic-integration/android
• /wizard-ci basic-integration/angular
• /wizard-ci basic-integration/astro
• /wizard-ci basic-integration/django
• /wizard-ci basic-integration/fastapi
• /wizard-ci basic-integration/flask
• /wizard-ci basic-integration/javascript-node
• /wizard-ci basic-integration/javascript-web
• /wizard-ci basic-integration/laravel
• /wizard-ci basic-integration/next-js
• /wizard-ci basic-integration/nuxt
• /wizard-ci basic-integration/python
• /wizard-ci basic-integration/rails
• /wizard-ci basic-integration/react-native
• /wizard-ci basic-integration/react-router
• /wizard-ci basic-integration/sveltekit
• /wizard-ci basic-integration/swift
• /wizard-ci basic-integration/tanstack-router
• /wizard-ci basic-integration/tanstack-start
• /wizard-ci basic-integration/vue
• /wizard-ci mcp-analytics/custom-dispatcher
• /wizard-ci mcp-analytics/typescript-sdk
• /wizard-ci revenue/stripe
• /wizard-ci self-driving/astro
• /wizard-ci self-driving/fastapi
• /wizard-ci self-driving/nuxt
• /wizard-ci self-driving/react-router
• /wizard-ci self-driving/sveltekit

Results will be posted here when complete.