Only policy-relevant changes are raised.
Stop Unity project integrity failures before merge.
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.
- FIRST SCOPE
- One repository / target
- FIRST RESULT
- Within one week
- DEPLOYMENT
- Your existing CI
A quiet PR check that comments only on definite and high-confidence findings, with the evidence and repair path beside each one.
The signals worth stopping for.
The first pilot uses the subset that matches your workflow. The rest stay out of the way until they earn their place.
Meta & GUID integrity
Find missing, orphaned, duplicated, or unexpectedly regenerated Unity meta identifiers.
Serialized references
Inspect changed YAML for references that point to removed or unavailable project objects.
Git LFS enforcement
Catch large binaries committed directly, missing pointers, and tracked-file rule drift.
Package consistency
Review manifest and lockfile changes together and call out unresolved or surprising dependency movement.
Merge-risk patterns
Detect high-signal changes to scenes, prefabs, and project settings that deserve explicit review.
Actionable evidence
Every finding includes a path, reason, confidence level, and suggested next check.
A narrow pilot, built around your real pipeline.
No platform migration and no quarter-long rollout. We start with one decision your team currently has to make without enough evidence.
Choose the review point
Agree on one repository, target, baseline, CI job, and the signals that should be visible.
Connect the artifacts
Wire a read-only analysis step into the current workflow and produce an example report.
Review the evidence
Run it against representative changes, tune noise, and decide whether the next scope is justified.
Why not use a generic repository linter?+
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.
Will this flood every PR with warnings?+
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.
What can be ready in one week?+
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.
Bring us the workflow
you cannot see clearly.
We will tell you what a useful one-week pilot can cover—and what it cannot.
outreach@xesoft.dev ↗