feat(feature-flags): add an end-to-end setup workflow

[hacktivist123]

Turn the existing feature-flags skills into an ordered workflow that can assess an app, configure a safe flag, implement one use case, verify the result, and leave an evidence-based report.

What

• Add a five-step workflow shared by the feature-flags skill variants.
• Add framework-specific browser and server rule tags for JavaScript variants.
• Update Next.js server evaluation guidance to use the current evaluateFlags() API.
• Separate public project tokens from personal API keys, OAuth tokens, and other secrets.
• Add conservative flag creation, rollout, verification, and reporting rules.
• Add a generation contract test for the Next.js skill.

Why

The previous skill provided documentation and general principles, but it did not define an executable workflow or completion criteria.

Testing the generated Next.js skill with a real Wizard agent exposed gaps around environment-file detection, production-build verification, report ownership, safe rollout behavior, and credential terminology. These instructions turn those findings into reusable context rather than fixture-specific fixes.

Verification

• npm test - 19 test files and 139 tests passed
• npm run build - all 363 skills generated
• Environment-variable naming check passed
• Generated Next.js skill inspected
• Bundle and individual skill archives remain within CI size limits
• End-to-end Wizard agent test completed against a Next.js App Router fixture and a live PostHog project
  • Production build and PostHog flag read-back passed
  • An existing inactive flag was reused without changing its rollout conditions
  • Environment configuration was checked by key presence without reading values

Runtime coverage

The agent test covered the Next.js variant. Other feature-flags variants generated successfully but were not exercised through full runtime integrations.

Live evaluation and custom event ingestion were not run because the shared rollout was not changed solely for testing. The workflow requires these layers to remain visibly classified as not run rather than treating source review or local state as ingestion evidence.

[gewenyu99]

General feedback here for you is, what do you think the ideal use case is for this skill and wizard command?

What is the goal someone running this will accomplish when you designed this?

I think Feature Flags are unique in that they reflect a need, a requirement for someone to safely introduce new code or run an experiment.

Where should this intent of the user come into play here?

Do you think this approach will be meaningful for a potential feature flags user?