Oh-my-droid deepsearch

Exhaustive multi-strategy codebase search using grep, ripgrep, find, and AST-aware tracing to locate implementations, references, dependencies, and usage patterns for a given symbol, pattern, or concept. Use when you need to find every occurrence of a function, type, config key, or concept across a project — especially when simple text search misses indirect references, re-exports, or dynamic usage.

install

source · Clone the upstream repo

git clone https://github.com/MeroZemory/oh-my-droid

Claude Code · Install into ~/.claude/skills/

T=$(mktemp -d) && git clone --depth=1 https://github.com/MeroZemory/oh-my-droid "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/deepsearch" ~/.claude/skills/merozemory-oh-my-droid-deepsearch && rm -rf "$T"

manifest: skills/deepsearch/SKILL.md

source content

Deep Search

Objective

Perform an exhaustive, multi-pass search of the codebase for the specified query, pattern, or concept. Go beyond naive text matching by combining literal search, regex patterns, structural analysis, and dependency tracing to produce a complete map of where and how the target appears.

Phase 1 — Literal and Regex Search

Start broad. Run parallel searches to catch exact matches, variations, and related terms.

Exact identifier search

# Case-sensitive exact match across the project (ripgrep)
rg --word-regexp 'FunctionName' --type-add 'src:*.{ts,tsx,js,jsx,py,go,rs,java}' -t src -n

# If ripgrep is unavailable, fall back to grep
grep -rn --include='*.ts' --include='*.tsx' 'FunctionName' src/

Case-insensitive and partial matches

# Catch naming-convention variants (camelCase, snake_case, SCREAMING_CASE)
rg -in 'function.name|function_name|FUNCTION_NAME' --glob '!node_modules' --glob '!dist'

Regex pattern search

# Find all call sites, including method calls and chained usage
rg 'functionName\s*\(' -n --glob '*.{ts,tsx,js,jsx}'

# Find type annotations, generic usage, and interface references
rg ':\s*FunctionName[<\s,\)]' -n --glob '*.{ts,tsx}'

# Find decorators or annotations referencing the target
rg '@FunctionName|@.*FunctionName' -n

File and path search

# Find files whose name matches the concept
find . -type f \( -name '*function-name*' -o -name '*FunctionName*' \) -not -path '*/node_modules/*'

# Find config or manifest entries
rg 'function.name|functionName' -g '*.{json,yaml,yml,toml,ini,env}'

Phase 2 — Structural and Dependency Tracing

Move beyond text matching to understand the dependency graph around the target.

Import/export tracing

# Who imports this symbol?
rg "import.*FunctionName.*from" -n --glob '*.{ts,tsx,js,jsx}'
rg "from\s+['\"].*function-name['\"]" -n --glob '*.{ts,tsx,js,jsx}'

# Who re-exports it? (barrel files, index files)
rg "export.*FunctionName|export \* from.*function-name" -n --glob '*.{ts,tsx,js,jsx}'

# For Python
rg "from\s+\S+\s+import\s+.*FunctionName" -n --glob '*.py'

Reverse dependency walk

For each file that contains the target, ask: "What imports this file?"

# Extract the module path from the file, then search for imports of that path
rg "from ['\"].*modules/target-module['\"]" -n --glob '*.{ts,tsx,js,jsx}'

Dynamic and indirect references

# String-based lookups (config keys, event names, route paths)
rg "'function.name'|\"function.name\"|`function.name`" -n

# Object bracket access
rg "\[.*['\"]functionName['\"].*\]" -n

# Reflection, decorators, or registry patterns
rg "register\(.*functionName|resolve\(.*functionName" -n

Phase 3 — Contextual Deep Dive

Read the files identified in Phases 1 and 2 to understand context.

For each match cluster

Read the surrounding code (20-30 lines of context) to understand the role of the target at that location.
Check function signatures and type definitions to understand the contract.
Trace data flow: Where does the input come from? Where does the output go?
Identify test files: Search for test files covering the target.

# Find related test files
find . -type f \( -name '*FunctionName*test*' -o -name '*FunctionName*spec*' -o -name '*test*FunctionName*' \) -not -path '*/node_modules/*'

# Search test content for usage
rg 'FunctionName' --glob '*{test,spec}*.{ts,tsx,js,jsx,py}'

Framework-specific locations to check

React/Next.js:

components/

hooks/

pages/

app/

lib/

utils/

services/

store/

context/

Express/Fastify:
```
routes/
```
,
```
middleware/
```
,
```
controllers/
```
,
```
handlers/
```
Python/Django:
```
views/
```
,
```
models/
```
,
```
serializers/
```
,
```
urls.py
```
,
```
tasks/
```
Go: Check
```
cmd/
```
,
```
internal/
```
,
```
pkg/
```
, plus any
```
*_test.go
```
files

Config/infra:

.env*

docker-compose*

Dockerfile

*.yaml

*.toml

, CI workflow files

Phase 4 — Synthesize and Report

Output Format

Primary Locations — main implementations with file paths and line numbers
Related Files — dependencies, consumers, and re-exports
Usage Patterns — how the target is used across the codebase (called, extended, composed, configured)
Key Insights — naming conventions, patterns, unexpected coupling, gotchas, dead code

Cite every finding with

file:line

references. Group related findings together.

Completeness Checkpoint

Before reporting results, verify coverage:

Searched for exact name, aliases, and naming-convention variants (camelCase, snake_case, kebab-case)
Checked both source code and configuration files (JSON, YAML, TOML, env)
Traced imports forward (who uses it) and backward (what it depends on)
Searched for dynamic/string-based references (bracket access, registry lookups, event names)
Looked in test files for additional usage context
Checked framework-specific conventional directories
Confirmed no matches were missed in generated/build output directories (dist, build, .next)

If any checklist item is uncovered, go back and run the missing search before finalising the report.