> AI agents: this is one page from PostHog's docs. Full index of Markdown docs for LLMs: https://posthog.com/llms.txt # Remove the feature flags you already rolled out – Self-driving pocket guide Canonical URL: https://posthog.com/docs/self-driving/pocket-guide/flag-debt > **Cloud region:** This page uses US Cloud hosts. For an EU Cloud project, use `https://eu.posthog.com` instead of `https://app.posthog.com` (app host for links). ## On this page - [What the scout looks at](#what-the-scout-looks-at) - [The report in your inbox](#the-report-in-your-inbox) - [The pull request you merge](#the-pull-request-you-merge) - [The scout itself](#the-scout-itself) - [The schedule it runs on](#the-schedule-it-runs-on) - [Add this to your scout troop](#add-this-to-your-scout-troop) Chapter 03 # Remove the feature flags you already rolled out – Self-driving pocket guide Every fully rolled out flag is a decision you've already made. Once the flag is fully rolled out, the flag chooses the same code branch every time, and the losing branch becomes dead code. If you don't clean it up, every evaluation is still billed, and the dead code clutters your codebase. This scout finds the flags you forgot to remove and opens the pull request that takes them out. ## What the scout looks at A rollout hit 100% four months ago, and the evaluations never stopped. A decision you already made and moved on with is still being asked ~52,000 times a day. Which is it? - If the rollout is still moving, that's a live experiment, not debt. The scout stays *quiet*. - If the rollout finished and the evaluations kept going, it signals flag debt. The scout ***reports***. That second pattern is what the scout looks for – Fig. 1 shows every flag it caught. | Flag | Rollout | Age | Evals/day | In code | Verdict | | --- | --- | --- | --- | --- | --- | | new-checkout-flow | 100% | 4 mo | ~29,000 | 3 files | Remove | | beta-nav | 0% | 5 mo | ~12,000 | 1 file | Remove | | legacy-export | 100% | 7 mo | ~11,000 | not found | Ask first | Fig. 1 – What the scout saw: every flag still evaluating, and how long each decision has been finished. ## The report in your inbox When your product emits [signals](https://posthog.com/docs/self-driving/signals.md) that indicate flags have gone stale, a [scout](https://posthog.com/docs/self-driving/scouts.md) opens a [report](https://posthog.com/docs/self-driving/reports.md) – and Fig. 2 breaks the card down part by part. Click Review and the report opens into Fig. 3: the full evidence, the raw signals, and the button that turns it into a pull request. P313 flags at a terminal rollout for 4+ months, still evaluated 2new-checkout-flow and beta-nav finished months ago and are still evaluated – legacy-export is left as an open question3Scout · flag debt4ReadyActionable51d ago ArchiveReview6 Fig. 2 – Once surfaced, your inbox surfaces this report card. The card includes its claim and triage, with the evidence sitting inside the report itself.Hover over the figure to learn about each element. P33 flags at a terminal rollout for 4+ months, still evaluated 1ReadyActionableScout · flag debt· 1d ago ArchiveCreate PR2 Summary3 Safe to clean up. `new-checkout-flow` has been at 100% for four months with no edits, and its key still appears in three files – all of them taking the same branch every time. `beta-nav` has been at 0% for five months, with its key in one file behind a conditional that never fires. Neither is experiment-linked, and no other flag depends on them. Open question. `legacy-export` is at 100% and still evaluated ~11,000 times a day, but its key doesn't appear in any connected repo. 94% of those evaluations come from `posthog-android` versions older than the cleanup release, so this looks like shipped clients rather than live code – deleting it would flip them to the off path. Worth confirming before anything is removed. 3 flags · ~52,000 evaluations/day **Suggested fix:** Remove the call sites for `new-checkout-flow` and `beta-nav`. Once that's deployed and evaluations stop, you can delete the flags themselves – that's the follow-up, not this diff. 4 Evidence2 sources5 Your feature flagsWhich flags still evaluate, how often, at what rollout, and how long they've sat there. Your codebaseYour repo is a signal source too. Whether the flag key still appears in code decides between cleanup and a question. Fig. 3 – The report opened. From here, you can review the evidence and open a pull request.Hover over the figure to learn about each element. ## The pull request you merge When you're ready to open a pull request, PostHog dispatches an agent to do it for you with the report and evidence attached as context. You review and merge it like any other PR – nothing merges without you. Reports are free. Pull requests are **$15 each**, with your first three a month **free**. See self-driving [Pricing](https://posthog.com/docs/self-driving/pricing.md). ## The scout itself Scouts are the heart of the self-driving system – they're instructions an agent follows on a schedule – Fig. 4 is the actual skill file for this guide's custom scout. signals-scout-flag-debt/SKILL.md ```markdown --- name: signals-scout-flag-debt description: > Finds feature flags whose decision is over but which are still evaluated in production – terminal rollouts left in place, or keys that no longer appear in any connected repo. allowed_tools: - emit_report - edit_report --- # Feature flag debt Find flags whose decision is over while something is still evaluating them. Narrower than `signals-scout-feature-flags`, which watches the whole flag surface – evaluation cliffs, ghost keys, response-distribution shifts, flag debt – from PostHog data alone. This one adds the half that scout cannot see: your repository. Run it if your flags routinely outlive your cleanup PRs. If you want the analysis on demand rather than on a schedule, the `cleaning-up-stale-feature-flags` and `finding-deleted-feature-flags` skills already do it, and `auditing-experiments-flags` covers experiment-linked flags. Weekly rather than the daily fleet default: flag debt accumulates over months, so a daily run would re-read the same roster and write nothing six days out of seven. **Term collision, worth knowing.** The canonical scout uses **ghost flag** for the opposite case – code calling a key with no flag behind it, where the SDK silently returns `false`. That is a different finding with a different fix. Don't reuse the term here. ## Discriminator Emit a report when a flag is still emitting `$feature_flag_called` evaluations **and** either - **(a)** it has been at 100% or 0% with no edits for 60+ days, or - **(b)** its key does not appear in any connected repository. Write nothing for a flag whose rollout percentage changed recently, or that was edited in the last 30 days – that flag is mid-rollout and doing its job. The two cases are not the same finding. **(a)** is cleanup you can do: the code is there and it takes the same branch every time. **(b)** is a question – something is calling that key and it isn't in the code you can see. Never treat (b) as a delete candidate on its own. ### Coverage caveat `$feature_flag_called` fires on explicit evaluation calls. Server SDKs using local evaluation, bootstrapped flags, and clients with flag-event capture disabled may not emit it at all, so **absence of the event is weak evidence that a flag is unused**. Lean on PostHog's server-side `STALE` status, which accounts for `last_called_at`, rather than on raw event absence. ## Explore 1. List flags with recent evaluations, plus their rollout percentage, tags, and last-modified date. 2. Search every connected repository for each candidate key. Three outcomes, not two: - **A string literal, or a constant that resolves to one** – a definite answer either way. - **Dynamically constructed** – a key assembled at the call site from a variable. A repo search can't resolve these, and they are the main source of false "the key is gone" conclusions. Treat a nearby prefix or template match as uncertainty, never as a delete recommendation. - **Not found anywhere** – case (b). Go to step 3 before concluding anything. 3. For a case (b) flag, work out what is still calling it. The plausible answers are all things this scout can't see: a repo that isn't connected, shipped mobile clients still running old code, or a third-party or SDK consumer. Name the possibilities in the report, and check the `$lib` and `$lib_version` spread on the evaluations – old client versions point at shipped code you can't deploy over. 4. Before recommending any removal, confirm the flag isn't load-bearing: - **Attached to an experiment**, with a non-empty `experiment_set` – leave it alone entirely; deleting it breaks the experiment and its results. - **Referenced by another flag's release conditions** – flag dependencies exist, and deleting the parent changes what the dependent serves. - **Consumed for its payload** – a flag can sit at 100% and be read only for its payload value, so the key shows up in a config fetch rather than in a branch. - **Tagged as excluded** – see the disqualifiers. 5. Quantify the reach: evaluations per day and distinct persons. That is what makes the report worth someone's afternoon. It is **not** a billing argument – `$feature_flag_called` is excluded from billable event volume – so don't put a dollar figure on it. The cost here is a code path nobody can reason about, not an invoice. 6. Bundle the findings into one report rather than filing one per flag, and keep the two cases visibly separate inside it. ## Suggested action Deleting a flag is not a no-op. Once the flag is gone, evaluation returns `false` or `undefined` – not the last value it served. Any live client still evaluating a deleted 100% flag flips to the off path, which is a production behavior change. So the order matters, and it isn't one pull request: 1. Remove the call sites, and deploy. 2. Confirm evaluations stop. 3. Then delete the flag. Recommend step 1 – that's the PR an agent can open. Steps 2 and 3 are the follow-up you name in the report, not something to bundle into the same diff. ## Disqualifiers - The key appears in the repo, even only in tests or config. - The key may be dynamically constructed and the search can't rule it out. - The flag was edited recently, or its percentage is between 1 and 99. - The flag is experiment-linked, has dependent flags, or is read for its payload. - The flag carries an exclusion tag. Kill switches and ops toggles look exactly like debt and must never be recommended for removal – but most of them carry no description, so don't try to infer intent from prose. Ask the team to tag them (`keep`, `ops`, `kill-switch`) and read the tag. Record anything you're told to leave alone in your scratchpad so the exclusion survives to the next run. The durable way to stop a scout re-flagging something is to give it somewhere to remember, not to hope for good metadata. - Coverage is partial. If any repo that evaluates flags isn't connected, case (b) findings are unsafe – report them as open questions only. ``` Show full example Fig. 4 – The scout itself – the file an agent follows on a schedule. It reads more than one [signal source](https://posthog.com/docs/self-driving/inbox/sources.md), so the report will name a likely cause, not just a number that moved. This scout's signal sources come from the following product data: - [Your feature flags](https://posthog.com/docs/feature-flags.md) Which flags still evaluate, how often, at what rollout, and how long they've sat there. - [Your codebase](https://posthog.com/docs/self-driving/context.md) Your repo is a signal source too. Whether the flag key still appears in code decides between cleanup and a question. ## The schedule it runs on This custom scout runs **daily** by default. You can choose to run it every 30 minutes up to once a day. It only writes when something is wrong, so most days it's silent. ## Add this to your scout troop You'll need these to run this scout. - Required[Feature flags](https://posthog.com/docs/feature-flags/installation.md) in use - RequiredYour codebase connected via GitHub – every repo that evaluates flags, not just the main one. A repo the scout can't see looks exactly like code that no longer exists. [Add this scout](https://app.posthog.com/inbox/config#createScout=eyJuYW1lIjoic2lnbmFscy1zY291dC1mbGFnLWRlYnQiLCJkZXNjcmlwdGlvbiI6IkZpbmRzIGZlYXR1cmUgZmxhZ3Mgd2hvc2UgZGVjaXNpb24gaXMgb3ZlciBidXQgd2hpY2ggYXJlIHN0aWxsIGV2YWx1YXRlZCBpbiBwcm9kdWN0aW9uIOKAkyB0ZXJtaW5hbCByb2xsb3V0cyBsZWZ0IGluIHBsYWNlLCBvciBrZXlzIHRoYXQgbm8gbG9uZ2VyIGFwcGVhciBpbiBhbnkgY29ubmVjdGVkIHJlcG8uXG4iLCJib2R5IjoiIyBGZWF0dXJlIGZsYWcgZGVidFxuXG5GaW5kIGZsYWdzIHdob3NlIGRlY2lzaW9uIGlzIG92ZXIgd2hpbGUgc29tZXRoaW5nIGlzIHN0aWxsIGV2YWx1YXRpbmcgdGhlbS5cblxuTmFycm93ZXIgdGhhbiBgc2lnbmFscy1zY291dC1mZWF0dXJlLWZsYWdzYCwgd2hpY2ggd2F0Y2hlcyB0aGUgd2hvbGUgZmxhZyBzdXJmYWNlIOKAkyBldmFsdWF0aW9uXG5jbGlmZnMsIGdob3N0IGtleXMsIHJlc3BvbnNlLWRpc3RyaWJ1dGlvbiBzaGlmdHMsIGZsYWcgZGVidCDigJMgZnJvbSBQb3N0SG9nIGRhdGEgYWxvbmUuIFRoaXMgb25lXG5hZGRzIHRoZSBoYWxmIHRoYXQgc2NvdXQgY2Fubm90IHNlZTogeW91ciByZXBvc2l0b3J5LiBSdW4gaXQgaWYgeW91ciBmbGFncyByb3V0aW5lbHkgb3V0bGl2ZVxueW91ciBjbGVhbnVwIFBScy4gSWYgeW91IHdhbnQgdGhlIGFuYWx5c2lzIG9uIGRlbWFuZCByYXRoZXIgdGhhbiBvbiBhIHNjaGVkdWxlLCB0aGVcbmBjbGVhbmluZy11cC1zdGFsZS1mZWF0dXJlLWZsYWdzYCBhbmQgYGZpbmRpbmctZGVsZXRlZC1mZWF0dXJlLWZsYWdzYCBza2lsbHMgYWxyZWFkeSBkbyBpdCwgYW5kXG5gYXVkaXRpbmctZXhwZXJpbWVudHMtZmxhZ3NgIGNvdmVycyBleHBlcmltZW50LWxpbmtlZCBmbGFncy5cblxuV2Vla2x5IHJhdGhlciB0aGFuIHRoZSBkYWlseSBmbGVldCBkZWZhdWx0OiBmbGFnIGRlYnQgYWNjdW11bGF0ZXMgb3ZlciBtb250aHMsIHNvIGEgZGFpbHkgcnVuXG53b3VsZCByZS1yZWFkIHRoZSBzYW1lIHJvc3RlciBhbmQgd3JpdGUgbm90aGluZyBzaXggZGF5cyBvdXQgb2Ygc2V2ZW4uXG5cbioqVGVybSBjb2xsaXNpb24sIHdvcnRoIGtub3dpbmcuKiogVGhlIGNhbm9uaWNhbCBzY291dCB1c2VzICoqZ2hvc3QgZmxhZyoqIGZvciB0aGUgb3Bwb3NpdGUgY2FzZVxu4oCTIGNvZGUgY2FsbGluZyBhIGtleSB3aXRoIG5vIGZsYWcgYmVoaW5kIGl0LCB3aGVyZSB0aGUgU0RLIHNpbGVudGx5IHJldHVybnMgYGZhbHNlYC4gVGhhdCBpcyBhXG5kaWZmZXJlbnQgZmluZGluZyB3aXRoIGEgZGlmZmVyZW50IGZpeC4gRG9uJ3QgcmV1c2UgdGhlIHRlcm0gaGVyZS5cblxuIyMgRGlzY3JpbWluYXRvclxuXG5FbWl0IGEgcmVwb3J0IHdoZW4gYSBmbGFnIGlzIHN0aWxsIGVtaXR0aW5nIGAkZmVhdHVyZV9mbGFnX2NhbGxlZGAgZXZhbHVhdGlvbnMgKiphbmQqKiBlaXRoZXJcblxuLSAqKihhKSoqIGl0IGhhcyBiZWVuIGF0IDEwMCUgb3IgMCUgd2l0aCBubyBlZGl0cyBmb3IgNjArIGRheXMsIG9yXG4tICoqKGIpKiogaXRzIGtleSBkb2VzIG5vdCBhcHBlYXIgaW4gYW55IGNvbm5lY3RlZCByZXBvc2l0b3J5LlxuXG5Xcml0ZSBub3RoaW5nIGZvciBhIGZsYWcgd2hvc2Ugcm9sbG91dCBwZXJjZW50YWdlIGNoYW5nZWQgcmVjZW50bHksIG9yIHRoYXQgd2FzIGVkaXRlZCBpbiB0aGVcbmxhc3QgMzAgZGF5cyDigJMgdGhhdCBmbGFnIGlzIG1pZC1yb2xsb3V0IGFuZCBkb2luZyBpdHMgam9iLlxuXG5UaGUgdHdvIGNhc2VzIGFyZSBub3QgdGhlIHNhbWUgZmluZGluZy4gKiooYSkqKiBpcyBjbGVhbnVwIHlvdSBjYW4gZG86IHRoZSBjb2RlIGlzIHRoZXJlIGFuZCBpdFxudGFrZXMgdGhlIHNhbWUgYnJhbmNoIGV2ZXJ5IHRpbWUuICoqKGIpKiogaXMgYSBxdWVzdGlvbiDigJMgc29tZXRoaW5nIGlzIGNhbGxpbmcgdGhhdCBrZXkgYW5kIGl0XG5pc24ndCBpbiB0aGUgY29kZSB5b3UgY2FuIHNlZS4gTmV2ZXIgdHJlYXQgKGIpIGFzIGEgZGVsZXRlIGNhbmRpZGF0ZSBvbiBpdHMgb3duLlxuXG4jIyMgQ292ZXJhZ2UgY2F2ZWF0XG5cbmAkZmVhdHVyZV9mbGFnX2NhbGxlZGAgZmlyZXMgb24gZXhwbGljaXQgZXZhbHVhdGlvbiBjYWxscy4gU2VydmVyIFNES3MgdXNpbmcgbG9jYWwgZXZhbHVhdGlvbixcbmJvb3RzdHJhcHBlZCBmbGFncywgYW5kIGNsaWVudHMgd2l0aCBmbGFnLWV2ZW50IGNhcHR1cmUgZGlzYWJsZWQgbWF5IG5vdCBlbWl0IGl0IGF0IGFsbCwgc29cbioqYWJzZW5jZSBvZiB0aGUgZXZlbnQgaXMgd2VhayBldmlkZW5jZSB0aGF0IGEgZmxhZyBpcyB1bnVzZWQqKi4gTGVhbiBvbiBQb3N0SG9nJ3Mgc2VydmVyLXNpZGVcbmBTVEFMRWAgc3RhdHVzLCB3aGljaCBhY2NvdW50cyBmb3IgYGxhc3RfY2FsbGVkX2F0YCwgcmF0aGVyIHRoYW4gb24gcmF3IGV2ZW50IGFic2VuY2UuXG5cbiMjIEV4cGxvcmVcblxuMS4gTGlzdCBmbGFncyB3aXRoIHJlY2VudCBldmFsdWF0aW9ucywgcGx1cyB0aGVpciByb2xsb3V0IHBlcmNlbnRhZ2UsIHRhZ3MsIGFuZCBsYXN0LW1vZGlmaWVkXG4gICBkYXRlLlxuMi4gU2VhcmNoIGV2ZXJ5IGNvbm5lY3RlZCByZXBvc2l0b3J5IGZvciBlYWNoIGNhbmRpZGF0ZSBrZXkuIFRocmVlIG91dGNvbWVzLCBub3QgdHdvOlxuICAgLSAqKkEgc3RyaW5nIGxpdGVyYWwsIG9yIGEgY29uc3RhbnQgdGhhdCByZXNvbHZlcyB0byBvbmUqKiDigJMgYSBkZWZpbml0ZSBhbnN3ZXIgZWl0aGVyIHdheS5cbiAgIC0gKipEeW5hbWljYWxseSBjb25zdHJ1Y3RlZCoqIOKAkyBhIGtleSBhc3NlbWJsZWQgYXQgdGhlIGNhbGwgc2l0ZSBmcm9tIGEgdmFyaWFibGUuIEEgcmVwb1xuICAgICBzZWFyY2ggY2FuJ3QgcmVzb2x2ZSB0aGVzZSwgYW5kIHRoZXkgYXJlIHRoZSBtYWluIHNvdXJjZSBvZiBmYWxzZSBcInRoZSBrZXkgaXMgZ29uZVwiXG4gICAgIGNvbmNsdXNpb25zLiBUcmVhdCBhIG5lYXJieSBwcmVmaXggb3IgdGVtcGxhdGUgbWF0Y2ggYXMgdW5jZXJ0YWludHksIG5ldmVyIGFzIGEgZGVsZXRlXG4gICAgIHJlY29tbWVuZGF0aW9uLlxuICAgLSAqKk5vdCBmb3VuZCBhbnl3aGVyZSoqIOKAkyBjYXNlIChiKS4gR28gdG8gc3RlcCAzIGJlZm9yZSBjb25jbHVkaW5nIGFueXRoaW5nLlxuMy4gRm9yIGEgY2FzZSAoYikgZmxhZywgd29yayBvdXQgd2hhdCBpcyBzdGlsbCBjYWxsaW5nIGl0LiBUaGUgcGxhdXNpYmxlIGFuc3dlcnMgYXJlIGFsbCB0aGluZ3NcbiAgIHRoaXMgc2NvdXQgY2FuJ3Qgc2VlOiBhIHJlcG8gdGhhdCBpc24ndCBjb25uZWN0ZWQsIHNoaXBwZWQgbW9iaWxlIGNsaWVudHMgc3RpbGwgcnVubmluZyBvbGRcbiAgIGNvZGUsIG9yIGEgdGhpcmQtcGFydHkgb3IgU0RLIGNvbnN1bWVyLiBOYW1lIHRoZSBwb3NzaWJpbGl0aWVzIGluIHRoZSByZXBvcnQsIGFuZCBjaGVjayB0aGVcbiAgIGAkbGliYCBhbmQgYCRsaWJfdmVyc2lvbmAgc3ByZWFkIG9uIHRoZSBldmFsdWF0aW9ucyDigJMgb2xkIGNsaWVudCB2ZXJzaW9ucyBwb2ludCBhdCBzaGlwcGVkXG4gICBjb2RlIHlvdSBjYW4ndCBkZXBsb3kgb3Zlci5cbjQuIEJlZm9yZSByZWNvbW1lbmRpbmcgYW55IHJlbW92YWwsIGNvbmZpcm0gdGhlIGZsYWcgaXNuJ3QgbG9hZC1iZWFyaW5nOlxuICAgLSAqKkF0dGFjaGVkIHRvIGFuIGV4cGVyaW1lbnQqKiwgd2l0aCBhIG5vbi1lbXB0eSBgZXhwZXJpbWVudF9zZXRgIOKAkyBsZWF2ZSBpdCBhbG9uZSBlbnRpcmVseTtcbiAgICAgZGVsZXRpbmcgaXQgYnJlYWtzIHRoZSBleHBlcmltZW50IGFuZCBpdHMgcmVzdWx0cy5cbiAgIC0gKipSZWZlcmVuY2VkIGJ5IGFub3RoZXIgZmxhZydzIHJlbGVhc2UgY29uZGl0aW9ucyoqIOKAkyBmbGFnIGRlcGVuZGVuY2llcyBleGlzdCwgYW5kIGRlbGV0aW5nXG4gICAgIHRoZSBwYXJlbnQgY2hhbmdlcyB3aGF0IHRoZSBkZXBlbmRlbnQgc2VydmVzLlxuICAgLSAqKkNvbnN1bWVkIGZvciBpdHMgcGF5bG9hZCoqIOKAkyBhIGZsYWcgY2FuIHNpdCBhdCAxMDAlIGFuZCBiZSByZWFkIG9ubHkgZm9yIGl0cyBwYXlsb2FkXG4gICAgIHZhbHVlLCBzbyB0aGUga2V5IHNob3dzIHVwIGluIGEgY29uZmlnIGZldGNoIHJhdGhlciB0aGFuIGluIGEgYnJhbmNoLlxuICAgLSAqKlRhZ2dlZCBhcyBleGNsdWRlZCoqIOKAkyBzZWUgdGhlIGRpc3F1YWxpZmllcnMuXG41LiBRdWFudGlmeSB0aGUgcmVhY2g6IGV2YWx1YXRpb25zIHBlciBkYXkgYW5kIGRpc3RpbmN0IHBlcnNvbnMuIFRoYXQgaXMgd2hhdCBtYWtlcyB0aGUgcmVwb3J0XG4gICB3b3J0aCBzb21lb25lJ3MgYWZ0ZXJub29uLiBJdCBpcyAqKm5vdCoqIGEgYmlsbGluZyBhcmd1bWVudCDigJMgYCRmZWF0dXJlX2ZsYWdfY2FsbGVkYCBpc1xuICAgZXhjbHVkZWQgZnJvbSBiaWxsYWJsZSBldmVudCB2b2x1bWUg4oCTIHNvIGRvbid0IHB1dCBhIGRvbGxhciBmaWd1cmUgb24gaXQuIFRoZSBjb3N0IGhlcmUgaXMgYVxuICAgY29kZSBwYXRoIG5vYm9keSBjYW4gcmVhc29uIGFib3V0LCBub3QgYW4gaW52b2ljZS5cbjYuIEJ1bmRsZSB0aGUgZmluZGluZ3MgaW50byBvbmUgcmVwb3J0IHJhdGhlciB0aGFuIGZpbGluZyBvbmUgcGVyIGZsYWcsIGFuZCBrZWVwIHRoZSB0d28gY2FzZXNcbiAgIHZpc2libHkgc2VwYXJhdGUgaW5zaWRlIGl0LlxuXG4jIyBTdWdnZXN0ZWQgYWN0aW9uXG5cbkRlbGV0aW5nIGEgZmxhZyBpcyBub3QgYSBuby1vcC4gT25jZSB0aGUgZmxhZyBpcyBnb25lLCBldmFsdWF0aW9uIHJldHVybnMgYGZhbHNlYCBvciBgdW5kZWZpbmVkYFxu4oCTIG5vdCB0aGUgbGFzdCB2YWx1ZSBpdCBzZXJ2ZWQuIEFueSBsaXZlIGNsaWVudCBzdGlsbCBldmFsdWF0aW5nIGEgZGVsZXRlZCAxMDAlIGZsYWcgZmxpcHMgdG9cbnRoZSBvZmYgcGF0aCwgd2hpY2ggaXMgYSBwcm9kdWN0aW9uIGJlaGF2aW9yIGNoYW5nZS5cblxuU28gdGhlIG9yZGVyIG1hdHRlcnMsIGFuZCBpdCBpc24ndCBvbmUgcHVsbCByZXF1ZXN0OlxuXG4xLiBSZW1vdmUgdGhlIGNhbGwgc2l0ZXMsIGFuZCBkZXBsb3kuXG4yLiBDb25maXJtIGV2YWx1YXRpb25zIHN0b3AuXG4zLiBUaGVuIGRlbGV0ZSB0aGUgZmxhZy5cblxuUmVjb21tZW5kIHN0ZXAgMSDigJMgdGhhdCdzIHRoZSBQUiBhbiBhZ2VudCBjYW4gb3Blbi4gU3RlcHMgMiBhbmQgMyBhcmUgdGhlIGZvbGxvdy11cCB5b3UgbmFtZSBpblxudGhlIHJlcG9ydCwgbm90IHNvbWV0aGluZyB0byBidW5kbGUgaW50byB0aGUgc2FtZSBkaWZmLlxuXG4jIyBEaXNxdWFsaWZpZXJzXG5cbi0gVGhlIGtleSBhcHBlYXJzIGluIHRoZSByZXBvLCBldmVuIG9ubHkgaW4gdGVzdHMgb3IgY29uZmlnLlxuLSBUaGUga2V5IG1heSBiZSBkeW5hbWljYWxseSBjb25zdHJ1Y3RlZCBhbmQgdGhlIHNlYXJjaCBjYW4ndCBydWxlIGl0IG91dC5cbi0gVGhlIGZsYWcgd2FzIGVkaXRlZCByZWNlbnRseSwgb3IgaXRzIHBlcmNlbnRhZ2UgaXMgYmV0d2VlbiAxIGFuZCA5OS5cbi0gVGhlIGZsYWcgaXMgZXhwZXJpbWVudC1saW5rZWQsIGhhcyBkZXBlbmRlbnQgZmxhZ3MsIG9yIGlzIHJlYWQgZm9yIGl0cyBwYXlsb2FkLlxuLSBUaGUgZmxhZyBjYXJyaWVzIGFuIGV4Y2x1c2lvbiB0YWcuIEtpbGwgc3dpdGNoZXMgYW5kIG9wcyB0b2dnbGVzIGxvb2sgZXhhY3RseSBsaWtlIGRlYnQgYW5kXG4gIG11c3QgbmV2ZXIgYmUgcmVjb21tZW5kZWQgZm9yIHJlbW92YWwg4oCTIGJ1dCBtb3N0IG9mIHRoZW0gY2Fycnkgbm8gZGVzY3JpcHRpb24sIHNvIGRvbid0IHRyeSB0b1xuICBpbmZlciBpbnRlbnQgZnJvbSBwcm9zZS4gQXNrIHRoZSB0ZWFtIHRvIHRhZyB0aGVtIChga2VlcGAsIGBvcHNgLCBga2lsbC1zd2l0Y2hgKSBhbmQgcmVhZCB0aGVcbiAgdGFnLiBSZWNvcmQgYW55dGhpbmcgeW91J3JlIHRvbGQgdG8gbGVhdmUgYWxvbmUgaW4geW91ciBzY3JhdGNocGFkIHNvIHRoZSBleGNsdXNpb24gc3Vydml2ZXNcbiAgdG8gdGhlIG5leHQgcnVuLiBUaGUgZHVyYWJsZSB3YXkgdG8gc3RvcCBhIHNjb3V0IHJlLWZsYWdnaW5nIHNvbWV0aGluZyBpcyB0byBnaXZlIGl0IHNvbWV3aGVyZVxuICB0byByZW1lbWJlciwgbm90IHRvIGhvcGUgZm9yIGdvb2QgbWV0YWRhdGEuXG4tIENvdmVyYWdlIGlzIHBhcnRpYWwuIElmIGFueSByZXBvIHRoYXQgZXZhbHVhdGVzIGZsYWdzIGlzbid0IGNvbm5lY3RlZCwgY2FzZSAoYikgZmluZGluZ3MgYXJlXG4gIHVuc2FmZSDigJMgcmVwb3J0IHRoZW0gYXMgb3BlbiBxdWVzdGlvbnMgb25seS4iLCJzb3VyY2UiOiJwb2NrZXRfZ3VpZGUifQ)Opens PostHog with it prefilled. Review it, then hit Create. Not set up yet? One command installs PostHog, connects GitHub, and turns on a default troop of scouts. That troop doesn't include this one – add it above once you're set up. ``` npx @posthog/wizard self-driving ```