--- name: ledgerhq/remove-feature-flag source: https://app.decimal.ai/s/ledgerhq-remove-feature-flag@1/SKILL.md source_sha256: 495f81af21e0 --- # Remove Feature Flag Run the complete removal workflow. Never write to Firebase. ## Invocation ```text /remove-feature-flag [FLAG_VALUE_JSON] [TICKET_URL] ``` Optional modifiers: - `proposal only` — analyze and propose without changing files - `no pr` — implement and validate without publishing - `no watch` — create the PR without waiting for CI Only `FEATURE_ID` is required. Treat invoking this command as authorization for the complete workflow unless a modifier limits it. Accept optional arguments in any trailing order: recognize the JSON object, an `http(s)` ticket URL, and the exact modifier phrases independently. For `proposal only`, stop after read-only analysis. Do not create Jira work, stash files, create a branch, commit, push, or publish a PR. Report the resolved behavior, owner, affected scope, proposed edits, planned validation, and skipped Jira/PR/CI actions. ## 1. Resolve the production behavior Derive the Firebase key with the repository's canonical snake-case mapping. 1. Parse and use `FLAG_VALUE_JSON` when supplied. Validate it against the flag definition and consumers. If it is invalid, lacks a boolean `enabled`, or omits `params` that code consumes, ask for a corrected production value. 2. Otherwise run: ```bash node .agents/skills/remove-feature-flag/scripts/read-production-flag.mjs "$FEATURE_ID" ``` 3. If the lookup is unavailable, missing, malformed, or unauthorized, ask the user for the production value. Never fall back to development. 4. If Firebase reports conditional values, or the JSON describes A/B variants, show them and ask which behavior to preserve. Do not choose a client-specific variant automatically. Preserve the resolved production behavior whether `enabled` is `true` or `false`, including the selected production `params`. ## 2. Protect local work and create the branch Record the initial branch/ref and worktree state. If dirty, stash staged, unstaged, and untracked files with a unique descriptive message; do not ask. Fetch the latest remote base and always create a new branch: ```text support/remove--flag- ``` Create it directly from the freshly fetched `origin/develop`. If the name collides, append a numeric suffix. Never reuse an existing branch or PR. ## 3. Resolve Jira context Identify the owning team from `flags/team-*` and `CODEOWNERS`; use the `codeownership` skill when a team directory is involved. When no ticket is supplied and Jira tools are available: 1. Search the owning team's backlog by feature id and Firebase key. 2. Reuse one clearly relevant removal ticket; ask if several match. 3. If none match, create an unassigned `Task` in project `LIVE` for the owning team. If Jira is unavailable, continue without a ticket and add this to the PR description: `No Jira linked: Jira access was unavailable during PR creation.` ## 4. Remove the flag Search tracked source across the whole repository for the feature id and Firebase key; ignore generated and build artifacts. Load and use all applicable repository skills for the files involved. - Delete the flag definition and barrel export. - Remove legacy `types-live`, defaults, devtools, analytics, E2E, mocks, and test references when present. - Inline only the selected production behavior; remove unreachable branches. - Update focused tests and snapshots without weakening coverage. - Keep the change isolated from unrelated cleanup. Firebase remains read-only. Add a post-release PR note to delete the remote key manually. ## 5. Validate and publish Use `cleanup` and `run-tests` for the affected packages and files, including `@shared/feature-flags` checks when its registry changes. Follow `docs/validate-before-finishing.md`. When those skills do not map a `shared/`, `features/`, `domain/`, or nested package, read its README and `package.json` and run the equivalent scoped commands directly. Unless `no pr` is set, invoke `create-pr` end-to-end as the single source of truth for Git conventions, changesets, commits, push, draft PR content, browser opening, and the generated (not posted) Slack message. Pass it the resolved behavior, Firebase key, Jira result, validation evidence, affected flows, and the manual Firebase cleanup note. For `no pr`, follow `git-conventions`, create a local commit after validation, and do not push. Preserve that commit on the removal branch before restoring the initial workspace. ## 6. Watch CI Skip this section for `no pr` or `no watch`. 1. Watch required checks on the draft PR. Accept `skipped` or `neutral` only for optional checks. 2. Use `fix-ci` for related failures, with at most three diagnose/fix/push cycles. 3. Re-run an apparently unrelated failure once. If it fails again, report it and stop without changing unrelated code. 4. When required draft checks pass, mark the PR Ready for review. 5. Continue watching checks triggered by that transition under the same rules. 6. Finish only when all required checks are green, or when a guardrail stops the workflow. ## 7. Restore the workspace On success or early stop, preserve any removal work on its branch or a recovery stash, then return to the initial branch/ref and restore the saved stash so the workspace matches its starting state. Never discard work. If restoration conflicts, stop and report the conflict without resolving unrelated user changes.