메뉴
Use any time a branch, tag, or version in the user's question is ambiguous or unspecified - whether at the start of a question or mid-conversation (e.g. when comparing behavior across versions).
기본적으로 소스를 먼저 확인하는 Prompt가 선택됩니다. 직접 명령으로 전환하거나 로컬 사본을 다운로드할 수도 있습니다.
설치 여부를 결정하기 전에 SKILL.md와 SkillsMP에 표시된 보조 파일을 읽어 보세요.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
직접 명령은 검토 Prompt를 거치지 않습니다. 실행하기 전에 소스를 확인하세요.
npx skills add https://github.com/elastic/sourcerer --skill ref-resolution명령은 한 줄로 유지됩니다. 복사하기 전에 가로로 스크롤해 전체 내용을 확인하세요.
로컬 사본을 원하시나요? SkillsMP에서 현재 제공할 수 있는 파일을 다운로드하세요.
SKILL.md 표시 중
| name | ref-resolution |
| description | Use any time a branch, tag, or version in the user's question is ambiguous or unspecified - whether at the start of a question or mid-conversation (e.g. when comparing behavior across versions). |
Apply whenever a ref is ambiguous or unspecified. This includes:
Use sourcerer.refs.list to explore available refs. It accepts wildcards on git_ref:
git_ref: v8.* - all refs starting with "v8."git_ref: v8.17.* - all 8.17.x tagsgit_ref: main - exact branch matchCombine with git_ref_type: tag, git_ref_type: branch, or git_ref_type: commit (a pinned,
ad-hoc commit not on a tracked branch/tag tip) to narrow further.
refs.list with git_ref_type: tag for the repo.-rc, -beta, -alpha, -SNAPSHOT, -M1). A pre-release sorts below its final release (v9.0.0 > v9.0.0-rc1).indexed_at DESC order equals semver order ().v9.0.0 > v8.14.3 > v8.2.0status is complete (the status field surfaced by repo-discovery). If the very latest tag is still indexing (status indexing), drop to the next-highest complete tag, or proceed but tell the user that release is only partially indexed.main, master, trunk). If only pre-release tags exist, resolve to the highest pre-release and say so explicitly.Disambiguate based on context:
refs.list with git_ref: v8.* and git_ref_type: tag, then pick the highest stable patch.Resolve each ref independently using the steps above. Run content queries against each resolved ref (see "Pinning the ref" below), then compare results. Label each finding with its version.
Use as given. If it is a branch, call refs.list with git_ref_type: branch to confirm it exists and retrieve its row. If it is a tag, confirm it the same way. If it is a commit hash, you don't need a refs.list call to use it in a content query (a commit hash is already a valid git_commit_ish value) - optionally confirm with git_ref_type: commit if it may be a pinned commit rather than one reached via a branch/tag.
When a branch was indexed with since (history walk), multiple snapshots of the branch exist —
one per historical commit. Resolve "branch as of date D" like this:
refs.list with git_ref_type: branch and git_ref: <branch>.commit_date <= D and status: complete.commit_date among those (the branch state at the closest point on or before D).If only one marker exists for the branch (tip-only indexing, no since), state that historical
snapshots are unavailable for that branch.
Every content query (sourcerer.code.* and sourcerer.files.*) takes the same scoping param,
git_commit_ish: a commit SHA, or a branch/tag name (* and ? wildcards are supported). The
tool matches it against whichever field the content actually carries (git.commit for a
snapshot source, git.ref for an incremental branch) and then joins to resolve the citable
commit -- there is no mode you need to reason about, and no separate commit param to supply.
The param is optional (default "*", matching every indexed ref), but for a version-specific
question you should still resolve and pin a ref: an unpinned "*" query returns matches from
every ref at once, which blends versions. Results stay attributable (each row carries its
git.commit), so "*" is fine for "does this symbol exist anywhere" style questions -- just not
for "how does X behave in 8.17".
Once a ref is resolved above, pass the value straight through:
git_commit_ish.update: incremental in
sourcerer.yml; its refs.list row has status: complete, same as a snapshot ref): use the branch name
itself as git_commit_ish (e.g. main) -- no commit needed, the query always resolves to whatever
commit that branch is CURRENTLY at.Internally, each tool uses a FORK that branches on content-doc shape to resolve the citable commit:
snapshot-shaped rows already carry git.commit (no join needed), while incremental-shaped rows get
their git.commit resolved via a LOOKUP JOIN on (git.host, git.org, git.repo, git.ref).
Read the resolved git.commit back from each result row (the content query's own join supplies
it) for citations. Because incremental content overwrites in place, a branch query always returns
its current HEAD -- if you need to confirm a branch hasn't advanced since you resolved it (e.g. a
long-running investigation), re-check sourcerer.refs.list for its current commit. Re-invoke this
skill only when the question introduces a new or additional ref.