Menu
Permanently remove a feature flag, enabling the gated feature forever. Use when asked to remove a flag, graduate a flag, or make a flagged feature always-on.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
| name | remove-flag |
| description | Permanently remove a feature flag, enabling the gated feature forever. Use when asked to remove a flag, graduate a flag, or make a flagged feature always-on. |
| disable-model-invocation | true |
| argument-hint | <flag-name> |
Permanently enable a feature flag by removing all gating — the feature becomes always-on.
Flag to remove: $ARGUMENTS
Find all references — search the entire codebase for the flag name (string literal, template variable, docs, etc.)
lib/config.ts:
KNOWN_FLAGS arrayKNOWN_FLAG_DESCRIPTIONS objectALWAYS_ON_FLAGS array if present (leave the array intact with remaining entries)index.ts — find any if (hasFlag("<flag>")) guards. Remove the conditional but keep the guarded code (e.g. program.addCommand(...) becomes unconditional). If hasFlag is no longer used anywhere in the file, remove its import.
Template files in project-template/ — find <% if (it.<flag>) { %> and matching <% } %> blocks. Remove the Eta conditionals but keep the content between them. Be careful to match opening/closing pairs correctly — do not remove <% } %> that belongs to a different conditional.
Documentation — remove the flag row from the Experimental Flags table in AGENTS.md if present. Check README.md and project-template/.claude/skills/fusebase-cli/SKILL.md for any mention that the feature requires the flag.
Verify — run error checking on modified files. Confirm no remaining references to the flag as a feature flag (references to the feature itself, e.g. "cron jobs", are fine — only remove the flag gating).
Guide for adding a backend layer (REST API, WebSockets, cron jobs) to Fusebase Apps apps. Use when: (1) An app needs a server-side API beyond the Dashboard SDK, (2) Adding REST endpoints or WebSocket support, (3) Setting up the backend/ folder structure, (4) Scheduling cron jobs for periodic tasks. The backend is OPTIONAL — only add when the app genuinely requires server-side logic.
Guide for managing sidecar containers alongside app backends. Use when: (1) An app backend needs auxiliary services like headless browsers, caches, or other tools, (2) Adding/removing/listing sidecar containers, (3) Configuring sidecar networking, env vars, or resource tiers.
Complete guide for using the Fusebase CLI (fusebase) tool to initialize, develop, and deploy Fusebase Apps apps. Use when: 1. Initializing new Fusebase Apps projects, 2. Creating or configuring apps, 3. Running apps locally or deploying them 4. Setting up app permissions for dashboards.
Guide for creating and using secrets in Fusebase Apps app backends. Use when: (1) An app backend needs API keys, passwords, or other sensitive config, (2) Creating secrets via the CLI, (3) Accessing secrets at runtime in backend code, (4) Deciding what should be a secret vs. a regular env var.
How to use MCP for Fusebase Gate. Use when: working with gate contracts, tokens, org user listing, health, or generated MCP tools and prompts.
Required patterns for auth and session errors in Fusebase Apps: AppTokenValidationError (401) on platform tokens, and backend session probes (/api/account/me) for SaaS apps with httpOnly cookies. Use when implementing auth error handling, AuthExpiredModal, session bootstrap on load, or global API error handlers.
Based on SOC occupation classification
