feature-toggle-developer
This analyzes feature flag definitions and usage to facilitate the complete removal of unused logic after toggles are deleted.
Install
mkdir -p .claude/skills/feature-toggle-developer && curl -L -o skill.zip "https://agentskills.codes/api/skills/download/4309" && unzip -o skill.zip -d .claude/skills/feature-toggle-developer && rm skill.zipInstalls to .claude/skills/feature-toggle-developer
Activation
This is the description your AI agent reads to decide when to run this skill — the better it matches your request, the more reliably it fires.
Guides systematic removal of feature toggles from the codebase with automated cleanup detection. Use when removing feature flags, enabling toggles permanently, or cleaning up unused code after toggle removal.Key capabilities
- →Identify toggle usage patterns
- →Remove conditional logic branches
- →Detect orphaned state variables
- →Clean up unused view components
- →Update code generation artifacts
How it works
The process involves analyzing toggle definitions, determining the branch to keep based on default values, and systematically removing all references, state variables, and unused components.
Inputs & outputs
When to use feature-toggle-developer
- →Remove feature flags permanently
- →Clean up code after toggle removal
- →Identify dead code branches from feature flags
- →Safely enable features in production
About this skill
Feature Toggle Developer
Status: Active
Auto-activates on: Feature flag/toggle removal, cleanup after refactoring toggles
Related Skills: code-generation-developer, ios-dev-guidelines, code-review-developer
Purpose
Guides the systematic removal of feature toggles (feature flags) from the codebase with automated cleanup detection. Ensures no orphaned code, unused components, or forgotten files remain after toggle removal.
When This Skill Activates
- User mentions: "remove toggle", "delete feature flag", "enable feature toggle permanently"
- User edits:
FeatureDescription+Flags.swift - After completing toggle removal: helps identify cleanup opportunities
Feature Toggle Removal Workflow
Phase 1: Pre-Removal Analysis
Before removing any toggle, gather complete information:
-
Find the toggle definition:
# Location: Modules/AnytypeCore/AnytypeCore/Utils/FeatureFlags/FeatureDescription+Flags.swift rg "static let toggleName" --type swift -
Check the defaultValue to determine which branch to keep:
defaultValue: true→ Keep the TRUE branch, remove FALSE branchdefaultValue: false→ Keep the FALSE branch, remove TRUE branch
-
Search for ALL usages:
rg "toggleName" --type swift -
Identify usage patterns:
- Direct:
if FeatureFlags.toggleName { ... } - Inverted:
if !FeatureFlags.toggleName { ... }orguard !FeatureFlags.toggleName - Compound:
if FeatureFlags.toggleName && otherCondition { ... } - Assignment:
let value = FeatureFlags.toggleName ? a : b - State:
@State private var toggle = FeatureFlags.toggleName
- Direct:
-
List affected files and present to user for review
Phase 2: Toggle Removal
Systematic removal process:
-
Remove conditional checks and simplify:
Example 1 - Simple conditional (defaultValue: true):
// BEFORE if FeatureFlags.toggleName { // feature code } // AFTER (keep true branch) // feature codeExample 2 - Ternary operator (defaultValue: true):
// BEFORE VStack(spacing: FeatureFlags.toggleName ? 8 : 0) // AFTER VStack(spacing: 8)Example 3 - Inverted logic (defaultValue: true):
// BEFORE guard !FeatureFlags.toggleName else { return } oldCode() // AFTER (flag is true, so guard fails, remove entire block) // [entire block deleted]Example 4 - State variable (defaultValue: true):
// BEFORE @State private var toggle = FeatureFlags.toggleName if toggle { newUI() } else { oldUI() } // AFTER newUI() // Note: @State variable removed in cleanup phase -
Remove feature flag definition:
// Delete from: Modules/AnytypeCore/AnytypeCore/Utils/FeatureFlags/FeatureDescription+Flags.swift static let toggleName = FeatureDescription(...) -
Run code generation:
make generateThis updates
FeatureFlags+Flags.swiftautomatically. -
Verify removal:
rg "toggleName" --type swift # Should return no results
Phase 3: Automated Cleanup Detection ⭐
CRITICAL: After toggle removal, systematically check for orphaned code:
3.1 Unused State Variables
Search for @State variables that were only used for the toggle:
# Look for patterns like: @State private var someToggle = FeatureFlags.toggleName
rg "@State.*=.*FeatureFlags" --type swift
Action: Remove the entire @State variable declaration if it's no longer used.
3.2 Unused View Components
When a toggle controlled which UI component to show, one component may now be unused:
Detection Pattern:
- Toggle switched between ComponentA and ComponentB
- After removal, only one is used
- Search for the unused component's name across codebase
Example from vaultBackToRoots:
// BEFORE
if !vaultBackToRootsToggle {
SpaceCardLabel(...) // This became unused
} else {
NewSpaceCardLabel(...)
}
// AFTER
NewSpaceCardLabel(...)
// CLEANUP: SpaceCardLabel is now unused
rg "SpaceCardLabel" --type swift # Check if used anywhere else
# If only in its own file → DELETE the file
Action:
- Search for unused component name:
rg "UnusedComponentName" --type swift - If only found in its definition file and comments → DELETE the file
- Update references in comments
3.3 Unused ViewModels / Service Classes
Toggle removal may leave entire classes unused:
Detection:
# For each major component that was conditionally used:
rg "UnusedViewModel" --type swift
rg "class UnusedViewModel" --type swift
Action: Delete unused ViewModels, their files, and DI registrations.
3.4 Unused Imports
After simplification, import AnytypeCore may only have been needed for FeatureFlags:
Detection:
- File imports
AnytypeCore - Only usage was
FeatureFlags.toggleName - After removal, no other
AnytypeCoreusage
Action: Remove unused import.
3.5 Orphaned Parameters / Properties
Toggle-gated functionality may have parameters that are no longer needed:
Example:
// BEFORE
func configure(showFeature: Bool) {
if showFeature && FeatureFlags.toggle { ... }
}
// AFTER toggle removal
func configure(showFeature: Bool) {
if showFeature { ... }
}
// POTENTIAL CLEANUP: Is showFeature still needed?
Action: Review function signatures and remove unnecessary parameters.
3.6 Test Cleanup
Toggle removal affects tests:
Check:
- Mock objects with toggle-related properties
- Test cases specifically for toggle behavior
- Test setup code with toggle configurations
Files to check:
rg "toggleName" AnyTypeTests/ --type swift
rg "toggleName" "Anytype/Sources/PreviewMocks/" --type swift
Action: Update or remove tests for deleted code paths.
Phase 4: Final Verification
Before committing:
-
Grep verification:
rg "toggleName" --type swift # Should be empty -
Compilation check:
- Remind user to verify compilation in Xcode
- Claude cannot verify this due to caching
-
Generate updated commit message:
IOS-XXXX Removed [toggleName] toggle -
Review cleanup summary:
- List all files modified
- List all files deleted
- Note any remaining manual checks needed
Cleanup Checklist Template
Use this checklist after every toggle removal:
## Cleanup Verification for [toggleName]
- [ ] Toggle definition removed from FeatureDescription+Flags.swift
- [ ] `make generate` run successfully
- [ ] All conditional usage removed
- [ ] No grep results for toggle name
- [ ] Unused @State variables removed
- [ ] Unused view components identified and deleted
- [ ] Unused ViewModels/services deleted
- [ ] Unused imports removed (especially AnytypeCore)
- [ ] Orphaned function parameters removed
- [ ] Tests updated (check AnyTypeTests/ and PreviewMocks/)
- [ ] Comments referencing old component updated
- [ ] Xcode compilation verified (by user)
Common Patterns & Pitfalls
Inverted Logic
Watch out for !FeatureFlags.toggle:
// If defaultValue: true
if !FeatureFlags.toggle {
oldCode() // This branch NEVER runs, delete it
}
Compound Conditions
Simplify conditions properly:
// BEFORE (defaultValue: true)
if FeatureFlags.toggle && userHasPermission {
showFeature()
}
// AFTER
if userHasPermission {
showFeature()
}
Guard Statements
Be careful with guards:
// BEFORE (defaultValue: true)
guard !FeatureFlags.toggle else { return }
performOldBehavior()
// AFTER (toggle is true, guard returns, entire block is dead code)
// DELETE ENTIRE BLOCK
Integration with Other Skills
- code-generation-developer: References for
make generatecommand and troubleshooting - ios-dev-guidelines: Swift refactoring patterns, import management
- code-review-developer: Cleanup standards, ensuring no orphaned code in PRs
When not to use it
- →Removing toggles that are still active in production
- →Deleting code without verifying compilation
Prerequisites
Limitations
- →Requires manual compilation verification in Xcode
How it compares
This method uses automated cleanup detection and grep-based verification to ensure no orphaned code remains, unlike manual deletion.
Compared to similar skills
feature-toggle-developer side by side with the closest alternatives in the catalog.
| Skill | Installs | Updated | Safety | Difficulty |
|---|---|---|---|---|
| feature-toggle-developer (this skill) | 1 | 6mo | Review | Intermediate |
| swiftui-view-refactor | 0 | 7mo | No flags | Intermediate |
| swiftdata-pro | 0 | 3mo | Review | Intermediate |
| swift-coding | 0 | 1mo | Review | Intermediate |
Try saying
Example prompts that trigger this skill in your AI assistant.
More by anyproto
View all by anyproto →You might also like
swiftui-view-refactor
hot666666
Refactor and review SwiftUI view files for consistent structure, dependency injection, and Observation usage. Use when asked to clean up a SwiftUI view’s layout/ordering, handle view models safely (non-optional when possible), or standardize how dependencies and @Observable state are initialized and
swiftdata-pro
sobchak-security
Writes, reviews, and improves SwiftData code using modern APIs and best practices. Use when reading, writing, or reviewing projects that use SwiftData.
swift-coding
Dynokostya
Apply when writing or editing Swift (.swift) files. Behavioral corrections for error handling, concurrency, memory management, type safety, protocol-oriented design, security defaults, and common antipatterns. Project conventions always override these defaults.
swift-concurrency
AvdLee
Expert guidance on Swift Concurrency best practices, patterns, and implementation. Use when developers mention: (1) Swift Concurrency, async/await, actors, or tasks, (2) "use Swift Concurrency" or "modern concurrency patterns", (3) migrating to Swift 6, (4) data races or thread safety issues, (5) refactoring closures to async/await, (6) @MainActor, Sendable, or actor isolation, (7) concurrent code architecture or performance optimization, (8) concurrency-related linter warnings (SwiftLint or similar; e.g. async_without_await, Sendable/actor isolation/MainActor lint).
swift-concurrency-expert
Dimillian
Swift Concurrency review and remediation for Swift 6.2+. Use when asked to review Swift Concurrency usage, improve concurrency compliance, or fix Swift concurrency compiler errors in a feature or file.
ios-dev-guidelines
anyproto
Context-aware routing to Swift/iOS development patterns, architecture, and best practices. Use when working with .swift files, ViewModels, Coordinators, refactoring, or discussing Swift/SwiftUI patterns.