feature-flags

AI Community

Repo stars 245,422
Author repo react

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Use when feature flag tests fail, flags need updating, understanding @gate pragmas, debugging channel-specific test failures, or…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “Flag Files”, “Gating Tests”, “@gate pragma (test-level)”, “gate() inline (assertion-level)”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name feature-flags directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “Flag Files / Gating Tests / @gate pragma (test-level)” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

React Feature Flags

Flag Files

File	Purpose
`packages/shared/ReactFeatureFlags.js`	Default flags (canary), `__EXPERIMENTAL__` overrides
`packages/shared/forks/ReactFeatureFlags.www.js`	www channel, `__VARIANT__` overrides
`packages/shared/forks/ReactFeatureFlags.native-fb.js`	React Native, `__VARIANT__` overrides
`packages/shared/forks/ReactFeatureFlags.test-renderer.js`	Test renderer

Gating Tests

`@gate` pragma (test-level)

Use when the feature is completely unavailable without the flag:

// @gate enableViewTransition
it('supports view transitions', () => {
  // This test only runs when enableViewTransition is true
  // and is SKIPPED (not failed) when false
});

`gate()` inline (assertion-level)

Use when the feature exists but behavior differs based on flag:

it('renders component', async () => {
  await act(() => root.render(<App />));

  if (gate(flags => flags.enableNewBehavior)) {
    expect(container.textContent).toBe('new output');
  } else {
    expect(container.textContent).toBe('legacy output');
  }
});

Adding a New Flag

Add to ReactFeatureFlags.js with default value
Add to each fork file (*.www.js, *.native-fb.js, etc.)
If it should vary in www/RN, set to __VARIANT__ in the fork file
Gate tests with @gate flagName or inline gate()

Checking Flag States

Use /flags to view states across channels. See the flags skill for full command options.

`VARIANT` Flags (GKs)

Flags set to __VARIANT__ simulate gatekeepers - tested twice (true and false):

/test www <pattern>              # __VARIANT__ = true
/test www variant false <pattern> # __VARIANT__ = false

Debugging Channel-Specific Failures

Run /flags --diff <channel1> <channel2> to compare values
Check @gate conditions - test may be gated to specific channels
Run /test <channel> <pattern> to isolate the failure
Verify flag exists in all fork files if newly added

Common Mistakes

Forgetting both variants - Always test www AND www variant false for __VARIANT__ flags
Using @gate for behavior differences - Use inline gate() if both paths should run
Missing fork files - New flags must be added to ALL fork files, not just the main one
Wrong gate syntax - It's gate(flags => flags.name), not gate('name')

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: AI
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @facebook · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview feature-flags.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# React Feature Flags

## Flag Files

| File | Purpose |
|------|---------|
| `packages/shared/ReactFeatureFlags.js` | Default flags (canary), `__EXPERIMENTAL__` overrides |
| `packages/shared/forks/ReactFeatureFlags.www.js` | www channel, `__VARIANT__` overrides |
| `packages/shared/forks/ReactFeatureFlags.native-fb.js` | React Native, `__VARIANT__` overrides |
| `packages/shared/forks/ReactFeatureFlags.test-renderer.js` | Test renderer |

## Gating Tests

### `@gate` pragma (test-level)

Use when the feature is completely unavailable without the flag:

```javascript
// @gate enableViewTransition
it('supports view transitions', () => {
  // This test only runs when enableViewTransition is true
  // and is SKIPPED (not failed) when false
});
```

### `gate()` inline (assertion-level)

Use when the feature exists but behavior differs based on flag:

```javascript
it('renders component', async () => {
  await act(() => root.render(<App />));

  if (gate(flags => flags.enableNewBehavior)) {
    expect(container.textContent).toBe('new output');
  } else {
    expect(container.textContent).toBe('legacy output');
  }
});
```

## Adding a New Flag

1. Add to `ReactFeatureFlags.js` with default value
2. Add to each fork file (`*.www.js`, `*.native-fb.js`, etc.)
3. If it should vary in www/RN, set to `__VARIANT__` in the fork file
4. Gate tests with `@gate flagName` or inline `gate()`

## Checking Flag States

Use `/flags` to view states across channels. See the `flags` skill for full command options.

## `__VARIANT__` Flags (GKs)

Flags set to `__VARIANT__` simulate gatekeepers - tested twice (true and false):

```bash
/test www <pattern>              # __VARIANT__ = true
/test www variant false <pattern> # __VARIANT__ = false
```

## Debugging Channel-Specific Failures

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> Flag Files → Gating Tests → @gate pragma (test-level) → gate() inline (assertion-level) → Adding a New Flag → Checking Flag States
terms    -> Forgetting both variants · Using @gate for behavior differences · Missing fork files · Wrong gate syntax
files/cmd -> packages/shared/ReactFeatureFlags.js · EXPERIMENTAL · packages/shared/forks/ReactFeatureFlags.www.js · VARIANT · packages/shared/forks/ReactFeatureFlags.native-fb.js · packages/shared/forks/ReactFeatureFlags.test-renderer.js · @gate · gate()
body sha256 -> ab070c03162b