Teach Claude how to create feature flags for Android

[SaintPatrck]

🎟️ Tracking

TBD

📔 Objective

Adds a new Claude Code skill that automates feature flag creation for Bitwarden Android.

Problem: Creating feature flags currently requires manually updating 4 different files (FlagKey.kt, FlagKeyTest.kt, FeatureFlagListItems.kt, strings_non_localized.xml) following specific naming conventions and patterns. This is repetitive, error-prone, and requires knowledge of the established conventions.

Solution: This skill automates the entire process by:

• Gathering requirements through interactive prompts
• Generating correct naming variants (kebab-case, PascalCase, snake_case)
• Validating uniqueness before making changes
• Updating all required files following established patterns from PR [PM-28442] Added feature flag for migrate myvault to myitems #6235
• Running tests and compilation verification
• Providing a complete summary of changes

Benefits:

• Reduces feature flag creation time from ~10-15 minutes to ~2-3 minutes
• Eliminates common mistakes (naming format errors, missing commas, incorrect ordering)
• Ensures consistency across all feature flags
• Provides progressive disclosure documentation with examples and troubleshooting
• Supports Boolean, Int, and String flag types for both Password Manager and Authenticator

The skill includes comprehensive documentation with a user-facing README, detailed reference materials, and real-world examples.

📸 Screenshots

Compare Claude changes (below) to changes in PR #6235

FeatureFlagListItems.kt

---

FlagKeyTest.kt

---

FlagKey.kt

---

strings_non_localized.xml

⏰ Reminders before review

• Contributor guidelines followed
• All formatters and local linters executed and passed
• Written new unit and / or integration tests where applicable
• Protected functional changes with optionality (feature flags)
• Used internationalization (i18n) for all UI strings
• CI builds passed
• Communicated to DevOps any deployment requirements
• Updated any necessary documentation (Confluence, contributing docs) or informed the documentation team

🦮 Reviewer guidelines

• 👍 (:+1:) or similar for great changes
• 📝 (:memo:) or ℹ️ (:information_source:) for notes or general info
• ❓ (:question:) for questions
• 🤔 (:thinking:) or 💭 (:thought_balloon:) for more open inquiry that's not quite a confirmed issue and could potentially benefit from discussion
• 🎨 (:art:) for suggestions / improvements
• ❌ (:x:) or ⚠️ (:warning:) for more significant problems or concerns needing attention
• 🌱 (:seedling:) or ♻️ (:recycle:) for future improvements or indications of technical debt
• ⛏ (:pick:) for minor or nitpick changes

[github-actions]

Checkmarx One – Scan Summary & Details – 9494824d-dfcb-42e1-a114-01dcecea736f

Great job! No new security vulnerabilities introduced in this pull request

[claude]

Claude finished @SaintPatrck's task —— View job

---

Code Review: PR #6238 - Add creating-feature-flags skill

Overall Assessment: ✅ APPROVE with suggested improvements

This PR adds a well-structured Claude Code skill for automating feature flag creation in Bitwarden Android. The documentation is comprehensive, progressive disclosure is properly implemented, and the skill follows established patterns from PR #6235. However, there are several accuracy issues and improvement opportunities detailed below.

---

🔴 Critical Issues

Finding 1: Incorrect string resource location guidance

File: .claude/skills/creating-feature-flags/SKILL.md:188-205

The skill instructs adding string resources to strings_non_localized.xml within the Debug Menu region. However, examining the codebase shows CXP flags use strings.xml (lines 864-865) while other flags use strings_non_localized.xml. The skill should clarify:

1. When to use strings.xml vs strings_non_localized.xml
2. That existing flags are inconsistent (some use strings.xml, most use strings_non_localized.xml)
3. The recommended approach going forward

Suggested fix: Add a note in Step 6 explaining the inconsistency and recommend defaulting to strings_non_localized.xml for debug menu items (which matches PR #6235's pattern).

---

Finding 2: Naming conventions table contains inaccurate data

File: .claude/skills/creating-feature-flags/reference/naming-conventions.md:130-136

The reference table shows:

| `cxp-import-mobile` | `CredentialExchangeProtocolImport` | `cxp_import` |

However, the actual string resource key cxp_import doesn't follow the "remove JIRA prefix" rule as documented. This creates confusion about whether abbreviated names are automatic or design decisions.

Suggested fix: Add a section explaining special cases where abbreviated names are preferred for brevity (e.g., cxp instead of credential-exchange-protocol-import-mobile), and note this is a design decision, not an automatic transformation.

---

Finding 3: Missing guidance on string resource naming variations

File: .claude/skills/creating-feature-flags/reference/naming-conventions.md:136

The table shows avoid_logout_on_kdf_change for keyName pm-23995-no-logout-on-kdf-change. The string resource key changes "no-logout" to "avoid-logout" - a semantic transformation that isn't explained in the naming conventions.

Suggested fix: Add a note explaining that string resource keys may use semantic variations for better human readability, and the skill should ask the user to confirm the generated string resource key rather than assuming automatic conversion.

---

Finding 4: Incomplete validation for string resource key uniqueness

File: .claude/skills/creating-feature-flags/SKILL.md:88-93

The skill validates keyName uniqueness by reading FlagKey.kt, but doesn't explicitly validate string_resource_key uniqueness against strings_non_localized.xml. Given that string resource names can diverge from automatic conversion (per Finding 3), this validation gap could cause runtime errors.

Suggested fix: In Step 2, add validation:

**Validate string resource uniqueness:**
- Read strings_non_localized.xml Debug Menu region
- Search for existing string resource names
- If duplicate found, suggest alternative

---

Finding 5: Inconsistent guidance on data class vs data object terminology

Files: Multiple locations

The codebase uses data object (Kotlin singleton), but several places in the skill say "data class":

• .claude/skills/creating-feature-flags/SKILL.md:100 - "Generated names: Data Class: {DataClassName}"
• .claude/skills/creating-feature-flags/SKILL.md:244 - "Data Class: {DataClassName}"

While "DataClassName" as a variable name is fine, the term "Data Class" in output summaries is technically incorrect.

Suggested fix: Use "Data Object" in user-facing output, keep "DataClassName" as the internal variable name for clarity.

---

🟡 Suggested Improvements

Finding 6: Missing verification for alphabetical ordering

File: .claude/skills/creating-feature-flags/SKILL.md:296-309

The validation checklist mentions verifying alphabetical ordering, and the troubleshooting guide discusses it, but Steps 3-5 don't explicitly instruct Claude to maintain alphabetical order when adding flags.

Suggested fix: In Steps 3-5, explicitly state:

**Insert in alphabetical order** - Find correct position based on DataClassName

---

Finding 7: Template lacks KDoc consistency

File: .claude/skills/creating-feature-flags/reference/file-templates.md:22-31

The templates use "Data object holding the feature flag key for..." but existing flags in the codebase have varying KDoc styles.

Suggested fix: Add a note: "Note: Existing flags have varying KDoc styles. Use this template for consistency in new flags."

---

Finding 8: Progressive disclosure could be optimized

File: .claude/skills/creating-feature-flags/SKILL.md:289-294

Step 2 says "Read reference/naming-conventions.md for detailed naming rules" without a conditional.

Suggested fix: Make loading conditional:

**If name generation is unclear or user requests examples**, read `reference/naming-conventions.md` for detailed naming rules.

This saves tokens for simple cases where the transformation is straightforward.

---

Finding 9: Example in scenarios.md references non-existent PR example

File: .claude/skills/creating-feature-flags/examples/scenarios.md:82

Scenario 1 uses "PM-12345 Enable Password History Export" as an example, but the actual reference PR #6235 used "PM-20558 Migrate My Vault to My Items".

Suggested fix: Either use the actual PR #6235 example as Scenario 1 for consistency, or add a note: "(hypothetical example)" to avoid confusion.

---

Finding 10: Missing edge case handling for JIRA ticket extraction

File: .claude/skills/creating-feature-flags/SKILL.md:64-70

The skill mentions JIRA pattern [A-Z]{2,4}-\d+ but doesn't handle edge cases:

• User provides "pm-12345-enable-totp" (already kebab-case)
• User provides "enable-totp (PM-12345)" (ticket at end)
• Multiple tickets: "PM-123 PS-456 Feature"

Suggested fix: Add explicit handling in Step 2 for these edge cases.

---

✅ Strengths

The skill demonstrates several excellent practices:

1. ✅ Comprehensive coverage - All four required files documented with complete templates
2. ✅ Proper YAML frontmatter - Valid structure with clear name, version, and description
3. ✅ Progressive disclosure - Reference materials separated and loaded on-demand
4. ✅ Real-world examples - 8 different use cases including edge cases
5. ✅ Thorough troubleshooting - 340-line guide covering compilation, tests, runtime, and build issues
6. ✅ Validation checklist - Anti-patterns and success criteria clearly defined
7. ✅ Accurate file paths - All file locations verified against actual repository structure
8. ✅ Clear step-by-step process - 8 well-defined steps with thinking blocks
9. ✅ Type support - Handles Boolean, Int, and String flags with appropriate templates
10. ✅ Test coverage - Includes test generation and verification steps

---

🔒 Security Considerations

✅ No security issues identified:

• No hardcoded secrets or credentials
• File operations use standard Edit/Read tools
• No unsafe shell commands
• Proper validation before file modifications

---

📊 Token Efficiency

File sizes are reasonable:

• SKILL.md: 344 lines (appropriate for main skill logic)
• Reference files: 136-363 lines each (good separation)
• Total: 1,643 lines across 6 files

The progressive disclosure pattern is well-implemented, loading reference materials only when needed.

---

📝 Recommendations

1. High priority: Address Findings 1-5 (accuracy and validation issues)
2. Medium priority: Address Findings 6-8 (consistency and optimization)
3. Low priority: Address Findings 9-10 (examples and edge cases)
4. Consider adding: A visual flowchart in README.md showing the 4-file modification pattern
5. Consider adding: A "Common Mistakes" section in README.md for quick reference

---

🎯 Summary

This skill is production-ready with minor corrections. The structure is solid, documentation is comprehensive, and it follows Claude Code best practices. The main issues are accuracy discrepancies between the skill documentation and actual codebase patterns (string resource locations, naming conventions). Once corrected, this will be a highly effective automation tool for Bitwarden Android feature flag creation.

Recommendation: Approve after addressing Findings 1-5 (should take ~30 minutes to update documentation)

---

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 85.39%. Comparing base (8c6782d) to head (ed095e5).
⚠️ Report is 1 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #6238      +/-   ##
==========================================
+ Coverage   84.90%   85.39%   +0.49%     
==========================================
  Files         989      755     -234     
  Lines       57570    54113    -3457     
  Branches     7914     7793     -121     
==========================================
- Hits        48880    46212    -2668     
+ Misses       5930     5188     -742     
+ Partials     2760     2713      -47     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.