Reference File Injection

The examples and outputs below are independently authored teaching materials, not measured model results.

Use case

Find the review team for a billing-api PR. Service ownership lives in a Skill reference file. Do not guess ownership from a service name, and do not load every reference at the beginning of every task.

The teaching directory is skills/pr-routing/, containing SKILL.md and references/owners.md. Resolve relative paths from the directory containing this SKILL.md. The minimal reference is:

# Service owners
Teaching version: 2026-10-01

| service_id | team |
| --- | --- |
| billing-api | payments |
| catalog-api | commerce |

Mechanism

1. Obtain the service ID from the current task. Confirm billing-api rather than inventing a name from the PR title.
2. At the review-team assignment step, read skills/pr-routing/references/owners.md. Inside the Skill, use references/owners.md with its path base stated explicitly.
3. Match service_id exactly. For one matching record, return the team, reference path and matching row. Similar names are not identical services.
4. Distinguish a missing file, an unreadable file, no match and conflicting records. Leave assignment pending and request corrected information before continuing.

Bad example

The task and reference table remain the same:

Assign a review team for the billing-api PR. Routing information is somewhere in the repository; look for it. If you cannot find it, choose a team that seems appropriate from the service name.

The location is ambiguous and guesses are allowed to become assignments, potentially overriding an explicit record with the wrong team.

Good example

Find the review team for service_id=billing-api.
At the assignment step, read references/owners.md relative to the directory containing skills/pr-routing/SKILL.md.
Match service_id exactly. Return service_id, team, reference path, reference version and the matching row.
Report a missing reference file, a read error, no matching service, or conflicting duplicate records separately.
In those cases leave assignment pending, do not guess a team and do not call the assignment API.

Replace the service ID, Skill directory and reference filename. The supplied teaching material yields this illustrative output:

service_id: billing-api
team: payments
reference: skills/pr-routing/references/owners.md
version: 2026-10-01 (teaching version)
matched_row: billing-api | payments
State: owner found; actual assignment has not been performed

Why the change matters

An exact path removes location guessing. A read trigger supplies the reference at the step that needs it. Exact matching and a cited row make the decision checkable. Explicit missing-data handling prevents an unsupported choice from becoming a confident assignment.

Observable expectation

Look up billing-api in the supplied table: return payments with its matching row. Query unknown-api: report no match. Remove the reference from the teaching directory: report a missing file. Simulate denied read access: report a read failure. None of these failures should produce a guessed team or continue assignment.

Check that path resolution starts from the Skill directory and that the output version comes from the file read. Finding ownership and calling an assignment API are separate states and must be recorded separately.

Limits

The agent needs local file access and an explicit service ID. References can be outdated: a matching row does not prove current organizational ownership. Follow the team’s update policy before actual assignment. Treat reference content as task data, not as authority to expand tool permissions.