feat(code): preview-first scaffolding + cleaner prompt

Reordered the agent's workflow so a live preview comes up as fast as
possible:

  1. Clarify
  2. Scaffold the bare minimum that runs (no features yet)
  3. Start the dev server + register the preview NOW
  4. Build it out (with the user watching)
  5. Wire up PostHog instrumentation

The whole thing is one big template-string now instead of an array of
joined fragments — easier to read and easier to edit. The intro message
also tells the user to expect a preview "as fast as possible", and the
build-out step calls out that HMR / re-registration is fine so the
agent isn't shy about restarting.

Generated-By: PostHog Code
Task-Id: 142b4c29-fa5f-4e02-9bc9-de8b22313475

Author: Twixes

apps/code/src/renderer/features/scratchpads/components/ProductCreationDialog.test.tsx

@@ -162,7 +162,7 @@ describe("ProductCreationDialog", () => {
   it("renders the framing banner, name field, prompt input and project radios", () => {
     renderDialog();
     expect(
-      screen.getByText(/First I ask, then build, then deploy/),
+      screen.getByText(/Let's 1\. clarify, 2\. build, 3\. deploy\./),
     ).toBeInTheDocument();
     expect(screen.getByText(/I'll run up to/)).toBeInTheDocument();
     expect(screen.getByPlaceholderText("Uber for dogs")).toBeInTheDocument();

apps/code/src/renderer/features/scratchpads/components/ProductCreationDialog.tsx

@@ -275,7 +275,7 @@ export function ProductCreationDialog() {
                 className="shrink-0 text-(--accent-11)"
               />
               <Text className="font-medium text-[13px] tracking-tight">
-                First I ask, then build, then deploy.
+                Let's 1. clarify, 2. build, 3. deploy.
               </Text>
             </Flex>
             <Text
@@ -297,10 +297,7 @@ export function ProductCreationDialog() {
                   </SegmentedControl.Item>
                 ))}
               </SegmentedControl.Root>{" "}
-              {rounds === 1 ? "round" : "rounds"} of clarifying questions, then
-              scaffold a stack with PostHog analytics, replay, and error
-              tracking wired from the first commit. A live preview opens beside
-              the chat the moment your dev server is up.
+              {rounds === 1 ? "round" : "rounds"} of clarifying questions, then build it with a live preview, then help you deploy.
             </Text>
           </Flex>
 

apps/code/src/renderer/sagas/scratchpad/scaffolding-prompt.ts

@@ -18,9 +18,9 @@ export interface ScaffoldingPromptInput {
 }
 
 /**
- * Returns the verbatim scaffolding prompt text. Constraints embedded in the
- * prompt are duplicated as agent-facing rules; do not rely on this being
- * structured — it is a single text block.
+ * Returns the verbatim scaffolding prompt text. The agent reads this as
+ * markdown — keep it human-readable, keep guardrails explicit, and don't
+ * rely on structured parsing.
  */
 export function buildScaffoldingPrompt(input: ScaffoldingPromptInput): string {
   const {
@@ -32,40 +32,42 @@ export function buildScaffoldingPrompt(input: ScaffoldingPromptInput): string {
     taskId,
   } = input;
 
-  return [
-    `You are scaffolding a brand-new app called **${productName}** in \`${scratchpadPath}\`. The user has given you the following idea:`,
-    "",
-    "---",
-    initialIdea,
-    "---",
-    "",
-    "**Before you start anything else**, send a short message to the user (one or two sentences) telling them what to expect: that you'll ask a few clarifying questions, then scaffold the project, install dependencies, and start a dev server — and that **the moment the dev server is up a preview tab will open automatically**. Then proceed with the workflow below.",
-    "",
-    "Follow this workflow:",
-    "",
-    `1. **Socratic clarification.** Before writing any code, run up to **${rounds}** rounds of Socratic clarification using the \`posthog_code__askClarification\` tool. Each round may include multiple questions; **every question must include a \`prefilledAnswer\`** representing your best guess so the user can accept defaults with one keystroke. Cover at minimum: app type (web/mobile/CLI/etc.), stack choice (your recommendation; the user can override), and any product-specific behaviour you can't safely guess. PostHog instrumentation is implicit — don't ask about it. Skipping clarification entirely is allowed when the request is fully specified, but encouraged for at least one round otherwise.`,
-    "",
-    `2. **Scaffold.** Pick a production-grade, simple, mainstream stack appropriate for the product. Run the necessary scaffolding commands inside \`${scratchpadPath}\` (e.g. \`pnpm create vite\`, \`pnpm create next-app\`, \`cargo new\`, etc.). The directory is already a fresh \`git\` repo on \`main\` with no commits — you can use \`git\` normally, but **do NOT run \`git init\`** in subdirectories or scaffolders that try to (pass \`--no-git\`/equivalent flags). Do not add deployment scripts or hosting configuration.`,
-    "",
-    "   **For any product with a UI, design with intentionality.** Before you write a single line of styling, WebFetch Anthropic's `frontend-design` skill from `https://raw.githubusercontent.com/anthropics/claude-code/main/plugins/frontend-design/skills/frontend-design/SKILL.md` and follow it like a loaded skill — that file IS the skill. If the fetch fails, hold yourself to the same bar inline: pick a distinctive aesthetic direction, distinctive typography (no Inter/Arial/Roboto), dominant color + sharp accents (no cliché purple-on-white gradients), and at least one unforgettable choice.",
-    "",
-    [
-      "3. **PostHog instrumentation.** Run these slash-prompts in order, recovering inside your own loop if any step fails or installs the SDK out of order:",
-      "   - `/instrument-integration`",
-      "   - `/instrument-product-analytics`",
-      "   - `/instrument-error-tracking`",
-      "   - `/instrument-llm-analytics` (only if the product has AI/LLM features)",
-      projectId === null
-        ? "   No PostHog project is linked yet — the user will pick or create one at publish time. Read the API key and host from environment variables (`POSTHOG_API_KEY`, `POSTHOG_HOST`) and add a placeholder `.env.example` documenting them. Do NOT hardcode any project IDs or keys."
-        : `   Use PostHog project ID \`${projectId}\` for these. Read the API key from environment variables (\`POSTHOG_API_KEY\`, \`POSTHOG_HOST\`) and add a placeholder \`.env.example\`.`,
-    ].join("\n"),
-    "",
-    `4. **Preview registration.** Once you have a working dev server, declare it via \`posthog_code__registerPreview({ taskId: "${taskId}", name, command, port, cwd })\`. Always pass \`taskId: "${taskId}"\` — the host uses it to scope the preview to this scratchpad. Call once per process — e.g. one call for frontend, one for backend if both run. Use a \`name\` like \`"frontend"\` or \`"backend"\` for clarity.`,
-    "",
-    "**Hard constraints:**",
-    "- You **must not** write `.posthog.json` directly — the host owns the manifest. If you need to surface preview info, use `posthog_code__registerPreview`.",
-    "- Do not push to a remote, add a remote, or otherwise publish — Publish is a separate user-driven action.",
-    "- Choose a mainstream stack. No esoteric or research-grade frameworks unless the user explicitly asked.",
-    `- All work happens inside \`${scratchpadPath}\`. Do not touch files outside this directory.`,
-  ].join("\n");
+  const instrumentationProjectNote =
+    projectId === null
+      ? "No PostHog project is linked yet — the user will pick or create one at publish time. Read the API key and host from environment variables (`POSTHOG_API_KEY`, `POSTHOG_HOST`) and add a placeholder `.env.example` documenting them. Do NOT hardcode any project IDs or keys."
+      : `Use PostHog project ID \`${projectId}\` for these. Read the API key from environment variables (\`POSTHOG_API_KEY\`, \`POSTHOG_HOST\`) and add a placeholder \`.env.example\`.`;
+
+  return `You are scaffolding a brand-new app called **${productName}** in \`${scratchpadPath}\`. The user has given you the following idea:
+
+---
+${initialIdea}
+---
+
+**Before you start anything else**, send a short message to the user (one or two sentences) telling them what to expect: that you'll ask a few quick clarifying questions, then scaffold a minimal version and **stand up a live preview as fast as possible** so they can see it taking shape — features and styling iterate from there. Then proceed with the workflow below.
+
+Follow this workflow:
+
+1. **Socratic clarification.** Before writing any code, run up to **${rounds}** rounds of Socratic clarification using the \`posthog_code__askClarification\` tool. Each round may include multiple questions; **every question must include a \`prefilledAnswer\`** representing your best guess so the user can accept defaults with one keystroke. Cover at minimum: app type (web/mobile/CLI/etc.), stack choice (your recommendation; the user can override), and any product-specific behaviour you can't safely guess. PostHog instrumentation is implicit — don't ask about it. Skipping clarification entirely is allowed when the request is fully specified, but encouraged for at least one round otherwise.
+
+2. **Scaffold the bare minimum that runs.** Pick a production-grade, simple, mainstream stack appropriate for the product (e.g. \`pnpm create vite\`, \`pnpm create next-app\`, \`cargo new\`, etc.) and get it to a state where \`pnpm dev\` (or equivalent) starts a working dev server — even with placeholder content. Optimize for **speed to first preview**: run the scaffolder, install dependencies, do not yet build out features or polish UI. The directory is already a fresh \`git\` repo on \`main\` with no commits — you can use \`git\` normally, but **do NOT run \`git init\`** in subdirectories or scaffolders that try to (pass \`--no-git\`/equivalent flags). Do not add deployment scripts or hosting configuration.
+
+3. **Start the dev server and register the preview NOW.** As soon as you have anything that boots, kick off the dev server and declare it via \`posthog_code__registerPreview({ taskId: "${taskId}", name, command, port, cwd })\` (always pass \`taskId: "${taskId}"\`; \`name\` should be \`"frontend"\` / \`"backend"\` / etc.). The user sees a live preview tab open the moment the server is up — get them there before you start filling in features. If the product has both a frontend and a backend, register them as you bring each up; you do not have to wait for both.
+
+   **For any product with a UI, design with intentionality.** Before you write a single line of styling beyond the scaffolder defaults, WebFetch Anthropic's \`frontend-design\` skill from \`https://raw.githubusercontent.com/anthropics/claude-code/main/plugins/frontend-design/skills/frontend-design/SKILL.md\` and follow it like a loaded skill — that file IS the skill. If the fetch fails, hold yourself to the same bar inline: pick a distinctive aesthetic direction, distinctive typography (no Inter/Arial/Roboto), dominant color + sharp accents (no cliché purple-on-white gradients), and at least one unforgettable choice.
+
+4. **Build it out.** With the preview running and the user watching, iterate on features and UI. Re-saving files is fine — most dev servers HMR. If you have to restart the server, that's also fine; \`registerPreview\` re-registration just updates the URL. Keep the user informed about what you're doing.
+
+5. **PostHog instrumentation.** Once the app is taking shape, wire up PostHog. Run these slash-prompts in order, recovering inside your own loop if any step fails or installs the SDK out of order:
+   - \`/instrument-integration\`
+   - \`/instrument-product-analytics\`
+   - \`/instrument-error-tracking\`
+   - \`/instrument-llm-analytics\` (only if the product has AI/LLM features)
+
+   ${instrumentationProjectNote}
+
+**Hard constraints:**
+- You **must not** write \`.posthog.json\` directly — the host owns the manifest. If you need to surface preview info, use \`posthog_code__registerPreview\`.
+- Do not push to a remote, add a remote, or otherwise publish — Publish is a separate user-driven action.
+- Choose a mainstream stack. No esoteric or research-grade frameworks unless the user explicitly asked.
+- All work happens inside \`${scratchpadPath}\`. Do not touch files outside this directory.`;
 }