rlm-mode

What this skill does

# RLM Mode Skill

You detect when users need large-scale operations that would benefit from recursive decomposition and route to RLM commands instead of attempting to load everything into context.

## Triggers

Alternate expressions and non-obvious activations (primary phrases are matched automatically from the skill description):

- "RLM" / "recursive language model" → explicit RLM mode activation
- "process in chunks" → chunk-based decomposition request
- "decompose and process" → explicit decomposition shorthand
- "fan out" → parallel fan-out processing across files or modules

## Core Problem

Loading entire codebases or directory trees into context causes:
- **Context window overflow**: Exceeding model limits
- **Degraded quality**: Agent struggles with too much information
- **Poor performance**: Slow processing, truncated responses
- **Memory exhaustion**: System crashes on large repos

**RLM solution**: Decompose → Process in chunks → Aggregate results

## Trigger Patterns Reference

| Pattern | Example | Why RLM? |
|---------|---------|----------|
| `analyze all files` | "analyze all TypeScript files for security issues" | Scope exceeds context window |
| `search the entire codebase` | "search the entire codebase for authentication logic" | Need to traverse full tree |
| `review every module` | "review every module for proper error handling" | Many independent reviews |
| `find all instances` | "find all instances of deprecated API usage" | Requires exhaustive search |
| `summarize the whole repository` | "summarize the whole repository structure" | Hierarchical decomposition |
| `check every file` | "check every file for missing tests" | File-by-file evaluation |
| `scan all directories` | "scan all directories for outdated dependencies" | Directory tree traversal |
| `across the entire project` | "find TODOs across the entire project" | Project-wide aggregation |
| `throughout the repository` | "identify duplicated code throughout the repository" | Cross-file comparison |
| `recursively process` | "recursively process src/ and generate docs" | Explicit recursion request |
| `batch process` | "batch process all markdown files for formatting" | Parallel batch operation |
| `apply to all` | "apply linting rules to all JavaScript files" | Bulk transformation |
| `update every` | "update every component to use new API" | Mass refactoring |
| `generate for each` | "generate tests for each module in lib/" | Templated generation |

## Detection Logic

### High Confidence (Auto-Suggest)

**Patterns that almost always need RLM**:

1. **Quantifiers**: "all", "every", "entire", "whole", "throughout"
2. **Scope words**: "codebase", "repository", "project-wide"
3. **Recursive terms**: "recursively", "nested", "hierarchical", "tree"
4. **Batch terms**: "batch", "bulk", "mass", "apply to multiple"

**Heuristics**:
- User mentions directory paths (`src/`, `lib/`, `test/`)
- User wants aggregated output ("list all", "summarize", "generate report")
- Task involves file count estimation >20 files
- User explicitly says "this might be a lot" or "there are many files"

### Medium Confidence (Suggest with Alternatives)

**Patterns that might need RLM**:

1. User asks about "multiple files" without quantity
2. User wants to "find patterns" without specifying scope
3. Task could be done with grep but user phrases it as analysis

**In these cases**: Ask user to clarify scope before recommending RLM

### Low Confidence (Don't Suggest)

**Patterns that DON'T need RLM**:

1. Single file operations: "analyze this file", "refactor login.ts"
2. Specific file list: "check auth.ts, user.ts, and session.ts"
3. Interactive exploration: "show me the auth module"
4. Already scoped: "in this directory" (with small directory)

## Decomposition Strategies

When RLM is appropriate, suggest the right strategy:

### Strategy 1: Recursive Query (`rlm-query`)

**Use when**: User wants to find, list, or aggregate information

**Example triggers**:
- "find all functions that use deprecated API"
- "list all files missing tests"
- "identify all TODO comments"
- "show me all error handling patterns"

**Suggested command**:
```
/rlm-query "{context-source}" "{query}" --depth {N}
```

The first positional argument is the context source — a single file path or glob pattern. The second is the sub-prompt for the spawned sub-agent.

**Example**:
```
User: "find all TODO comments across the entire codebase"

Decomposition:
  Context source: "**/*.{js,ts,jsx,tsx}" (all code files)
  Query: "Extract TODO comments with file:line locations"

Suggested: /rlm-query "**/*.{js,ts,jsx,tsx}" "Extract TODO comments with file:line locations"
```

### Strategy 2: Batch Processing (`rlm-batch`)

**Use when**: User wants to transform, update, or generate for multiple files

**Example triggers**:
- "update every component to use new prop types"
- "add JSDoc comments to all functions"
- "refactor all API calls to use new client"
- "generate tests for each module"

**Suggested command**:
```
/rlm-batch "{glob-pattern}" "{operation}" --max-parallel {N}
```

The first positional argument is the glob pattern that selects target files. The second is the operation applied to each file (use `{file}` as the placeholder for the current file path).

**Example**:
```
User: "add TypeScript types to every JavaScript file in src/"

Decomposition:
  Glob pattern: "src/**/*.js"
  Operation: "Add TypeScript type annotations to {file}"
  Max parallel: 4 (concurrent workers)

Suggested: /rlm-batch "src/**/*.js" "Add TypeScript type annotations to {file}" --max-parallel 4
```

### Strategy 3: Hierarchical Summary (`rlm-batch` with summarize aggregation)

**Use when**: User wants to understand large-scale structure or relationships

**Example triggers**:
- "summarize the entire repository structure"
- "explain the architecture of this codebase"
- "show me the dependency tree"
- "what are the main modules?"

**Suggested command**:
```
/rlm-batch "{glob-pattern}" "Summarize {file} for repository structure analysis" --aggregate summarize --max-parallel {N}
```

Pick a glob pattern that matches your repository layout. Common patterns:

- `**/README.md` — works for monolith *and* monorepo layouts (use a `.gitignore`-aware glob to avoid `node_modules/`)
- `apps/*/README.md` — multi-app monorepos
- `packages/*/README.md` — workspace-style monorepos
- `src/*/index.{ts,js}` — top-level module entry points

**Example**:
```
User: "summarize the whole repository so I can understand the architecture"

Decomposition:
  Glob pattern: "**/README.md" (adapt to your layout)
  Operation: "Summarize {file} for architecture overview"
  Max parallel: 3
  Aggregate: summarize (collapse all sub-summaries into one overview)

Suggested: /rlm-batch "**/README.md" "Summarize {file} for architecture overview" --aggregate summarize --max-parallel 3
```

## Response Templates

### When RLM is Clearly Needed

```
This request involves processing {N estimated} files, which exceeds comfortable
context window usage.

I recommend using RLM (Recursive Language Model) processing:

**Suggested approach:**
{command}

This will:
1. Decompose the task into manageable chunks
2. Process files independently (avoiding context overflow)
3. Aggregate results into a coherent summary

Would you like me to proceed with this RLM approach, or would you prefer a
different strategy?
```

### When Scope is Unclear

```
This could involve processing many files. To choose the right approach:

1. How many files are we talking about?
   - A few (1-5): I can handle directly
   - Several (5-20): Borderline, depends on size
   - Many (20+): RLM processing recommended

2. What's the scope?
   - Specific directory: {suggest path}
   - Whole repository: Definitely use RLM
   - Filtered by pattern: {suggest glob pattern}

Please clarify and I'll recommend the best approach.
```

### When User Insists on Direct Processing (Warning)

```
I can attempt to load {estimated files} directly, but I shou