ADO Code Search

Search Azure DevOps code repositories and return filtered, relevant results.

CRITICAL: How To Execute This Skill

This skill uses exactly TWO tool calls. No Bash. No scripts.

Step 1: Load the MCP tool

code

ToolSearch:
  query: "+azure-devops search_code"

Step 2: Call the MCP tool directly

code

mcp__azure-devops__search_code:
  searchText: "your search query"
  repository: ["repo-name"]  # MUST be array, not string
  top: 25

CRITICAL: repository parameter MUST be an array of strings, even for single repo.

Examples:

•✅ repository: ["clinical-matching-workflow"]
•❌ repository: "clinical-matching-workflow"

That's it. Two tool calls. Both are TOOL CALLS, not Bash commands.

WRONG (do not do these):

•Bash(mcp__azure-devops__search_code ...) - MCP tools are NOT bash commands
•Bash(./scripts/...) - There are NO scripts in this skill
•Bash(cd ... && ...) - No Bash at all

Input Format

REQUIRED: You MUST specify a repository. Unscoped searches will hang and fill context.

code

{project}/{repo}:{search_query} | {research context}

Examples:

•Platform Engineering/clinical-matching-service:retry_policy | understanding how retries are configured
•DataPlatform/etl-framework:ConnectionString | finding where connection strings are used
•Platform Engineering/worker-service:def handle_error | reviewing error handling patterns

If user doesn't specify a repo: ASK which repository to search. Do NOT run unscoped searches.

Instructions

•Load tool - Call ToolSearch with query +azure-devops search_code
•Parse input - Extract project, repository, search query, and research context
•VALIDATE SCOPE - If no repository was specified, STOP and return error: "Repository required. Please specify which repo to search (e.g., 'Platform Engineering/my-repo:query')"
•
Execute search - Call mcp__azure-devops__search_code with:
- •searchText: the search query
- •repository: ["repo-name"] as ARRAY
- •project: ["project-name"] as ARRAY (optional but recommended)
- •top: 25 (limit results)
•
Handle errors gracefully:
- •If 400 Bad Request: query may be malformed, try simpler search text
- •If timeout: scope is too broad, ask user to narrow to specific repo
- •If validation error: check all array parameters are arrays, not strings
•Filter by relevance - Only include results relevant to the research context
•Summarize results - Return top matches with file paths and snippets
•Rate relevance - Assess how well results answer the research question

CRITICAL: Step 3 is a HARD STOP. Never proceed without a specific repository.

CRITICAL: All filter parameters (repository, project, path, branch) MUST be arrays, not strings.

Output Format

code

SEARCH: "{query}"
PROJECT: {project or "all projects"}
RESULTS: {total_count} matches across {repo_count} repos

RELEVANT FILES:
1. {project}/{repo}/{path}:{line}
   `{code snippet - max 100 chars}`
   Why relevant: {brief explanation}

2. {project}/{repo}/{path}:{line}
   `{code snippet - max 100 chars}`
   Why relevant: {brief explanation}

[Continue for top 5-10 most relevant results]

PATTERNS OBSERVED:
- {pattern 1 across results}
- {pattern 2 across results}

---
RESEARCH CONTEXT: {echoed from input}

RELEVANCE: high|medium|low - {explanation}

SUGGESTED FOLLOW-UP:
- {refined search if needed}
- {specific file to read}

Rules

•Filter aggressively - Don't dump all results, only what's relevant to research context
•~1000 tokens max - Be concise, this feeds back to main context
•Include paths - User needs file paths to navigate to code
•Truncate snippets - Max 100 chars per snippet, show the relevant part
•Group patterns - If multiple files show same pattern, summarize instead of listing all
•Note scope - If search was project-scoped, mention it clearly
•Suggest refinements - If results are too broad/narrow, suggest better queries

Example Output

code

SEARCH: "retry_policy"
PROJECT: all projects
RESULTS: 23 matches across 5 repos

RELEVANT FILES:
1. Platform Engineering/clinical-matching-service/src/worker/config.py:42
   `retry_policy = RetryPolicy(max_attempts=3, backoff_multiplier=2)`
   Why relevant: Defines retry configuration

2. Platform Engineering/clinical-matching-service/src/worker/handler.py:15
   `@retry_policy.wrap`
   Why relevant: Shows how retry policy is applied

3. DataPlatform/etl-framework/lib/resilience.py:88
   `class RetryPolicy: """Configurable retry with exponential backoff"""`
   Why relevant: Base class definition

4. DataPlatform/etl-framework/tests/test_resilience.py:120
   `def test_retry_policy_respects_max_attempts():`
   Why relevant: Shows expected behavior

PATTERNS OBSERVED:
- RetryPolicy class from etl-framework is the common implementation
- Most services use max_attempts=3 with exponential backoff
- Retry logic is applied via decorator pattern

---
RESEARCH CONTEXT: understanding how retries are configured

RELEVANCE: high - Found both configuration and implementation patterns

SUGGESTED FOLLOW-UP:
- Read `DataPlatform/etl-framework/lib/resilience.py` for full RetryPolicy implementation
- Search `backoff_multiplier` to find different retry timings

Handling Large Result Sets

If search returns many results:

•Prioritize by research context - Only include files that answer the research question
•Group similar files - "Found in 8 test files" instead of listing all 8
•Note omissions - "12 additional matches in test files (omitted)"
•Suggest scoping - If too broad, suggest adding project filter or refining query

Handling No Results

If search returns no results:

code

SEARCH: "{query}"
RESULTS: 0 matches

No code found matching "{query}".

SUGGESTIONS:
- Try broader search: "{alternative query}"
- Check spelling/casing
- Search specific project if you know where code lives