searching-sourcegraph（搜索源图）

Searching Sourcegraph

Search before you build. Existing patterns reduce tokens, ensure consistency, and surface tested solutions.

Tool Selection Logic

Start here:

1. Know the exact symbol or pattern? → keyword_search
2. Know the concept, not the code? → nls_search
3. Need to understand how/why? → deepsearch → deepsearch_read
4. Tracing a symbol's usage? → find_references
5. Need full implementation? → go_to_definition → read_file
6. Need to know what repos a user has worked on? → get_contributor_repos

Scoping (Always Do This)

repo:^github.com/ORG/REPO$           # Exact repo (preferred)
repo:github.com/ORG/                 # All repos in org
file:.*\.ts$                         # TypeScript only
file:src/api/                        # Specific directory
file:.*\.test\.ts$ -file:__mocks__   # Tests, exclude mocks

Start narrow. Expand only if results are empty.

Combine filters: repo:^github.com/myorg/backend$ file:src/handlers lang:typescript

Context-Aware Behaviour

When the user provides a file path or error message:

• Extract symbols, function names, or error codes
• Search for those exact terms first
• Trace references if the error involves a known symbol

When the user asks "how does X work":

• Use deepsearch to initiate the search, then deepsearch_read to retrieve results
• Follow up with read_file on key files mentioned in the response

When the user asks who worked on something or what repos a contributor has touched:

• Use get_contributor_repos with one or more usernames to discover their active repositories
• Then scope subsequent searches to those repos

When the user is implementing a new feature:

• Search for similar existing implementations first
• Read tests for usage examples
• Check for shared utilities before creating new ones

When troubleshooting an error, build failure, or runtime exception:

• Extract exact symbols, error codes, or log lines from the stack trace or build output
• Search for the error site, then trace the full call chain with find_references
• Check recent changes with diff_search and commit_search early — regressions are common
• Identify all affected code paths and services before proposing a fix

When fixing a bug:

• Extract exact symbols from the error message or stack trace
• Search for the error site, then trace the full call chain with find_references
• Check recent changes with diff_search and commit_search early — regressions are common
• Find all affected code paths before writing the fix
• Read existing tests to understand intended behaviour

Workflows

For detailed step-by-step workflows, see:

• workflows/implementing-feature.md — when building new features
• workflows/understanding-code.md — when exploring unfamiliar systems
• workflows/debugging-issue.md — when troubleshooting errors, build failures, stack traces, support issues, or runtime exceptions
• workflows/fixing-bug.md — when fixing bugs with extensive Sourcegraph search
• workflows/code-review.md — when reviewing a pull request or changeset

Efficiency Rules

Minimise tool calls:

• Chain searches logically: search → read → references → definition
• Don't re-search for the same pattern; use results from prior calls
• Prefer keyword_search over nls_search when you have exact terms (faster, more precise)

Batch your understanding:

• Read 2-3 related files before synthesising, rather than reading one and asking questions
• Use deepsearch + deepsearch_read for "how does X work" instead of multiple keyword searches

Avoid common token waste:

• Don't search all repos when you know the target repo
• Don't use deepsearch for simple "find all" queries — keyword_search is faster
• Don't re-read files you've already seen in this conversation

Query Patterns

For more patterns, see query-patterns.md.

Output Formatting

Search results:

• Present as a brief summary, not raw tool output
• Highlight the most relevant file and line
• Include a code snippet only if it directly answers the question

Code explanations:

• Start with a one-sentence summary
• Use the codebase's own terminology
• Reference specific files and functions

Recommendations:

• Present as numbered steps if actionable
• Link to specific patterns found in the codebase
• Note any existing utilities that should be reused

Common Mistakes

Principles

• Start narrow, expand if needed
• Chain tools: search → read → find references → definition
• Check tests for usage examples
• Read before generating