What this prompt does
This prompt makes the AI build a feature-flag system with Laravel Pennant, scoped by [user_count] users and [feature_count] features on Laravel [laravel_version], following the [rollout_strategy] you choose. It configures the [storage_driver] store, defines flags using a [naming_convention], and implements complex resolution for [primary_feature] based on [resolution_criteria] — percentage rollouts via Lottery, organization targeting, and attribute targeting. Stating the user count and rollout strategy lets the AI design real gating rather than a boolean toggle.
The structure works because safe rollouts depend on the controls this prompt names. An [admin_panel] dashboard surfaces [metrics_to_track] and a kill-switch; Blade @feature directives and a [fallback_page] handle gating in views; and an A/B pattern with [variant_count] variants assigns users deterministically and tracks [conversion_events]. The canary step rolls out to [canary_percentage] first, watches for [monitoring_period], then expands — with tests using Feature::define(), activate(), and deactivate() for isolation. Stating [user_count] and the [storage_driver] lets the AI pick resolution logic that performs at your scale instead of recomputing flags on every request. The Blade @feature directives plus a JavaScript bridge expose the same flags to both server-rendered views and the frontend, and the Pennant-aware health check correlates error-rate spikes with recently activated features so a bad rollout is easy to spot.
When to use it
- You want to ship features behind a flag and roll out gradually
- You need percentage-based rollouts plus team or plan-tier targeting
- You want a kill-switch to instantly disable a risky feature for everyone
- You are running A/B tests and need deterministic, consistent variant assignment
- You want a canary deployment that monitors error rate before expanding
- You need an admin dashboard to toggle features per user or globally
Example output
The AI returns Pennant configuration, feature definitions with Lottery-based percentage logic and attribute targeting, an [admin_panel] dashboard listing features with activation status and a kill-switch, Blade @feature/@endfeature usage plus middleware redirecting to [fallback_page], a JavaScript bridge exposing active features, an A/B testing pattern with deterministic hashing across [variant_count] variants, a canary rollout starting at [canary_percentage], and tests covering both feature-on and feature-off paths.
Pro tips
- Keep
[naming_convention]consistent (category-prefixed kebab-case) so flags stay discoverable as[feature_count]grows - Make variant assignment deterministic via hashing — if it is random per request, your A/B data is worthless
- Define
[resolution_criteria]as concrete attributes (plan tier, account age, sample percentage) the AI can resolve - Always implement the kill-switch; it is the difference between a bad deploy and an outage
- Set
[canary_percentage]and[monitoring_period]conservatively for risky features and widen only after the metrics hold - Test both code paths explicitly with Feature::activate()/deactivate() so the off-path does not rot
- Track
[metrics_to_track]per feature from day one so you can tell whether a rollout is actually safe to widen - Use the
[fallback_page]redirect for gated routes so users without access land somewhere useful rather than on an error
