Run a read-only PRI scan to baseline repository reliability

Before introducing AI coding tools, establish what reliability weaknesses already exist in the repository. Otherwise, a later finding can be hard to interpret: was it present before the tools arrived, or did a recent change introduce it?

Tomosu AI offers a read-only GitHub repository scan that calculates a Production Reliability Index (PRI). The report gives an initial baseline without changing source code. Here is a practical way to run the scan and make its results useful to an engineering team.

1. Choose the repository and the moment

Pick the repository you want to baseline, then choose a point in its development history that your team can identify. For example, scan before enabling an AI coding tool for a team or before a major round of code generation. The point is not to find a perfectly quiet moment; it is to record what you scanned and when, so future findings have context.

If you are starting with Tomosu, its repository scan is available at tomosu.ai/start. Tomosu says it can scan public and private GitHub repositories and describes the report as read-only. Treat the result as an assessment of the repository at the time of the scan, not as a guarantee about every future change or production outcome.

2. Run the read-only scan

Start a repository scan and provide the GitHub repository you want assessed. Follow the access steps presented for that repository. The product facts available here do not specify the exact authorization prompts or required permissions, so check those details in the flow before proceeding, especially for a private repository.

Keep the scope narrow for the first pass: one repository, one agreed baseline moment. Avoid changing code or merging unrelated changes during the scan if you want a cleaner reference point. The scan is intended to return a report, not to make a code change on your behalf.

3. Read the PRI as a summary, not the whole diagnosis

Tomosu calculates a Production Reliability Index across seven sub-indexes. Start with the overall PRI to orient the discussion, then inspect the sub-indexes and the findings by category. A single summary number can help teams talk about a repository consistently, but it cannot explain which weakness matters most in a specific service. The supporting findings are where you can decide what deserves investigation.

Separate observations from decisions. A finding is a reason to inspect code and context; it is not automatically a ticket, a release blocker, or evidence of a production incident. Ask the relevant maintainers whether the reported weakness applies to the way the service is built and operated. If the scan surfaces several gaps, prioritize them against your own reliability goals and operational knowledge rather than treating the report as a complete roadmap.

4. Preserve enough context to compare later

Put the result in the place your team already uses for engineering baselines. Record the repository, scan date, code revision, overall PRI, sub-index results, and the findings you plan to revisit. The code revision matters: a score without a clear reference point is difficult to compare with a later assessment. If the report does not make a detail easy to capture, record it separately rather than assuming it will be available later.

Do not assume that recording a baseline means Tomosu will automatically preserve or compare every scan. The useful practice is to keep a team-owned record and use the same repository and comparable scope when you assess again. That gives reviewers a basis for asking whether a change altered the reliability picture, while leaving room to investigate differences rather than attributing them to AI tools by default.

5. Use the baseline before expanding the workflow

Once the initial scan is documented, use it to set expectations before enabling AI-generated changes. For example, identify existing findings that should not be mistaken for regressions, and agree how engineers will evaluate newly reported weaknesses. Then run a later assessment at a meaningful point in your rollout and compare the evidence against the original record.

A repository baseline is most useful when it leads to a decision: which existing weaknesses need attention, what should count as a meaningful change, and who will review the results? Avoid turning the PRI into an unsupported pass/fail threshold. The score is one input to governance, not a substitute for code review, service context, or operational judgment.

For teams preparing older systems for new model-driven features, the same principle applies: establish what is already fragile before interpreting new changes. This guide to preparing a legacy codebase discusses why a reliability baseline and focused architecture review belong together.

What the first scan can and cannot tell you

A Tomosu read-only PRI scan gives a structured starting point: one repository-level index, seven sub-indexes, and categorized findings. It does not, by itself, prove that a repository is safe to change or that a later score shift was caused by AI coding. The baseline becomes valuable when the team preserves its scope and revision, reviews the underlying findings, and uses the result to make explicit decisions before adoption.