Tips and Tricks with Trails: How to Apply Path Filters
A Trail is Entire's alternative to the pull request. It puts confidence evals and coding sessions at the center of review, alongside all the context that created a diff. You can start a Trail before writing any code by asking your agent, running a terminal command, or using the web UI.
To customize your confidence evals, configure review agents to evaluate the changes in a Trail against instructions you set. For example, one review agent might check migration risk and another might check frontend code quality. Each returns findings or an evaluation score. When you push updates, review agents with matching triggers review the change again, and you follow their results on the Trail to decide whether the change is ready to merge.
In a monorepo, each review agent usually covers a different part of the codebase. Without path filters, fixing a one-line docs typo can trigger both your frontend reviewer and your migrations agent, as long as the change meets their other trigger conditions. When Entire has the complete file list, path filters skip those runs if no files in the current diff match the agent’s patterns.
This video shows how to open an agent’s configuration, add a pattern under Only when these paths change, and save it.
How Do I Filter an Entire Agent’s Runs by File Path?
Add a paths list of globs to your agent’s push trigger. With a complete changed-file list, the path filter matches when the current diff includes at least one file that matches a listed pattern.
We use this in our own repos. One of our frontend reviewer’s push triggers includes:
paths: ["frontend/**"]
A change confined to backend/ won’t match this filter, but a change that includes files in frontend/ will. Skipping those unrelated reviews saves runner time and cuts irrelevant verdicts.
Entire checks the full change from merge base to head. A later push that only changes docs still matches if an earlier frontend edit remains in the current diff. If that edit is fully reverted, it no longer counts as a match.
Select paths that match each agent’s scope:
| Agent | paths |
|---|---|
| Frontend reviewer | ["frontend/**"] |
| Migrations agent | ["db/**", "migrations/**"] |
| API agent | ["services/api/**"] |
Patterns within paths combine with OR: a match on any one pattern is enough, so the migrations agent’s filter matches files in either db/ or migrations/.
Can I Combine Path and Branch Filters?
Yes! Push triggers also accept a branches glob list. To review frontend changes on release branches, you can combine the filters:
paths: ["frontend/**"]
branches: ["release/*"]
Different filters combine with AND. With a complete changed-file list, the branch must match release/*, and the full change must include a file that matches frontend/**.
The trigger's readiness condition still applies on top of both filters.
FAQ
Does a path filter check only my latest push?
No. Entire checks the current diff from merge base to head, not just the latest push. A docs-only push still matches if an earlier edit to a filtered path remains in that diff. If that edit is fully reverted, it no longer counts as a match.
How many patterns need to match?
Just one! Patterns within paths combine with OR, so any single match satisfies the path filter. The branch filter and readiness condition still apply.
How do path and branch filters work together?
They combine with AND. With a complete changed-file list, the branch must match a branches pattern and the change must include a file that matches a paths pattern.
What happens if a review agent has no path filter?
Without a path filter, a review agent runs on every open change in its selected repos, as long as the change still meets its branch filter and readiness condition.
Can I exclude paths, like !docs/**?
No, negated patterns are not supported.
What glob syntax is supported?
Path patterns are repo-relative: * matches within one folder and ** across folders, so frontend/** matches anything under frontend/ and **/*.go matches every Go file.
What if the changed-file list is incomplete?
If the changed-file list is incomplete, the path filter allows the run even when none of the known files match. The branch filter and readiness condition still apply.
Do path filters apply to manual runs?
No, manual runs ignore both branch and path filters. Path filters only control when an agent runs automatically, such as on a push. To define what the agent reviews, use its instructions.
What’s Next?
Start with your busiest agent and take a peek at the changes behind some of its recent runs. If it keeps running on unrelated changes, add a path filter. When you create your next specialized reviewer, choose its paths while you’re writing its instructions. Let us know what you’re building or your thoughts on Discord!