Project Integrity Bot reviews the Unity-specific failure modes general linters miss—meta/GUID problems, serialized reference breakage, Git LFS mistakes, and dependency drift—and points to the exact files involved.
Only policy-relevant changes are raised.
A quiet PR check that comments only on definite and high-confidence findings, with the evidence and repair path beside each one.
The first pilot uses the subset that matches your workflow. The rest stay out of the way until they earn their place.
Find missing, orphaned, duplicated, or unexpectedly regenerated Unity meta identifiers.
Inspect changed YAML for references that point to removed or unavailable project objects.
Catch large binaries committed directly, missing pointers, and tracked-file rule drift.
Review manifest and lockfile changes together and call out unresolved or surprising dependency movement.
Detect high-signal changes to scenes, prefabs, and project settings that deserve explicit review.
Every finding includes a path, reason, confidence level, and suggested next check.
The first pilot is an evaluation contract, not an open-ended integration. The evaluator decides whether one real workflow became clearer or faster.
Lead engineer, tools engineer, technical artist, or producer responsible for repository health.
One representative Git diff and the smallest .meta, YAML, package, and LFS context needed for the agreed rule set.
Exact-path findings with the rule, observable evidence, confidence, limitations, and a human-verifiable next check.
It catches a real historical fault or stays acceptably quiet on a risky PR without opening Unity solely to discover repository damage.
Once the contract above is confirmed, the first report is prepared within one week. No platform migration and no quarter-long rollout.
Name the evaluator, review point, safe input, exact output, transfer method, and success criterion.
Run a read-only analysis step in the current workflow or against the agreed sanitized sample, then produce the first report.
Run it against representative changes, tune noise, and decide whether the next scope is justified.
Generic tools understand Git and file formats, but not the relationships between Unity meta files, GUIDs, serialized objects, and package state. The pilot focuses on those engine-specific edges.
The default gate is deliberately conservative: definite and high-confidence findings only. Lower-confidence rules can be reported separately after the team decides they are useful.
A first check on one repository covering an agreed rule set, posting to your current pull-request surface. We validate it against representative historical failures before treating anything as a gate.
A conservative checklist for catching meta/GUID, serialized-reference, LFS, and package-state damage before a Unity branch lands.
Read the workflow checklist ↗Describe the recurring production problem and the smallest representative input you could evaluate. XeSoft will first confirm whether this narrow pilot is a fit—and say so plainly if it is not.
Prefer email? outreach@xesoft.dev
We will tell you what a useful one-week pilot can cover—and what it cannot.
Request a private pilot ↑