Reversible Exposure Control

This skill handles CF-03: Reversible Change Control and CF-04: Exposure Strategy from the release-decision framework.

These two control principles are handled together because they represent a single user decision intent: "I want to start showing this to users in a controlled way."

When to Activate

• A change is about to be implemented that will affect user behavior, adoption, or outcomes
• A change exists but is not yet behind a feature flag (not reversible)
• A feature flag exists but exposure strategy is undefined or implicit
• User asks about rollout percentages, targeting, or who should see a variant
• The user owns the decision but not the codebase, the wrapper around FeatBit, or the flag operations
• Project stage is implementing or exposing

On Entry — Read Current State

Before doing any work, read the project from the database using the project-sync skill's get-project command.

Check these fields:

Field	Purpose
goal	Confirms business outcome exists
hypothesis	Confirms causal claim exists
constraints	Existing flag contract / rollout constraints
stage	Current lifecycle position

• If hypothesis is empty → redirect to hypothesis-design
• If stage is already exposing → resume from rollout / expansion rather than restarting
• If constraints already has flag contract details → build on existing rather than overwriting

Default Operating Mode

Start by deciding which role the current user is playing.

• Spec owner / PM / experiment owner: they need to define the flag contract, targeting intent, rollout logic, and rollback triggers clearly enough for another team to implement. This is the default path.
• Operator / developer: they can create the flag, wire the SDK or wrapper, and configure rollout directly in FeatBit or another flag system.

Do not assume the current user can touch code, run vendor tooling, or change production flags.

Decision Actions (by user intent)

"I need to hand this feature flag requirement to the team that owns code or flags"

1. Confirm the business goal, hypothesis, and primary metric already exist
2. Define the flag contract: human-readable name, stable key, flag type, and variants
3. Define the implementation decision point: where the flag should be evaluated and what behavior changes per variant
4. Define targeting and protection rules: who sees the candidate first, who must not see it, and which user attribute controls assignment
5. Define rollout logic: initial exposure, expansion checkpoints, stop conditions, and rollback triggers
6. Define ownership and operational expectations: who creates the flag, who wires the wrapper or SDK, who approves expansion, who can disable it
7. Package the result as a handoff spec using references/pm-dev-handoff.md

"I want to create a feature flag for this change"

Use this path only if the current user actually owns flag operations. Otherwise, switch to the handoff path above.

1. Confirm feature flag key naming (kebab-case, descriptive, environment-agnostic)
2. Define variants: baseline (control) and candidate (treatment) — if non-boolean, set up variants in the web UI first
3. Look up the environment ID: featbit flag list <env-id> or featbit project get <project-id>
4. Create the flag in the OFF state: featbit flag create <env-id> --flag-name "..." --flag-key ...
5. For multi-variant flags or custom variation values: use references/tool-featbit-webui.md

"I want to start rolling this out"

1. Confirm hypothesis and primary metric exist first
2. Confirm who is protected (must NOT see the candidate)
3. Set initial exposure: default 5–10%
4. Define expansion criteria in advance — what evidence justifies moving to 25%, 50%, 100%
5. Define rollback triggers — what signals cause immediate revert
6. Read: references/rollout-patterns.md for strategy
7. Set rollout: featbit flag set-rollout <env-id> <flag-key> --rollout '<json>'
8. Enable the flag: featbit flag toggle <env-id> <flag-key> true
9. To rollback: featbit flag toggle <env-id> <flag-key> false

"I want to target a specific audience"

1. Identify the targeting rule: user property, segment, or custom attribute
2. Confirm this audience is the right proxy for the hypothesis audience
3. If implementation is owned by another team, describe the targeting logic in the handoff spec instead of assuming direct FeatBit access
4. Set targeting rules in the FeatBit web UI before enabling the flag — see references/tool-featbit-webui.md for targeting rule setup
5. After rules are set, proceed to rollout using the CLI (see "I want to start rolling this out" above)

"I want to add the feature flag to my code"

Use this path only if the current user can change application code. If not, create a handoff spec that names the exact insertion point and expected variant behavior.

1. Identify the language or framework in use
2. Install the FeatBit SDK skill: npx skills add featbit/featbit-skills --skill featbit-sdks-[language]
3. Follow the SDK skill to add the variation() call at the correct point in the code path
4. Use references/tool-featbit-cli.md to verify the flag key matches what is in the codebase

"I have multiple experiments planned on the same flag or surface"

1. Determine whether experiments are sequential or must run concurrently
2. Default to sequential design: run Experiment 1 to conclusion, then start Experiment 2. This avoids mutual-exclusion complexity and gives each experiment the full traffic pool
3. If experiments must run concurrently on the same surface, use mutual exclusion: partition traffic into non-overlapping segments via hashed dispatch key. Each experiment gets its own slice
4. If experiments are concurrent but on independent surfaces with no shared metrics, use orthogonal design: no traffic splitting needed
5. Run sample-size calculations on the reduced traffic pool for concurrent designs — underpowered experiments are worse than sequential with a wait
6. Document the chosen strategy in the handoff spec and in the exposure activity log
7. Read: references/multi-experiment-traffic.md for detailed patterns and anti-patterns

Operating Rules

• Reversibility (feature flag exists) must be confirmed before exposure begins
• Never start at 100% unless protected audience targeting is explicitly intentional
• Default to a written implementation handoff when the user cannot operate the flag system or edit code directly
• Treat FeatBit CLI and Web UI as optional adapters, not the required workflow of this skill
• The important artifact is the flag contract and rollout intent; the vendor tool is secondary
• Hand off to measurement-design if instrumentation is not confirmed before exposure begins

Persist State

After completing work, use the project-sync skill to persist state to the database:

1. update-state — save --constraints "<flag contract and rollout criteria>" and --lastAction "<what was done>"
2. set-stage — set to implementing (flag contract defined, not yet live) or exposing (traffic is live)
3. add-activity — record what happened, e.g. --type stage_update --title "Flag contract ready"

Reference Files

• references/rollout-patterns.md — vendor-agnostic rollout strategy, progressive exposure, protected audience guidance
• references/multi-experiment-traffic.md — sequential, mutual-exclusion, and orthogonal patterns for multi-experiment traffic allocation
• references/pm-dev-handoff.md — PM or experiment owner handoff template for the team that owns code, wrappers, and flag operations
• references/tool-featbit-cli.md — FeatBit CLI: config, inspect, flag create/toggle/archive/set-rollout/evaluate, SDK integration via featbit-skills
• references/tool-featbit-webui.md — FeatBit web UI: targeting rules, multi-variant setup, audit trail, RBAC management