Semantic Code Search Workflow

When triggered, prioritize the semantic-code-search MCP tools over built-in search mechanisms.

Provide context (paths, snippets, precise queries) to maximize accuracy.

When NOT to use:

• •You only need a simple string/filename lookup: use Grep/Glob.
• •You are reviewing uncommitted work or a feature branch and need the exact local state: use local repo tools.
• •You are doing purely mechanical pattern matching to drive a replace/edit: use Grep/Glob.
• •The current repo is not indexed (not present in list_indices): do not use semantic-code-search at all.

Important limitation:

• •The semantic index is a snapshot (typically of main). Use it to learn base-branch context and patterns. For PRs/branches, compare semantic (base) findings against your local branch diff for what actually changed.

Hard gate (required): repo must be indexed

• •Semantic code search is only valid for repos that exist in list_indices.
• •If the current repo is not represented by any available index, do not proceed with semantic code search. Fall back to local Grep/Glob/Read (and normal git comparisons).

Index usage:

• •If the user provides an index name, use it directly.
• •If the user does NOT provide an index name:
  • •Prefer list_indices and confirm the current repo is represented.
  • •If multiple indices could apply, pick the one that clearly matches the current repo's main branch.
  • •Only after that, you may omit index to rely on the MCP server's default, but do not assume the default points at the correct repo.
• •If a search returns no results or the index is not found in one MCP, try the other MCP before giving up.
• •Two MCP servers are available: scsi-main (shared/team indices) and scsi-local (user-specific indices).

Tool selection guidelines: