Understand the impact before merge. Share the change after.
Free includes one repository. No credit card. Reviews are advisory. Cross-repo evaluation options
Adding a required argument to checkout changes how connected repositories call your API.
− checkout(options)+ checkout(operation, options)Make the argument optional or update the 3 linked callers. Review the evidence before merging.
Understand the change. Keep everyone in the loop.
Recorded platform totals from August 17, 2026, including Yanib’s own use.
Yanib traces affected code in the current repository and across the connected repositories you choose. When enabled, its GitHub review explains the likely consequence, recommended change, and verification steps.
payments-api / api/checkout.tsexport async function checkout(+ operationName: string, options: CheckoutOptions) {payments-api/lib/billing.ts:41Needs update: checkout(options)
checkout-web/src/pricing.ts:27Needs update: checkout(options)
mobile-app/src/cart.ts:84Needs update: checkout(options)
New argument breaks existing call signatures
Existing checkout(options) calls now pass an object where a string is required and omit the options argument. TypeScript reports an error at each unchanged call.
Recommended: Preserve checkout(options) by adding the operation name inside options, or update all three callers together.
Verify: Run the TypeScript build for payments-api, checkout-web, and mobile-app after updating the calls.
Yanib reviews the technical consequence while a pull request is open. Once the change is confirmed, the same source becomes a release update for every channel you configure.
Explore the lifecycleOne same-repository caller and 2 selected cross-repository consumers need attention.
checkout-web/src/pricing.ts:27The required operation name is missing.
Preserve compatibility or coordinate all 3 callers in this release.
The verified change becomes one release source with migration guidance and exact provenance.
Checkout API now requires an operation name
Migration guidance is ready for affected teams and users.
Connect a GitHub repository. Enable analysis and GitHub posting separately. Same-repository analysis is included; you choose which connected repositories to add to the scope.
On each eligible pull-request update, Yanib checks changed code and supported dependency relationships. One GitHub review shows severity, exact locations, what to change, and how to verify it.
After merge, confirmed surface changes can update release notes, notify configured channels, open a docs pull request, or create separately enabled downstream issues.
Declared surfaces are the product contracts your team chooses to track for post-merge routing. That can be an endpoint, a database field, or an environment variable. Yanib checks default-branch diffs, preserves source evidence, and routes confirmed changes only to the notifications and repository actions you enable.
How surface rules workpayments-api#482Swap the billing estimate endpoint for the new preview one
+ app/api/billing/preview/route.ts
− app/api/billing/estimate/route.ts
~ lib/pricing/round.ts
api-routesPOST /api/billing/previewGET /api/billing/estimate@acme/payments· read from your CODEOWNERSThe third file does not match the declared surface rules. The two matches move to confirmation, either through review or an eligible repository’s auto-confirm policy.
When notifications are enabled, a match follows the surface’s configured routes and remains available for review in Yanib.
docs: document new api-routes capabilitiesOpened as a PR on your repo. Yours to merge.
Configured outcomes
Yanib formats the same source evidence for every destination. It notifies the channels configured for a surface. When a consuming repository declares that dependency and enables issue creation, Yanib opens a GitHub issue automatically.
Kind-first alerts in the engineering channels each surface names.
Acme
● Engineering
Channels
#general
#platform
#api-consumers
# api-consumers
34 members
🔴 Removed from api-routes
GET /api/billing/estimateacme/payments-api · BREAKING
View producing commit ↗
Rich embeds keep the change type, surface, impact, and source together.
Acme Engineering
Platform
#team-platform
#platform-alerts
#deployments
🔴 Removed from api-routes
GET /api/billing/estimateYanib’s AI reviewer confirmed this change on api-routes.
View change ↗
Opted-in consuming repos receive trackable work with the declaration attached.
A dependency changed: something was removed in acme/payments-api #214
A surface this repository declares as consumed changed in acme/payments-api, and Yanib’s AI reviewer confirmed it automatically.
What changed
Removed: GET /api/billing/estimateYour declaration
consumes: api-routes from acme/payments-apiView producing commit 0d9ae36 ↗
Assignees
No one assigned
Labels
None yet
Development
checkout-web
The routing is explicit. Channel notifications follow the surface configuration. A GitHub issue is opened only when the consuming repository declared the dependency, enabled issue creation, and the change was confirmed under the producing repository’s policy.
.yanib.ymlcommitted to your repo, reviewed like codefeat: add POST /api/billing/previewapi-routes · candidaterefactor: move helpers into lib/silentchore: bump prisma to 6.1silentremove GET /api/billing/estimateapi-routes · reviewstyle: reformat route handlerssilentThree of those five did not match the declared structural rules. The two matches enter confirmation, not verified impact. A person can review them; eligible repositories may use Auto mode while uncertain candidates remain available for review.
You don’t start from an empty list
Connect a repo and Yanib reads back through 90 days of history first, so the inventory of what you expose already exists before you have written a line of config.
Nothing new to maintain
Owners come from the CODEOWNERS file you already have. The watchlist is one small file in the repo, changed in a pull request like everything else you version.
Writes stay under your control
Impact Review, docs pull requests, and consumer issues have independent settings. Analysis never writes directly to your default branch.
Before merge, Impact Review uses indexed code references for advisory findings. After merge, declared surface rules drive only the confirmed workflows you enable.
Whether you ship in public or ship for customers, Yanib connects review and release communication in one workflow. Impact Review runs automatically on eligible GitHub pull-request events once you enable it.
Free public profile at /u/username with a shipping heatmap, AI tagline, and pinned releases. Embed on your site or paste into your portfolio.
Impact Review links a pull request to affected code in the same repository or the connected repositories you select. After merge, Yanib drafts the release and sends it to the channels you configure.
Get a walkthrough tailored to how your team ships. We’ll show you around and help you get set up. Free to start, no credit card.
Start with one repository. No credit card.
Get started free