45 HIGH
(11.2 ÷ 25) × 100 = 44.8 → 45
≥70 critical · ≥45 high · ≥25 medium · below 25 low. Only factors above low appear in the comment.
RigelProductImpact
Know the blast radius before you merge.
See which services a change touches, what it could break and why it scored the way it did, before anyone clicks merge.
Off by default: turn it on per repo, or request it on a single PR. Works on any PR in an enabled repo, whoever or whatever opened it.
# orders-api · PR comment · Illustration Rigel Impact Analysis 45 HIGH Affected services in this repo (3) orders-api directly changed fulfillment depends on orders-api notifications depends on fulfillment Why this scored high ▲ Service scope 1 changed, 3 affected ▲ Cross-service shared DB → fulfillment ▲ Migrations 1 in orders-api ▲ API changes 2 endpoints Impact chain orders-api → fulfillment → notifications
Consumers in other repos: Coming soon in this comment; your agents can ask today with find_consumers.
Blast radius
A risk score you can read.
Eight weighted factors, one 0–100 score. A transparent heuristic, not an ML model. Try it.
Services affected · Cross-service impact · Database migrations · API changes
Severity values: low 0.1 · medium 0.4 · high 0.7 · critical 1.0. Total weight 25.
Rigel classifies every changed file, maps it to a service and walks the dependency graph to find what's affected downstream. A migration in a service that shares its database is flagged breaking for every service that shares it.
| Factor | Weight | This PR | What sets each severity |
|---|---|---|---|
| Services affected Changes that reach many services, directly or transitively. | ×3 | HIGH | ≥5 affected critical · ≥3 high · ≥2 directly changed medium |
| Cross-service impact Hits another service's API contract, shared library or shared database. | ×4 | CRIT | any breaking critical · ≥3 warnings high · ≥1 warning medium |
| Database migrations Migration files and ORM schema changes. | ×4 | HIGH | ≥3 migrations critical · any migration or ORM schema file high |
| Destructive schema changes Deleted schema files, or schema and migration files with net line deletions. | ×5 | LOW | deleted schema file, or ≥2 schema/migration files with net deletions critical · 1 high |
| API changes Endpoints added, changed or removed. | ×3 | MED | ≥5 endpoints high · ≥1 medium |
| Change volume Large numbers of source files or lines. | ×2 | LOW | ≥20 source files or ≥1000 lines high · ≥10 / ≥500 medium |
| Config and CI changes CI files and configuration. | ×2 | LOW | any CI file, or ≥3 config files medium |
| File deletions Files removed. | ×2 | LOW | ≥5 high · ≥2 medium |
# Score a branch against its base locally rigel pr-analyze main feature/split-order-totals
A local structural score from manifests and file classes. The full analysis, with API and contract factors, runs on your Rigel server. No model is called at review time. The rigel CLI name is shown for the upcoming release.
Mechanism in depth: how the risk score is computed →
Beyond the repo
Find consumers in other repos first.
A changed package in repo A can break a consumer in repo D. Rigel searches every other onboarded repo, and your agents can ask before they edit.
# repo A · orders-api — changed in this PR @your-org/orders-client + accountId − customerId # consumers found in other repos repo C · fulfillment fulfillment-service ⚠ warning · package repo D · billing billing-worker ⚠ warning · package repo · shipping no match
Services in other repos that declare the changed package, read from package.json.
Services whose recorded HTTP channels or queues match the changed route or topic.
Plus a dedicated Cross-Repo Impact screen.
Available to agents via MCP today
Your coding agents call find_consumers and cross_repo_impact through Rigel MCP.
Rigel's own agents check consumers before they act: Solution Course (solution design), bug-triage investigators and internal-library upgrade fan-out.
Worst case first. Every match carries a type, a severity and a one-line reason, rolled up per service and per repo.
Coverage today: package matching reads package.json manifests. Endpoint and topic matching use the channels recorded in the chart, so coverage depends on how much detail extraction captured. We're hardening it now.
> find_consumers(source_repository_id: "orders-api", package_names: ["@your-org/orders-client"]) Cross-repo consumers for changes in orders-api: Repos affected: fulfillment, billing [package] fulfillment / fulfillment-service — severity: warning Depends on package "@your-org/orders-client" [package] billing / billing-worker — severity: warning Depends on package "@your-org/orders-client"
Architecture-aware review
Review that knows the architecture.
A Solution Architect and a QA persona review the change with the service's deep-analysis docs and code-graph neighbourhood in hand.
Line-anchored findings, posted as one GitHub review.
Told to leave a finding out rather than make one up.
Same per-repo switch as impact analysis. Works alongside your existing reviewer, not instead of it.
src/orders/dto.ts · L42
Renaming customerId changes a payload fulfillment consumes from order.created. Keep the old field for one release.
src/orders/totals.ts · L88
The new split-totals path has no test for a cancelled order with a partial refund.
Every morning
Start every day knowing yesterday's risk.
On the schedule you set, Rigel grades the last 24 hours of merged PRs across a constellation for cross-service blast radius.
Pick the time, for example weekdays at 08:00. The digest lands in Slack with the high-risk merges at the top and the reason next to each.
Requires a GitHub MCP server registered by your operator.
Rigel 08:00
Deploy risk digest · Orders constellation · 14 PRs merged
1 high3 medium10 low
High: orders-api #412 migration touches a shared database (fulfillment, billing)
For release managers
A CAB-ready pack from the real diff.
Rigel compares what's in production with what's in staging and writes the release pack. No more day of archaeology across repos and pipelines.
# production ↔ staging — diff → release pack (Illustration) # per-repo investigators · read-only orders-api 12 PRs · 3 Jira keys billing 4 PRs · 1 migration fulfillment hotfix merged back ✓ # written up as ✓ CAB ticket + checklist ✓ Schema change notice ✓ Feature docs · business, technical # + schema inventory and PDF artifacts for the record
1
A read-only investigator fans out per repo: commits, then PRs, then files, plus Jira keys.
2
It verifies that hotfixes were merged back.
3
Writers produce the pack, optionally publish to Confluence and post a Slack summary.
AWS release pipelines·Confluence · optional, off by default·Jira keys
Every run can be a dry run first. Other CD systems are on our radar; tell us what you run.
In your pipeline
Impact analysis as a CI step. Beta
A GitHub Action reads the refs from the pull request event, runs the analysis and comments on the PR. It can add model-powered analysis, or hand off to your Rigel server.
# .github/workflows/rigel-impact.yml (illustrative) - uses: <RIGEL_IMPACT_ACTION> with: enable-llm: "true" anthropic-api-key: ${{ secrets.ANTHROPIC_API_KEY }} # or hand off to your server: # server-url: https://rigel.your-company.internal
Not on the Marketplace yet
The action is in Beta and not yet published to the GitHub Marketplace. Ask us about access.
Next · Govern the merge
From knowing the risk to governing the merge.
Next in the platform →
Rigel Autopilot: gated merges for PRs from Rigel's own agents.
What ships today →Shipped, Beta and Coming soon, feature by feature.
Book a technical walkthroughWe'll score a sample PR on a demo estate, then on one of your repos.
Mechanism: how the risk score is computed →
See a sample Impact Analysis.
We'll walk through one on a demo estate, then on one of your repos.