Pull Requests
Point Fabric at a pull request and it reads the diff through your connected repository, then keeps exactly what it read — so you can see what a review would be based on.
Fabric can read a pull request from a repository you have already connected, keep the diff it fetched, and then tell you what that change is missing test coverage for.
The reading and the reviewing are separate steps on purpose. A review that says a pull request is untested is only worth acting on if you can check what the reviewer actually saw — whether it had the whole change or half of it, the right commit or a stale one. So Fabric reads first, shows you the diff, and only reviews when you ask.
Where to find it. Project ▸ Testing ▸ Pull requests. The tab is part of the Testing feature and appears only when that feature is enabled for your deployment — if Testing is missing entirely, ask whoever administers your Fabric instance.
What you need first
One connected GitHub repository on the project. Fabric reads the pull request using the same credential the project is already connected with — there is nothing new to authorise and no second token to manage.
GitHub only for now. GitLab and Azure DevOps repositories are not readable yet. A project with only those connected shows a message saying so rather than an empty picker, and the repository selector lists GitHub repositories only.
If the repository's credential has expired or been revoked, the read is refused with "No usable credential for this repository". Reconnect it under Settings ▸ Repositories and try again.
Read a pull request
Open the Pull requests segment
Go to Project ▸ Testing and choose Pull requests in the segmented control.
Pick the repository and enter the number
Choose one of the project's connected GitHub repositories and type the pull request number — the number in its URL, not the branch name. If the project has exactly one GitHub repository, it is selected for you.
Press Read pull request
Fabric fetches the pull request's title, author, commit range and changed-file count, then its unified diff. The diff opens as soon as the read finishes.
Reading a pull request needs permission to edit the project's test cases. A member with read-only access sees the list of what has already been read, but no read control — because the read spends an API call against your organisation's credential, and that is not a read-only action.
What gets stored
For each read, Fabric keeps:
| Field | Why it's there |
|---|---|
| Repository, number, title, author | Identifies the pull request without another API call |
| Head and base commit | The exact commit range the diff covers |
| Changed-file count | Reported by GitHub, so it can be compared against the diff |
| The unified diff | The text any later review reasons over |
Nothing else. Fabric does not clone the repository, does not read files the pull request did not touch, and does not post anything back to GitHub.
Once you review it, the findings are stored against that read too — with the model that produced them, where a model was involved.
Re-reading the same commit replaces that read; a new commit is a new read. If you read pull request #42, the author pushes a fix, and you read it again, you get a second entry — because it is genuinely a different change. Reading the same commit twice updates the existing entry instead of adding a duplicate.
Very large pull requests are truncated, and say so
Fabric stores up to 400 KB of diff per read. A pull request that exceeds that — a lockfile refresh, a regenerated client, a bulk rename — is stored up to the limit and marked Partial diff in the list, with a banner above the diff itself.
A partial read is never presented as a complete one. The mark exists so that nothing built on this read can imply it saw the whole change. If you need full coverage of a very large pull request, split it — the same advice that makes it reviewable by a person.
If Fabric reads the pull request's details but GitHub does not return a diff, the entry is recorded as Diff unavailable with the reason, rather than as a review of an empty change. "There were no changes" and "we could not see the changes" are different facts, and the list distinguishes them.
It is recorded in the audit log
Three events are written to the audit log:
| Action | When |
|---|---|
project.pull_request.read | Fabric fetched a pull request — who asked, which repository, which commit, whether the diff was truncated |
project.pull_request.reviewed | A lens ran over a read pull request — how many findings survived, and how many were discarded as ungrounded |
project.pull_request.finding_judged | Someone accepted or dismissed a finding |
This is Fabric reaching out of your workspace with your own credential and pulling your source code in, so it is an event your security review can filter for. The audit entry records what was read — it never contains the diff itself or the credential.
Review it for test coverage
Open a read pull request and press Review for test coverage. Fabric puts the diff in front of a model alongside something a general-purpose reviewer does not have: your project's features, their acceptance criteria, and the titles of the test cases already linked to each one. The question it asks is narrow — what behaviour does this change introduce or alter that no existing case covers?
Each finding carries a severity, what a case for it would assert, and — where it applies — the file and line in the diff plus the acceptance criterion it concerns.
The review follows your project's testing depth. A Light project gets a lighter review — gaps in functional and acceptance-level coverage only, capped at four findings — because a lighter tier is a deliberate choice about scope, not an oversight for the review to correct. Standard adds integration and end-to-end gaps; Enterprise adds security, performance and accessibility where the change touches them. It reads the same Strategy & depth setting the test-case drafter reads, so one setting means one thing. See Testing settings.
"No coverage gaps found" is stated explicitly, with a timestamp. An empty list that could equally mean "not reviewed yet" is reassurance nobody earned, so the panel always says which of the two it is.
Findings are advisory. Fabric files nothing. Accept records that a gap is real without committing to a work item; Dismiss records that it is not worth acting on. Both are stored — dismissals are how the lens's own false-positive rate gets measured, so they are a judgement on the record rather than a way to hide a row.
Findings that cite something Fabric never saw are discarded
A model asked about a diff will sometimes name a file that is not in it, or an acceptance criterion the feature does not have. Fabric checks every finding against what it actually holds and throws away the ones that do not survive:
| Claim | What happens |
|---|---|
| A file path that is not in this change | The finding is dropped — it is about code the review never saw |
| A feature identifier that is not this project's | The feature link is removed; the observation is kept |
| A criterion beyond the end of that feature's criteria | The criterion reference is removed; the observation is kept |
| A line the change did not add | The line is removed; the file and the observation are kept |
This runs in Fabric's own code, not as an instruction in the prompt, so it holds even if your team rewrites the prompt in the Prompt Library. When findings are discarded you are told how many.
A very large change is reviewed in part. The model sees up to 200 KB of diff — less than the 400 KB Fabric stores — and is told when it is only looking at a portion, so it does not report the half it cannot see as untested. Most pull requests are nowhere near this: across 25 consecutive merged pull requests in Fabric's own repository the median diff was 16 KB and the largest 182 KB. What does exceed it is the mechanical change — a regenerated client, a lockfile refresh, a bulk rename — and those are worth splitting out of a reviewable change anyway.
Tune what the lens looks for
The prompt behind it is an editable binding: Prompt Library ▸ PR review — QA lens. Edit it to bias the review toward the gaps your team cares about. It cannot widen what the lens is allowed to cite — the discarding above is enforced regardless.
Check it for circular imports
Check circular imports answers a different question: does this change sit inside a cycle of files that import each other?
It reports three things, all computed: files that import each other in a cycle, a package importing another it does not declare as a dependency, and a library importing an application. This involves no AI at all. Fabric computes it from the import graph the Atlas analysis already built for your repository — the same graph the code map is drawn from. A cycle either exists in that graph or it does not, so there is nothing here to be confidently wrong about.
Only cycles your change is actually in are reported. A repository that has accumulated cycles elsewhere is a real problem, but it is not this pull request's finding, and attaching it here is how a review list becomes something people learn to skim past. When there are more cycles in the repository than in your change, Fabric tells you both numbers so you can see the difference.
Each finding names the files in the cycle, gives one concrete path round it (a → b → c → a), says which of them this change touches, and notes that breaking any single edge in that path is enough. Severity comes from size: two files importing each other is a local tangle, a larger knot is a module boundary that has stopped existing.
This needs an indexed repository. If Atlas has never analysed the project, Fabric says so rather than reporting "no problems found" — "we have never mapped your imports" and "your imports are fine" are different facts. Run an analysis from the Atlas tab first.
What this does not do yet
Being explicit, because the page name invites more than is here:
- No comments on GitHub. Nothing is posted back to the pull request.
- No automatic trigger. Reads and reviews happen when a person asks. Fabric does not register a webhook on your repository, so a new pull request does not review itself.
- No test cases created for you. A finding tells you what a case would assert; writing it is still a person's call, from the Cases segment.
- No project-specific architecture rules. The lens checks what your repository already states — circular imports, a package importing something it does not declare, and a library importing an application. It cannot check a convention nobody has written down, such as "this module should not reach into that one".
Either lens can be switched off per project — see Testing settings.
Next Steps
CI Test Results
Pull automated test results from GitHub Actions, GitLab CI, and Azure DevOps into Fabric, link them to your test cases, and see what broke without opening your CI dashboard.
Testing settings
Choose how much testing a project gets — how deep test cases go, whether Fabric drafts them at all, which environments runs target, and how often CI results are pulled in.