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.
Best use case
deepsearch is best used when you need a repeatable AI agent workflow instead of a one-off prompt.
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.
Teams using deepsearch should expect a more consistent output, faster repeated execution, less prompt rewriting.
When to use this skill
- You want a reusable workflow that can be run more than once with consistent structure.
When not to use this skill
- You only need a quick one-off answer and do not need a reusable workflow.
- You cannot install or maintain the underlying files, dependencies, or repository context.
Installation
Claude Code / Cursor / Codex
Manual Installation
- Download SKILL.md from GitHub
- Place it in
.claude/skills/deepsearch/SKILL.mdinside your project - Restart your AI agent — it will auto-discover the skill
How deepsearch Compares
| Feature / Agent | deepsearch | Standard Approach |
|---|---|---|
| Platform Support | Not specified | Limited / Varies |
| Context Awareness | High | Baseline |
| Installation Complexity | Unknown | N/A |
Frequently Asked Questions
What does this skill do?
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.
Where can I find the source code?
You can find the source code on GitHub using the link provided at the top of the page.
SKILL.md Source
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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
```bash
# 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?"
```bash
# 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
```bash
# 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
1. **Read the surrounding code** (20-30 lines of context) to understand the role of the target at that location.
2. **Check function signatures and type definitions** to understand the contract.
3. **Trace data flow**: Where does the input come from? Where does the output go?
4. **Identify test files**: Search for test files covering the target.
```bash
# 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.