fix(self-driving): Copy fixes, enable error tracking and replay by default, rename "fleet" to "troop"

context/skills/self-driving/config.yaml

@@ -1,6 +1,6 @@
 type: skill
 template: description.md
-description: Set up PostHog Self-driving — enable the right signal sources, connect GitHub, tune the scout fleet, and design custom scouts
+description: Set up PostHog Self-driving — enable the right signal sources, connect GitHub, tune the scout troop, and design custom scouts
 tags: [signals, self-driving]
 references:
   preamble: "**Read ONLY this file.** Do not read any other reference file until this one tells you to."

context/skills/self-driving/description.md

@@ -1,6 +1,6 @@
 # PostHog Self-driving setup
 
-This skill configures PostHog Signals for a project that already has PostHog installed: it switches on the signal sources (the inbox's "Responders") that match what the product actually uses, makes sure the GitHub integration is connected so Signals can research and fix issues in code, tunes the scout fleet, designs custom scouts for the watchable surfaces the canonical fleet doesn't cover (always proposed to the user first). Organization-level AI data processing approval — which everything downstream depends on — is enforced by the wizard itself before this skill runs.
+This skill configures PostHog Signals for a project that already has PostHog installed: it switches on the signal sources (the inbox's "Responders") that match what the product actually uses, makes sure the GitHub integration is connected so Signals can research and fix issues in code, tunes the scout troop, designs custom scouts for the watchable surfaces the canonical troop doesn't cover (always proposed to the user first). Organization-level AI data processing approval — which everything downstream depends on — is enforced by the wizard itself before this skill runs.
 
 The wizard's run prompt supplies the project URLs (integrations settings, organization AI settings, new warehouse source, Signals inbox). Use those exact URLs whenever a step sends the user to the browser.
 
@@ -19,7 +19,7 @@ Each step file points to the next. Run them in order. **Start by reading `refere
 - **Never disable a source the user already enabled.** You only switch things on (and tune scouts off); existing enabled rows are someone's deliberate choice.
 - **Never enable a connected-tool source the user hasn't confirmed they use.** GitHub Issues, Linear, Zendesk, and pganalyze are ask-then-connect, never blind.
 - **Stay off the internal surfaces.** Don't call `signals-scout-emit-signal` or any scratchpad-write tool, and don't change a scout's `emit` flag or `run_interval_minutes` — on configs, this skill only flips `enabled`. **Canonical scout bodies are never edited.** New scout skills are created in exactly one place: step 6b, and only ones the user approved there.
-- **Keep the scout fleet small.** Every enabled scout is a recurring LLM spend. Step 6 enables only `signals-scout-general` plus the **one or two** specialists for the products this project uses most — never error tracking or session replay (those reach the inbox as native sources) — and step 6b adds **at most two** custom scouts. Everything else stays disabled.
+- **Keep the scout troop small.** Every enabled scout is a recurring LLM spend. Step 6 enables only `signals-scout-general` plus the **one or two** specialists for the products this project uses most — never error tracking or session replay (those reach the inbox as native sources) — and step 6b adds **at most two** custom scouts. Everything else stays disabled.
 - **Batch your questions.** `wizard_ask` has a small per-run budget; one multi-select beats four yes/nos. Don't skip a step or drop a connector (e.g. Linear) or custom scouts setup to save calls.
 - **Decline goes first.** Every `wizard_ask` that offers choices must include a plain-language decline option (skip / none / "keep what's there"), and it must be the **first** option so it is the default highlight — an accidental `enter` then declines instead of committing the user to something. The **one exception is step 3's GitHub gate**: the run cannot proceed without GitHub, so there the affirmative ("Done — I've installed it") stays first and the decline ("I can't connect right now", which aborts) stays last.
 

context/skills/self-driving/references/2-read-context.md

@@ -20,7 +20,7 @@ Load via `ToolSearch select:Read,Glob,Grep,mcp__posthog-wizard__signals-scout-pr
 
 ## Do
 
-1. **Read `./posthog-setup-report.md`.** It is ground truth for what the base integration instrumented **in this repo**: events, error tracking, feature flags. Do not re-derive what it already states. It is NOT authority over project-level facts — session replay in particular may be instrumented in another repo or via the snippet, so the report can rule replay in but never out (step 4 probes the server for that).
+1. **Read `./posthog-setup-report.md` if it's there.** It's written only by a recent base-wizard integration run, so it's often absent — a project set up a while ago, manually, or via the snippet won't have one, a run whose report wasn't committed won't either, and a project that never ran the wizard never does. Treat its absence as **no signal** (skip to the profile and probes below), never as "nothing instrumented". When present, it is ground truth for what the base integration instrumented **in this repo**: events, error tracking, feature flags — do not re-derive what it already states. Either way it is NOT authority over project-level facts — session replay in particular may be instrumented in another repo or via the snippet, so the report can rule replay in but never out (step 4 probes the server for that).
 
 2. **Call `signals-scout-project-profile-get`.** It returns products in use, connected integrations, warehouse sources, and the signal source configs split enabled/disabled — one call instead of four. It also carries **relative usage magnitude**: `top_events` (per-event count + distinct users), `recent_activity` (edits per scope), and per-entity active counts (feature flags, experiments, surveys, dashboards). Capture a rough sense of **which products this project uses most** — step 6 enables a scout only for the one or two most-used products, so a usage ranking matters, not just a binary in/out. **Tolerate failure**: it can 404 or error on a team without a profile yet. If it fails, fall back to the step-1 source list and the report; do not retry more than once and do not abort. **Note "profile unavailable" in your checklist** — a profile 404 is expected on a first-run team, so any later decision that relies only on the profile must record "unknown", not a confident negative.
 

context/skills/self-driving/references/3-github.md

@@ -33,7 +33,7 @@ Load via `ToolSearch select:mcp__posthog-wizard__integrations-list,mcp__wizard-t
 ```
 {
   id: "github-connect",
-  prompt: "Self-driving needs GitHub access to investigate findings in your code and open fixes — setup can't finish without it.\n\nOpen this link to install the PostHog GitHub App in one click, then approve access. Grant it the repos you want Self-driving to work with — include this project's repo so step 5 can also watch its issues:\n\n<github authorize URL>\n\nThen come back here.\n\n(Need to re-link an existing installation instead? Use your integrations settings: <integrations settings URL>.)",
+  prompt: "Self-driving needs GitHub access to investigate findings in your code and open fixes — setup can't finish without it.\n\nOpen this link to install the PostHog GitHub App in one click, then approve access. Grant it the repos you want Self-driving to work with — include this project's repo so step 5 can also watch its issues:\n\n<github authorize URL>\n\nThen come back here.",
   kind: "single",
   options: [
     { label: "Done — I've installed it", value: "done" },

context/skills/self-driving/references/4-sources.md

@@ -4,7 +4,7 @@ next_step: 5-connected-tools.md
 
 # Step 4 — Enable native signal sources
 
-Switch on the PostHog-native sources (the inbox's "Responders") that match what this product actually uses, per your step-2 checklist. Conditional means conditional: a source for a surface the product doesn't have just adds noise.
+Switch on the PostHog-native sources (the inbox's "Responders") that match what this product actually uses, per your step-2 checklist. For most sources, conditional means conditional: one for a surface the product doesn't have just adds noise. **Error tracking and session replay are the exception — lean toward enabling them by default** (see the table), even with no current signal: teams adopt them sooner or later and an idle source costs nothing until data arrives.
 
 ## Status
 
@@ -30,9 +30,9 @@ Load via `ToolSearch select:mcp__posthog-wizard__inbox-source-configs-create,mcp
 
 | Source | When | Payload |
 |---|---|---|
-| Scout gate | **Always** — it lets the step-6 fleet's findings reach the inbox | `signals_scout` / `cross_source_issue` |
-| Error tracking | Error tracking is in use anywhere: instrumented in this repo (report), exception autocapture ON (project-state block), or error issues exist (step-2 probe) | **All three rows**: `error_tracking` / `issue_created`, `error_tracking` / `issue_reopened`, `error_tracking` / `issue_spiking` — the product UI treats them as one switch |
-| Session replay | Replay is enabled for the **project**: recording opt-in ON (project-state block) OR recordings exist (step-2 probe) OR the report says this repo instruments it. Opt-in ON with zero recordings still counts (recordings just haven't arrived yet). Skip only when all three say no/unknown, with reason "replay not enabled for this project" | `session_replay` / `session_analysis_cluster` — don't pass a `config`; the server injects the default sample rate. A 400 mentioning AI approval is unexpected (approval is enforced upstream) → skip this source and record a follow-up |
+| Scout gate | **Always** — it lets the step-6 troop's findings reach the inbox | `signals_scout` / `cross_source_issue` |
+| Error tracking | **Enable by default**, even with no current signal — teams adopt error tracking sooner or later, and with no errors there are no findings and no cost. Evidence (report, exception autocapture ON, or error issues from the step-2 probe) only raises confidence; its absence is **not** a reason to skip | **All three rows**: `error_tracking` / `issue_created`, `error_tracking` / `issue_reopened`, `error_tracking` / `issue_spiking` — the product UI treats them as one switch |
+| Session replay | **Enable by default**, same reasoning — arm it now even with no current signal; recordings are only analyzed once they exist, so an idle source costs nothing and teams turn replay on eventually. Evidence (recording opt-in ON, recordings from the step-2 probe, or the report) only raises confidence; its absence is **not** a reason to skip | `session_replay` / `session_analysis_cluster` — don't pass a `config`; the server injects the default sample rate. A 400 mentioning AI approval is unexpected (approval is enforced upstream) → skip this source and record a follow-up |
 | Support | The team uses PostHog support/conversations (per the profile). If the profile was unavailable (step 2), don't record a confident skip — record "unknown — profile unavailable" + a follow-up to enable Support manually if they use it | `conversations` / `ticket` |
 
 ## Skip — do not create

context/skills/self-driving/references/5-connected-tools.md

@@ -27,7 +27,7 @@ Load via `ToolSearch select:mcp__wizard-tools__wizard_ask,mcp__posthog-wizard__e
 ```
 {
   id: "connected-tools",
-  prompt: "Self-driving can also watch your other tools and pull their issues into the inbox. Which of these do you use?",
+  prompt: "Self-driving can also watch your other tools and investigate and fix the problems they surface. Which of these do you use?",
   kind: "multi",
   options: [
     { label: "None of these", value: "none" },

context/skills/self-driving/references/5a-github.md

@@ -16,8 +16,6 @@ Emit:
 
 Load via `ToolSearch select:mcp__posthog-wizard__integrations-github-repos-retrieve,mcp__posthog-wizard__external-data-sources-create`.
 
-If `integrations-github-repos-retrieve` or `external-data-sources-create` isn't available (older server), skip the auto-create and record GitHub Issues as a dormant source (the dormant fallback below). **Not an abort.**
-
 ## Do
 
 1. **Infer the repository.** Run `git remote get-url origin` in the project root and parse `owner/repo` from either form (`git@github.com:owner/repo.git` or `https://github.com/owner/repo[.git]`). No remote, or not a github.com remote → go to the dormant fallback (below).
@@ -69,6 +67,6 @@ If `integrations-github-repos-retrieve` or `external-data-sources-create` isn't
    - 400 mentioning credentials or repository access → dormant fallback (below).
    - Success returns the source `id` — record "connected by this setup (source id …, first sync started)".
 
-5. **Dormant fallback** (no remote / repo not visible / create failed / tools unavailable): don't redirect the user and don't re-prompt — record **"picked but not connected"** and return to step 5, where the dormant responder is enabled and the follow-up recorded (same harmless posture as Zendesk — it only emits once a warehouse source syncs). When the cause was the repo not being visible to the App, the follow-up also tells the user to grant this repo to the PostHog GitHub App. A failed connector never dead-ends the run.
+5. **Dormant fallback** (no remote / repo not visible / create failed): don't redirect the user and don't re-prompt — record **"picked but not connected"** and return to step 5, where the dormant responder is enabled and the follow-up recorded (same harmless posture as Zendesk — it only emits once a warehouse source syncs). When the cause was the repo not being visible to the App, the follow-up also tells the user to grant this repo to the PostHog GitHub App. A failed connector never dead-ends the run.
 
 Return to step 5 (responder enabling and class recording happen there).

context/skills/self-driving/references/5b-linear.md

@@ -14,8 +14,6 @@ Emit:
 
 Load via `ToolSearch select:mcp__posthog-wizard__external-data-sources-create` (`integrations-list` from step 3 stays loaded).
 
-If `external-data-sources-create` isn't available (older server), skip this file and treat Linear as picked-but-not-connected — arm the dormant responder and add a follow-up (step 5's picked-but-not-connected path) — instead. **Not an abort.**
-
 ## Do
 
 1. **Check for an existing Linear integration**: call `integrations-list` and look for `kind: "linear"`. Present → skip ahead to create the source (below).