eng-flags

Create PostHog feature flags and update in-repo registries atomically.

Updated Aug 23, 2026
One-click install
npx skills add https://github.com/CasaPerks/casaflow --skill eng-flags
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: eng-flags
Source: https://github.com/CasaPerks/casaflow/tree/main/packs/engineering/skills/eng-flags
Command: npx skills add https://github.com/CasaPerks/casaflow --skill eng-flags

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

This Skill removes the risk of inconsistent feature-flag rollout by guiding you through a consent-driven, atomic creation workflow that keeps PostHog and per-repo registries in sync.

Core Features & Use Cases

  • Consent-gated flag creation: Drafts and confirms the flag details once, then creates it across configured PostHog environments.
  • Registry parity across repos: Verifies each touched repo has the configured registry path, then writes the correct CAS-577-shaped entry with owner and expected sunset.
  • Resilient handling with manual fallback: Retries transient MCP failures and, if needed, uses an explicit manual PostHog creation fallback while recording warnings in the spec when verification is uncertain.
  • Governed lifecycle semantics: Enforces kebab-case keys ending in -enabled (kill switch) or -rollout (adoption gate), with validated semantics, owner, description, and ISO sunset dates.

Quick Start

Use eng-flags to create the correct PostHog flag and update the configured feature-flag registries for the repos listed in your spec by running /casaflow:eng-flags when your plan task body includes it.

Frequently Asked Questions about eng-flags

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I keep feature flags in sync between PostHog and my repo registry?

Feature flag registry parity is maintained by validating flag keys and touched repos, creating flags across all configured PostHog environments, then writing alphabetically positioned registry entries with owner and sunset metadata.

What naming convention do feature flag keys need for rollout gates and kill switches?

Feature flag keys must use kebab-case, ending in `-rollout` for adoption gates or `-enabled` for kill switches, ensuring governed lifecycle semantics with validated descriptions and ISO sunset dates.

Can I create PostHog feature flags across multiple environments with automatic retry?

PostHog feature flag creation runs across all configured environments with retry-once logic for transient MCP failures, falling back to manual creation with recorded spec warnings if persistent MCP failure occurs.

Do I need to confirm feature flag details before writing to the registry?

Feature flag creation uses a consent-driven workflow where you draft and confirm free-text fields, flag keys, touched repos, and registry paths before any PostHog or in-repo registry modifications occur.

What happens when MCP integration fails during feature flag creation?

MCP integration failures trigger a single retry for transient errors, then escalate to a manual PostHog creation fallback that records verification warnings directly in the spec when flag state is uncertain.

How do I add a kill switch feature flag with an expected sunset date?

Kill switch flags require a kebab-case key ending in `-enabled`, an assigned owner, validated description, and an ISO sunset date, written as a CAS-577-shaped registry entry positioned alphabetically within the repo file.