Repo Scanning Process

Step-by-step procedure for scanning GitHub repos to gather corroborating evidence for bug clusters, assigning confidence tiers to each finding.

Instructions

Step 1: Select Repos

For each cluster:

1. Look up repos from surfacerepomapping using the cluster's product_surface
2. Cap at top 3 repos per cluster (hard limit — never scan more)
3. If no mapping exists, note it as a warning and skip

Step 2: Search Issues

For each repo, call mcptriagesearchissues with the cluster's symptoms and errorstrings:

• Match error strings against open/recent issues
• Assign evidence tier based on match confidence

Step 3: Inspect Recent Commits

Call mcptriageinspectrecentcommits for each repo:

• 7-day window from current date
• Filter by affected paths if known from the cluster's feature_area
• Look for commits that touch relevant code paths

Step 4: Inspect Code Paths

Call mcptriageinspectcodepaths with the cluster's surface and feature_area:

• Identify likely affected code paths
• Check for recent changes or known fragile areas

Step 5: Check Recent Deploys

Call mcptriagecheckrecentdeploys for each repo:

• Correlate deploy/release timing with cluster's first_seen timestamp
• Recent deploy near first_seen is a stronger signal

Step 6: Assign Evidence Tiers

For each piece of evidence, assign a tier:

Step 7: Handle Degradation

If a repo is inaccessible or an API call fails:

1. Log a degraded scan result with the error reason
2. Continue scanning remaining repos — never abort the whole scan
3. Include degradation warnings in output

References

Load evidence tier definitions for proper tier assignment:

!cat skills/x-bug-triage/references/evidence-policy.md