/feature-flag-remove

Feature Flag Removal

> **Project context:** Values in angle brackets below (e.g. `<scheme>`, `<JIRA_KEY>`, `<flag-key-enum>`) are resolved at runtime — detect them from the project (`xcodebuild -list -json` for the scheme, `git`/`gh` for repo & owner, the branch name for the Jira key, a codebase search for flag/font files), or ask if they cannot be inferred. This plugin ships no per-project config.

Remove the feature flag **$ARGUMENTS** following the investigation plan.

**Prerequisite:** Must have an investigation file at `docs/feature-flags/issues/$ARGUMENTS.md`. Run `/feature-flag-check $ARGUMENTS` first if it doesn't exist.

Steps

1. Create Jira Task

Create a Jira task in the current sprint using `mcp__claude_ai_Atlassian__createJiraIssue`:

• **Project:** <JIRA_KEY>
• **Type:** Task
• **Summary:** `Remove feature flag: $ARGUMENTS`
• **Epic Link:** <JIRA_KEY>-EPIC (Firebase Flags Clean Up)
• **Assignee:** Current user (get from `git config user.email`)

Description template:

## Objective

Remove the `$ARGUMENTS` feature flag as part of the Firebase Feature Flags Maintenance initiative.

## Investigation

<Summary from docs/feature-flags/issues/$ARGUMENTS.md>

## Complexity

<Low/Medium/High based on investigation>

## Related

- Epic: <JIRA_KEY>-EPIC (Firebase Flags Clean Up)
- Notion: <notion-flags-tracker-url>

Save the Jira ticket number (e.g., <JIRA_KEY>-XXXX) for later use in commit messages and PR title.

2. Create Branch

Create a feature branch for this removal:

git checkout dev
git pull origin dev
git checkout -b feature/remove-flag-$ARGUMENTS

3. Check for Conflicting PRs

**IMPORTANT:** Before modifying RemoteConfig files, check for open PRs that touch the same files:

gh pr list --state open --json number,title,files --jq '.[] | select(.files[]?.path | test("<flag-key-enum>|<flag-defaults-file>")) | "PR #\(.number): \(.title)"'

**If PRs are found:** 1. ⚠️ **STOP and warn the user** with the list of conflicting PRs 2. Recommend syncing with those developers before proceeding 3. Options:

• Wait for the other PR to merge, then rebase
• Coordinate with the other developer to avoid conflicts
• Proceed only with explicit user confirmation

**Why this matters:** <flag-key-file> and <flag-defaults-file>.swift are shared files. Multiple PRs modifying them simultaneously will cause merge conflicts or overwrites.

4. Read the Investigation

Read `docs/feature-flags/issues/$ARGUMENTS.md` and understand:

• Files to delete
• Files to modify
• Tests to update
• The removal plan

**STOP if no investigation exists.** Run `/feature-flag-check` first.

5. Remove Flag Definition

Edit `<scheme>/Helpers/RemoteConfig/<flag-key-file>`:

• Remove the case for this flag

Edit `<scheme>/Helpers/RemoteConfig/<flag-defaults-file>.swift`:

• Remove the case from the switch statement

6. Delete Dead Code Files

For each file marked for deletion in the investigation:

• Delete the file entirely
• These are files that only exist for the feature being removed

6.1. V1/V2 Flow Removal (when applicable)

If the flag controls a V1/V2 flow with separate ViewControllers and components, follow this safety protocol:

A. Identify Entry Points

**V1 Entry Points (removal candidates):**

• Deep links V1 (e.g., `<deeplink-scheme>`)
• Universal Link Handlers V1
• Coordinators V1 and their navigation methods
• ViewControllers V1

**V2 Entry Points (NEVER remove):**

• Deep links V2 (e.g., `<v2-deeplink-scheme>`)
• Universal Link Handlers V2
• Coordinators V2 (e.g., `<FeatureA>Coordinator`, `<FeatureB>Coordinator`)

B. Map Module Dependencies

For each V1 module candidate for removal:

# Check if it's used by V2 code
grep -r "ModuleName" --include="*.swift" . | grep -v "V1ModulePath"

| Result | Action | |--------|--------| | References ONLY in V1 code | CAN remove | | References in V2 code too | DO NOT remove - it's shared |

C. Safe Execution Order

1. **FIRST:** Remove references in coordinators/handlers

• Edit ``<your-universal-link-router>.swift`` - remove V1 case
• Edit ``<your-app-coordinator>+UniversalLinkContent.swift`` - remove V1 method
• Remove V1 protocol conformances

2. **SECOND:** Intermediate build

   xcodebuild build -workspace <scheme>.xcworkspace -scheme <scheme>

**STOP if it doesn't compile.** Fix before deleting files.

3. **THIRD:** Delete Universal Link Handler V1

   rm -rf <scheme>/Coordinator/UniversalLink/Handlers/<V1Handler>/

4. **FOURTH:** Delete V1-only modules

   rm -rf <scheme>/Modules/<V1Module>/

5. **FIFTH:** Final build + tests

D. V2 Verification Checklist

After removal, verify that V2 continues working:

• [ ] V2 deep link opens correctly
• [ ] Navigation from the consumer feature to V2 works
• [ ] Navigation from Explore to V2 works
• [ ] No V2 coordinator was impacted
• [ ] Build passes without errors
• [ ] Tests pass

E. Common Modules to Preserve

These modules are frequently shared between V1 and V2:

• `<design-system-module>/` - used by <FeatureA>, <FeatureB>
• Domain models (`GuideModel`, etc.)
• Repositories with GraphQL queries

**NEVER delete shared modules without explicit verification.**

7. Verify Code Usage Before Removal

**IMPORTANT:** Before deleting any file, class, or component, verify it's not used elsewhere:

# For each file/class/component to be removed, search for references
grep -r "ClassName" --include="*.swift" .
grep -r "import ModuleName" --include="*.swift" .

**If references are found outside the flag context:** 1. List all usages found 2. **PROMPT the user:** "The following code is used in other contexts. Confirm removal?"

• Show each usage location
• Wait for explicit confirmation before proceeding

3. If user declines, skip that specific removal and note it in the report

**Examples of what to check:**

• Classes/structs being removed → search fo