// AI implements a new feature using generic Android patterns
class NewFeatureActivity : AppCompatActivity() {
    private lateinit var binding: ActivityNewFeatureBinding

    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        binding = ActivityNewFeatureBinding.inflate(layoutInflater)
        setContentView(binding.root)
    }
}

# Example: Adding a new settings toggle

# 1. Find existing toggles
grep -r "SwitchMaterial" app/src/main/res/layout/

# 2. Find toggle handling code
grep -r "setOnCheckedChangeListener" app/src/main/kotlin/

# 3. Examine settings architecture
ls -la app/src/main/kotlin/**/settings/

# Check for architectural guidance
cat .agent/ARCHITECTURE.md
cat .agent/AGENTS.md
cat .agent/DEVELOPMENT_NOTES.md

// Read existing code to understand patterns
// Example: Before adding new theme option

// 1. Read existing theme toggle
Read: SettingsBottomSheet.kt
Read: ThemeManager.kt

// 2. Understand state management
Read: SettingsDataStore.kt or SharedPreferences usage

// 3. Check UI patterns
Read: layout/bottom_sheet_settings.xml

## Implementation Plan

### Existing Patterns Discovered
- Settings stored in: SharedPreferences (`SettingsManager.kt`)
- Toggles defined in: `bottom_sheet_settings.xml`
- Naming: `is[Feature]Enabled` (e.g., `isOledProtectionEnabled`)
- UI Pattern: Material SwitchMaterial with custom styling

### My Implementation Will
- [ ] Store setting in SharedPreferences via SettingsManager
- [ ] Add SwitchMaterial to bottom_sheet_settings.xml
- [ ] Follow `is*Enabled` naming convention
- [ ] Use existing toggle listener pattern
- [ ] Match existing toggle spacing/styling

// ❌ Generic implementation (ignore existing patterns)
class BrightnessManager {
    fun saveAutoBrightness(enabled: Boolean) {
        val prefs = context.getSharedPreferences("my_prefs", Context.MODE_PRIVATE)
        prefs.edit().putBoolean("auto_brightness", enabled).apply()
    }
}

// ✅ Pattern-matched implementation (matches existing code)
// After reading SettingsManager.kt and discovering:
// - Project uses singleton SettingsManager
// - Uses "is*Enabled" naming
// - Central SharedPreferences instance

object SettingsManager {
    // ... existing code ...

    var isAutoBrightnessEnabled: Boolean
        get() = prefs.getBoolean(KEY_AUTO_BRIGHTNESS, false)
        set(value) = prefs.edit().putBoolean(KEY_AUTO_BRIGHTNESS, value).apply()

    private const val KEY_AUTO_BRIGHTNESS = "is_auto_brightness_enabled"
}

┌─────────────────────────────────────────┐
│ Is the existing pattern DANGEROUS?     │
│ (security issue, crashes, data loss)   │
└─────────────────┬───────────────────────┘
                  │
        ┌─────────┴─────────┐
        │                   │
       YES                 NO
        │                   │
        v                   v
  ┌───────────┐      ┌────────────────┐
  │ STOP      │      │ Follow existing│
  │ Discuss   │      │ pattern        │
  │ with user │      └────────────────┘
  └───────────┘

Follow existing pattern if:
✓ Pattern is consistent across codebase
✓ Pattern works without bugs
✓ Changing it requires major refactoring
✓ Team is in "delivery mode" (agile sprint)

Propose improvements if:
✗ Pattern causes frequent bugs
✗ Pattern violates SOLID principles severely
✗ Better alternative requires < 5 file changes
✗ You're in "refactor mode" (tech debt sprint)

❌ BAD: Refactor entire settings system before adding toggle
Time: 2 weeks, Risk: High, Value: ?

✅ GOOD: Add toggle using existing pattern + note tech debt
Time: 1 hour, Risk: Low, Value: Feature shipped

✅ BETTER: Add toggle + improve pattern in that area only
Time: 2 hours, Risk: Low, Value: Feature + local improvement

// TODO(tech-debt): Settings stored in SharedPreferences directly.
// Consider migrating to DataStore for type safety and Flow support.
// Affects: SettingsManager.kt, ThemeController.kt, OledProtectionController.kt
object SettingsManager {
    var isOledProtectionEnabled: Boolean
        get() = prefs.getBoolean("is_oled_protection_enabled", false)
        set(value) = prefs.edit().putBoolean("is_oled_protection_enabled", value).apply()
}

## Technical Debt

- [ ] Migrate SharedPreferences to DataStore
  - Provides type safety
  - Supports Kotlin Flow for reactive updates
  - Affects ~8 files in settings package

// Just implement without research
class MinimalWidgetProvider : AppWidgetProvider() {
    override fun onUpdate(...) {
        // Generic implementation
    }
}

# Find existing widgets
ls app/src/main/kotlin/widget/

# Output:
# - WidgetClockBaseProvider.kt  ← Base class pattern!
# - WidgetClockClassicProvider.kt
# - WidgetClockGlassProvider.kt
# - WidgetClockSolidProvider.kt

// Read WidgetClockBaseProvider.kt
abstract class WidgetClockBaseProvider : AppWidgetProvider() {
    protected abstract fun getLayoutId(): Int
    protected abstract fun getWidgetStyle(): WidgetStyle
    // ... common logic ...
}

// Match the existing pattern exactly
class WidgetClockMinimalProvider : WidgetClockBaseProvider() {
    override fun getLayoutId() = R.layout.widget_minimal
    override fun getWidgetStyle() = WidgetStyle.MINIMAL
}

<!-- Just add colors without checking project style -->
<color name="accent">#FF5722</color>
<color name="accentDark">#E64A19</color>

# Check existing color naming
grep -r "color name=" app/src/main/res/values/colors.xml

# Find naming convention documentation
cat .agent/skills/color-tokens/SKILL.md

<!-- Discovered pattern from colors.xml -->
<color name="bg_primary_light">#FFFFFF</color>
<color name="bg_primary_dark">#000000</color>
<color name="text_primary_light">#000000</color>
<color name="text_primary_dark">#FFFFFF</color>

<!-- Follow discovered pattern -->
<color name="accent_primary_light">#FF5722</color>
<color name="accent_primary_dark">#E64A19</color>

### Pre-Implementation Checklist

- [ ] **Search for similar features**
  - [ ] Used Grep to find similar code
  - [ ] Used Glob to find similar files
  - [ ] Read at least 2 similar implementations

- [ ] **Read architectural docs**
  - [ ] Checked .agent/ARCHITECTURE.md
  - [ ] Checked .agent/AGENTS.md
  - [ ] Checked relevant skills/

- [ ] **Identify patterns**
  - [ ] Package structure convention
  - [ ] Naming conventions
  - [ ] Architectural patterns (MVC/MVVM/etc)
  - [ ] Resource naming patterns

- [ ] **Document findings**
  - [ ] Wrote down discovered patterns
  - [ ] Noted any LOCKED rules
  - [ ] Identified files to match

- [ ] **Plan implementation**
  - [ ] Implementation plan matches existing patterns
  - [ ] Will not require immediate refactoring
  - [ ] Follows project conventions exactly

### Only After Above: Proceed with Implementation

I found two different patterns for [feature] in the codebase:

Pattern A (used in FileX.kt, FileY.kt):
[code example]

Pattern B (used in FileZ.kt):
[code example]

Which pattern should I follow for this new feature?

Or should I refactor to unify these patterns first?

I discovered the existing [feature] pattern:
[code example]

This pattern works but has limitations:
- [limitation 1]
- [limitation 2]

I can:
1. Follow the existing pattern (fast, consistent, ships feature)
2. Improve the pattern locally (medium effort, better code)
3. Refactor all usages (slow, high risk, best quality)

In agile mode, I recommend Option 1 or 2. Which do you prefer?

20% - Pattern discovery (search, read, analyze)
10% - Planning (document findings, match patterns)
60% - Implementation (write code matching patterns)
10% - Verification (test, review consistency)