
Description
Use at the start of most questions to identify which repos are indexed before querying content. Also use mid-conversation when an answer may require expanding into a related or upstream repo (e.g. tracing from an application repo into a lower-level dependency).
SKILL.md
When this applies
- At the start of a question: confirm which repos are indexed and plan where to look before issuing any content queries.
- Mid-investigation: when the trail leads into a dependency, upstream library, or sibling repo - expand scope before drawing conclusions.
- When a dependency boundary is reached: if the current repo's code delegates to an external dependency (e.g., an import resolves outside the repo, behavior is implemented in an upstream library), always check whether that dependency is indexed before concluding the answer can't be found. Never assume a dependency is unindexed without checking.
Tool
Use sourcerer.refs.list with wildcard git_repo and git_org patterns. Each result row is one indexed ref; the distinct git.repo values in the results are the repos available to query.
Progressive disclosure - narrow first, expand only as needed
Start with the most specific pattern likely to match the question. Broaden only if the result is empty or you need more coverage.
| Scenario | Example call |
|---|---|
| Specific repo, confident | git_org: elastic, git_repo: elasticsearch |
| Repo family in one org | git_org: elastic, git_repo: elasticsearch* |
| All repos in one org | git_org: elastic, git_repo: * |
| Different org or upstream | git_org: apache, git_repo: lucene* |
| Cross-org fallback (expensive) | git_repo: * (no org filter) |
Avoid git_repo: * without an org filter unless you genuinely need all orgs - it returns every indexed ref and consumes many tokens.
Interpreting results
From the result rows:
- Distinct
git.repovalues - the repos available to query. git.ref_type- whether each repo has branches, tags, or both. Useful for knowing whetherref-resolutionwill find tags or needs to fall back to a branch.status- a ref with status other thanreadymay have incomplete content.
Example: expanding scope mid-conversation
A question about Elasticsearch's query parsing leads into how Lucene's QueryParser works underneath:
- Initial discovery:
refs.list(git_org: elastic, git_repo: elasticsearch)- confirm the repo and plan the search. - Answer the Elasticsearch side. When the trail leads to Lucene, expand:
refs.list(git_org: apache, git_repo: lucene*)- discover which Lucene repos are indexed.- Use
ref-resolutionon the relevant Lucene repo to pin a commit, then query content.
Each discovery call should be targeted - retrieve only what you need to plan the next step.
More skills from the sourcerer repository
View all 4 skillsMore from Elastic
View publisheraccessing-benchmark-results
retrieve and analyze Rally benchmark results
rally
Jul 12AnalyticsData AnalysisElasticPerformancedeveloping-rally
develop and debug Rally source code
rally
Jul 12DebuggingElasticEngineeringLocal Developmentrunning-benchmarks
run Rally benchmarks against Elasticsearch
rally
Jul 12ElasticElasticsearchPerformanceTestingcloud-access-management
manage Elastic Cloud organization access
agent-skills
Jul 12CloudElasticOperationsPermissionscloud-create-project
create Elastic Cloud Serverless projects
agent-skills
Jul 12CloudDeploymentElasticsearchcloud-manage-project
manage Elastic Cloud Serverless projects
agent-skills
Jul 12CloudElasticsearchOperations