# Statsig Development Guidelines
It is important that we selectively killswitch new features or any new, risky codepaths using Statsig Feature Gates so that we can turn them off if they cause issues.
## When To Use Gates
- We should consider adding a gate whenever we make significant changes to product features that have any risk of causing issues.
- It is possible for this to be spammy, so clarify with users during planning what should be killswitched.
- Start by assuming atomic, session-level features will be killswitched - e.g. "A new modal" would be, but not a copy change within a modal, or a bugfix.
- Sometimes, adding a gate is just as dangerous as the feature itself.
- Identify situations where this could occur - usually when adding the gate adds a large amount of complexity - and flag the risk to the user when asking if they want to create a gate.
Always ask the user if they want to gate the feature. Often, users will want to include the feature behind an existing gate, so ask in this way, when appropriate:
"This seems like a feature that you might want to be able to turn off remotely. Would you like to gate this feature, add it to an existing gate, or proceed without using gates?"
Look for gates already being used for this feature type - often in the same file or nearby in the file tree for client code.
Don't spend a bunch of time investigating code before asking, since it leads to a lot of hang time. This should be an early step in the process.
Quickly check in with the user on gating before you do a deep codebase scan - though you might want to use a quick context check to identify risk.
## How to Use Gates
- Create a new gate, if requested, using the statsig-local MCP server. If this server does not exist, ignore the above.
- After creation, use that gate in code, following the local codebase patterns for accessing statsig.
- This will normally be Statsig.useGate() or similar, but they may have an internal wrapper or use a general feature flag library which wraps Statsig.
- When creating the gate, start it with a default-fail rules. The user, or we, can add rules later to release the gate.
- Add a rule called "Development" which passes the user's ID, specified below. Make sure this is the first evaluated rule.
## Override instructions
- The user's ID is the string ""
- Use a custom ID gate condition, with the userID field set to that ID
## Naming Conventions
- For these features, create a feature gate which is a 3-4 word description separated by dashes.
- Do not use the word killswitch. Propose the name of the gate before creating it, allowing the user to update it if desired. Do not include your name (e.g. codex, claude, cursor) in the gate name.
## Logging
- We would like to measure our gate changes as we roll out features.
- If there's key interactions in the code which are not logged to Statsig, consider logging those events to statsig
- Include critical metadata (e.g. information about what happened, key numeric values)
Propose these logging changes to the user and see what they say, and only if they're very clearly needed. Similar to the gate checks, pattern match to what is in the repo already, e.g.
Statsig.logEvent or a wrapper like LoggingContext.log()
## Statsig Implementation Instructions
[left empty - fill with specific instructions about your Statsig implementation if it exists, such as specific calling patterns or gotchas]
## Guardrails and Critical Rules
- In this context, only use this MCP server to create gates
- Never run deletions or other destructive tools without explicit instructions from the user
