Mode Awareness Framework

When This Activates

This skill activates when:

• •Mode detection shows in <pattern-context> with low confidence
• •User explicitly asks to "switch to X mode"
• •Approach guidance is needed for a task type

Detected Modes

The system auto-detects these modes from your messages:

1. Debugging Mode

Signals: fix, broken, error, bug, issue, wrong, not working, fails, crash, exception

Approach:

• •Check recent changes first
• •Review error logs
• •Identify root cause BEFORE fixing
• •Don't change code until you understand the issue

Avoid:

• •Making changes without understanding
• •Multiple fixes at once (hard to isolate)

Tools: Error logs, git diff, debugger

2. Performance Mode

Signals: slow, fast, optimize, performance, speed, memory, cpu, latency, efficient

Approach:

• •Measure before changing
• •Profile to identify bottleneck
• •Document baseline metrics
• •Change one thing at a time

Avoid:

• •Premature optimization
• •Changing without measuring first
• •Optimizing non-bottlenecks

Tools: Profiler, time command, resource monitors

3. Feature Mode

Signals: add, create, implement, build, new, feature, want, need to

Approach:

• •Understand requirements fully
• •Check existing patterns in codebase
• •Plan before coding
• •Consider edge cases

Avoid:

• •Over-engineering
• •Skipping tests
• •Not checking for similar features

Tools: memory_query for similar features, project patterns

4. Refactor Mode

Signals: refactor, clean, reorganize, restructure, improve, simplify

Approach:

• •Ensure tests exist first
• •Make small incremental changes
• •Verify behavior unchanged after each step
• •Commit frequently

Avoid:

• •Changing behavior during refactor
• •Large changes without tests
• •Refactoring untested code

Tools: Test suite, git diff, code review

5. Exploration Mode

Signals: how, what, where, why, explain, understand, find, show, look

Approach:

• •Use memory query first (instant)
• •Check existing documentation
• •Explore systematically
• •Build mental model before acting

Avoid:

• •Modifying code while exploring
• •Making assumptions

Tools: memory_query, memory_search, Grep, Read

6. Infrastructure Mode

Signals: docker, deploy, server, database, config, setup, install, environment

Approach:

• •Check current state first
• •Document all changes
• •Test in isolation before applying
• •Have rollback plan

Avoid:

• •Making production changes without testing
• •Undocumented configuration
• •Assuming environment matches local

Tools: Docker, config files, environment variables

Mode Confidence

When mode is detected with low confidence (<0.5):

<pattern-context mode="exploration" confidence="0.33">

This means:

• •Multiple modes match equally
• •Signals are ambiguous
• •May need clarification

Response: Ask which approach the user wants: "I could approach this as exploration (understanding the code) or as a feature (implementing something). Which would you prefer?"

Mode Switching

Users can explicitly switch:

• •"Let's switch to debugging mode"
• •"I want to explore first"
• •"Time to refactor this"

When switching, acknowledge and adjust: "Switching to debugging mode. Let me check what changed recently and look at the error logs."

Multi-Mode Tasks

Some tasks span modes:

1. •Explore → understand the issue
2. •Debug → find root cause
3. •Feature → implement fix
4. •Refactor → clean up after

It's okay to move through modes naturally. The key is being intentional about which mode you're in.

Mode-Specific Memory Queries

Each mode benefits from different queries: