Skip to content

feat(feature-flags): add wizard feature-flags install skill - #378

Draft
fristovic wants to merge 4 commits into
PostHog:mainfrom
fristovic:feat/feature-flags-program
Draft

feat(feature-flags): add wizard feature-flags install skill#378
fristovic wants to merge 4 commits into
PostHog:mainfrom
fristovic:feat/feature-flags-program

Conversation

@fristovic

@fristovic fristovic commented Sep 1, 2026

Copy link
Copy Markdown

There's already wizard audit feature-flags (read-only) and a docs-only feature-flags group. Neither of those actually wires flags into an app.

This adds feature-flags-setup for wizard feature-flags. Next.js App Router only: evaluate on the server with evaluateFlags(), bootstrap into the client, create one boolean flag, and gate one UI path after the user confirms. Other stacks abort instead of growing a second pattern.

@fristovic
fristovic requested a review from a team as a code owner September 1, 2026 19:14
@fristovic
fristovic marked this pull request as draft September 1, 2026 20:36

`advanced_disable_feature_flags: true` in test/CI stops forgotten CI jobs from polling `/flags` (see `cutting-costs.md`). A missing token in production is a no-op (render `children`); in development throw the missing-config error named in the framework guidelines.

**If `instrumentation-client.ts` (or `.js`) already inits `posthog-js`:** move that init into this provider so bootstrap can be passed per request. Keep the existing `api_host` / `defaults` / other options. Do not leave both inits in place. Do not follow any framework note that says to keep init in `instrumentation-client.ts` — that path cannot take per-request bootstrap.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this might work better as a commandment (check and see if it already is, it might be) and see what this might contradict with in commandments in general

@gewenyu99 gewenyu99 left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey, this is a great start. I have some suggestions:

  • I'm not sure if I understand who would want/need this Wizard
  • Try setting up feature flags yourself, think about the pain points/difficult bits that someone is likely to fumble on, see if this resolves those issues.
  • I would think about this program's relationship to the main PostHog integration program and shared skill reuse. I think this contains a less reliable but duplicate version of many of they paths.


Record: package manager, whether `src/` is used, and whether PostHog is already initialized (`posthog.init`, `PostHogProvider`, `instrumentation-client`, `posthog-js` / `posthog-node` in dependencies). If flags are already wired the way this skill describes (`evaluateFlags` + bootstrap + a gated call site), verify they are correct and skip to STEP 10.

### STEP 2: Credentials

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If we're installing the package, we can init this for them. There's examples you can copy from, the OAuth session will let you grab the token on the wizard side to add them. I think it'd be pretty odd to have an environment variable -> have no integration.

```ts
import { PostHog } from 'posthog-node'

export function PostHogServer(token: string) {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm gonna throw you one more wrench, you'll need to figure out a reasonable lower bound for the patterns you apply here. The way Next versions work across the board differs, and changes how PostHog need to be initialized. There are examples here in the repo


Flags change production UI. Ask **once**, then create a flag and gate only if they picked a target.

1. Scan pages and components for additive surfaces (a banner, an extra card, an empty-state illustration). Prefer a new element over wrapping existing critical logic.

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🤔 Do you think someone is more likely to come to this program with a thing they have in mind and wanna gate, or do you think they'd be looking for suggestions on what to gate?

const token = process.env.NEXT_PUBLIC_POSTHOG_PROJECT_TOKEN
const cookieStore = await cookies()
const distinctId =
cookieStore.get('ph_distinct_id')?.value ?? crypto.randomUUID()

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PostHog always generates a distinct_id on the frontend. You can call posthog.get_distinct_id(). If they're not identified, they'd have an anonymous distinct Id that's merged with the user on identify.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants