We've watched dozens of teams onboard to Re-entry over the past two months. The ones who get value fastest all do the same things - and the ones who struggle usually miss one or two setup decisions that make everything else work.
This guide covers what to do in your first hour, your first week, and your first month to get the most out of the platform.
First Hour: Connect and Select
Connect GitHub or Bitbucket. This is the obvious first step, but there's a decision here that matters: which repositories to monitor.
Don't select everything. Start with 2-3 repositories that meet these criteria:
Active - at least a few PRs per week. Re-entry needs signal flow to learn.
Consequential - repos where a bad merge actually causes problems. Your documentation repo doesn't need governance.
Varied contributors - repos where multiple people push code. Single-contributor repos don't benefit from risk triage.
You can always add more repos later. Starting narrow gives you cleaner data and faster learning.
Watch the first assessments come in. Within minutes of connecting, Re-entry will start scoring open PRs. Look at the scores and ask yourself: does this match my intuition? A large PR touching authentication code should score higher than a README update. If the ordering feels wrong, that's useful - it tells you where to provide feedback once you've seen a few more.
First Week: Build the Feedback Loop
This is the most important week. Re-entry's deterministic scoring (file types, change size, branch targets, linked tickets) works immediately. But the system gets dramatically better when it learns from your team's actual outcomes.
Resolve assessments when PRs close. When a PR merges cleanly, Re-entry can learn "this type of change was safe." When a PR causes a revert or incident, it learns "this pattern is dangerous." The more outcomes you resolve, the faster prediction accuracy improves.
You need about 10 resolved outcomes before the accuracy metrics become meaningful. Most active teams hit this within the first week.
Use the feedback buttons. Every assessment has a thumbs-up/thumbs-down. If a PR scores 72 but you know it's routine, mark it as a false positive. If a small change scores 20 but touches something fragile, flag it as too low. This direct feedback accelerates calibration more than anything else.
Link your issue tracker. If your team uses Linear or Jira, Re-entry automatically detects ticket references in PR titles, descriptions, and branch names. A PR with a linked ticket scores lower than one without — it signals the change was planned and scoped. Make sure your team's branch naming or PR title conventions include the ticket ID.
First Month: Set Up Guards
Guards (formerly called policies) are where Re-entry moves from informing to acting. They're rules that trigger automated responses when conditions are met.
Start with one guard. Don't try to automate everything on day one. Pick the single most annoying recurring problem your team has:
PRs sitting open for days without review? → Guard: "If a PR has risk score above 50 and no reviewer assigned after 24 hours, auto-assign the team lead."
Risky changes going straight to main? → Guard: "If a PR targets main/master with risk above 70, require review before merge."
No ticket references? → Guard: "If a PR has no linked ticket and touches more than 5 files, add a label requesting ticket linkage."
You can define guards in natural language through the command bar. Type what you want to happen, and Re-entry compiles it into conditions and actions.
Autonomous vs. assisted vs. manual. Each guard has an autonomy level:
Manual - Re-entry detects the condition and notifies you, but takes no action. Good for learning what triggers.
Assisted - Re-entry recommends an action and asks for confirmation before executing. Good for building trust.
Autonomous - Re-entry executes the action immediately. Good for well-understood, low-risk responses.
Start every guard on manual or assisted. Move to autonomous only after you've seen it trigger correctly several times.
Daily Habits That Compound
The teams getting the most value treat Re-entry as their morning dashboard. Here's the 2-minute daily routine:
Open the live surface. Look at the risk summary in the sidebar. If everything is green, your team's code flow is healthy — move on with your day.
Check flagged PRs. If any PRs are scored high (orange or red), click to expand. Read the risk drivers. Decide if it needs your attention or if the score is expected.
Reassess if something changed. If a PR was updated since the last assessment (new commits pushed), hit Reassess to get a fresh score. The engine factors in the latest changes.
That's it. If nothing is risky, Re-entry should be invisible. This is by design — we built it to stay quiet on the happy path.
Advanced: Risk Intelligence Reports
Once you have 2-4 weeks of assessment data, generate a risk intelligence report from the sidebar.
The report tells you things you can't see from individual PRs:
Which files keep causing problems. The top risky files list shows files correlated with incidents and reverts. These are your "touch with care" files — consider adding guards specifically for changes to these paths.
Whether your risk detection is accurate. The prediction accuracy section shows precision and recall. If false positives are high, provide more feedback. If false negatives are high, your guards may need tighter thresholds.
How risk trends over time. A rising trend means your team is shipping riskier code (or the engine is getting better at detecting risk). A falling trend means things are stabilizing.
Who needs support. In named mode (opt-in, not anonymous), developer profiles show which contributors are consistently working in high-risk areas. This isn't about blame — it's about pairing, mentoring, and distributing risk-sensitive work.
Advanced: Deep Codebase Scanning
Beyond the passive intelligence report, you can run active scans:
Active Scan checks for unprotected default branches, stale PRs that have been open too long, and open PRs that haven't received a risk assessment yet. Think of it as a health check for your repositories.
Dependency Audit scans your package manifests (package.json, requirements.txt, go.mod) and cross-references against the GitHub Advisory Database. You get a severity breakdown and an AI-generated summary of findings.
Both run as background jobs — no CI changes needed. Results appear in the risk intelligence panel.
What Not to Do
Don't monitor every repo. More repos means more noise. Monitor what matters.
Don't set guards to autonomous on day one. Trust is earned. Start on manual, watch it work, then upgrade.
Don't ignore the feedback buttons. The engine can't learn from silence. Five minutes of feedback per week saves hours of false-positive triage.
Don't expect perfection on day one. Risk scoring is probabilistic. The first week will have false positives. By week four, the engine will know your codebase and your team's patterns well enough to be genuinely useful. The teams who push through the first week are the ones who never go back.
The Payoff
Here's what teams consistently report after 30 days:
Senior engineers spend less time on routine PR review because Re-entry triages what needs attention
High-risk changes get caught before merge instead of after production incidents
Institutional knowledge about "dangerous files" is captured in the system instead of living in one engineer's head
The team develops a shared language around risk - "this is a 70+ PR, let's pair on it" becomes natural
Re-entry.ai is built to be invisible when things are safe and loud when they're not. The goal is not more dashboards — it's fewer surprises.
Need help with setup? Reach us at info@re-entry.ai or use the command bar in the dashboard to ask questions directly.