Feature Flags

Deep feature flag workflow—taxonomy, targeting, lifecycle, safety and kill switches, cleanup, and governance. Use when shipping gradually, experimenting, or...

Security Scan

This is an instruction-only best-practices guide for feature-flag workflows; it contains no code, no installs, and requests no credentials or system access, so its declared purpose aligns with its contents.

Purpose & Capability

Name and description (feature-flag workflow and lifecycle) match the SKILL.md content. The skill does not request binaries, env vars, or other resources that would be unexpected for a documentation/guide skill.

Instruction Scope

SKILL.md is purely prescriptive guidance (taxonomy, targeting, safety, governance, checklist). It does not instruct the agent to read files, access credentials, call external endpoints, or run commands outside the scope of providing advice.

Install Mechanism

No install spec and no code files are present. Because it is instruction-only, nothing is written to disk and there is no install-time risk.

Credentials

The skill declares no required environment variables, credentials, or config paths. That is proportionate for a workflow guide and avoids unnecessary access to secrets or systems.

Persistence & Privilege

Flags show default behavior (not always, agent-invocable allowed). Autonomous invocation is platform-default and not by itself concerning for an instruction-only guidance skill.

Assessment

This skill is a safe, read-only best-practices checklist for feature-flag workflows. It does not install software or request secrets. Before relying on it operationally, verify provider-specific behaviors (LaunchDarkly, Unleash, ConfigCat, or your homegrown system), ensure runbooks and audit/logging are implemented in your environment, and avoid using this guide as an automated source of truth for making changes — any real integrations will require separate, explicit provider credentials and tooling.

Flags decouple deploy from release—and become debt if never removed. Taxonomy, ownership, and retirement matter as much as targeting.

When to Offer This Workflow

Trigger conditions:

• Gradual rollouts, kill switches, or experiments behind flags
• Flag sprawl and unknown defaults
• Client vs server evaluation and hydration flicker

Initial offer:

Use six stages: (1) taxonomy, (2) targeting rules, (3) evaluation & consistency, (4) safety & ops, (5) lifecycle & cleanup, (6) governance). Confirm provider (LaunchDarkly, Unleash, ConfigCat, homegrown).

---

Stage 1: Taxonomy

Goal: Separate short-lived release flags, long-lived config flags, and experiment flags tied to analytics.

Exit condition: Naming convention and expected TTL per type.

---

Stage 2: Targeting Rules

Goal: Percentage rollouts, segments (tenant, plan, region), deterministic bucketing (stable user key).

---

Stage 3: Evaluation & Consistency

Goal: Server-side authoritative for security and billing; client flags for UX only; avoid UI flicker on hydration (SSR/CSR agreement).

---

Stage 4: Safety & Ops

Goal: Kill-switch runbook; audit trail for changes; safe defaults when provider unavailable (often “off”).

---

Stage 5: Lifecycle & Cleanup

Goal: Tickets to remove flags after full rollout; periodic audits; metric for stale flags.

---

Stage 6: Governance

Goal: Approvals for broadening exposure; promotion across environments; break-glass access for incidents.

---

Final Review Checklist

• Flag types and naming documented
• Targeting and bucketing deterministic
• Server vs client boundaries clear
• Kill switches and defaults documented
• Cleanup process and ownership

Tips for Effective Guidance

• Never put security-only gates solely in client-side flags.
• Pair with ab-testing when experiment analysis is primary.

Handling Deviations

• Align with release-management for communication cadence.