Yanib connects to your GitHub repositories. While a pull request is open, it traces the change to the code that depends on it and posts one advisory review in GitHub. After merge, the confirmed change becomes a release update for the channels you configure.
Free includes one repository. No credit card. Reviews are advisory. Cross-repo evaluation options
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.
Recorded platform totals from August 17, 2026, including Yanib’s own use.
What Yanib is
Yanib connects to your GitHub repositories and does two jobs, in order. While a pull request is open, it traces the change to the code that depends on it and posts one review in GitHub. After the change merges, it turns the confirmed change into a release update for the teams and users who need to know.
A small diff can change how another file, or another service, calls your code. Yanib finds those callers and explains the consequence in the pull request, where the decision is made.
For the engineer opening the change, the reviewer approving it, and the platform team whose API it touches.
Most of what a team ships never reaches the people who depend on it. Yanib drafts the release update from the merged change and publishes it once, everywhere you have told it to.
For the customers using the product, the teams building on it, and the people who answer for it in support and documentation.
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.
How it works
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.
Yanib drafts updates from your commits and PRs. Review the draft and its evidence, then share it through the channels you configure. Choose approval or an enabled automatic workflow, with formatting and routing for each destination.
One prepared update
One prepared update
Plus one more audience that never reads announcement posts. Meet the ninth channel: agents.
Give coding agents context about what a dependency shipped. Published public stories are available as markdown and through JSON and MCP tools. Private release content does not become public by enabling an agent integration.
$ curl https://yanib.dev/llms.txt
# the broadcasting layer, indexed for agents
/llms.txt → product + endpoint index
/stories/{slug}/llms.txt → stories as clean markdown
/api/v1/releases/latest → latest release, JSON
/api/mcp/public → read only MCP, no account
Detect, write, publish, and build a public record of what you ship.
01 · Detect
Check configured paths for added files, schema additions, or custom pattern matches. Each match keeps its diff evidence and enters review as a candidate.
See what Yanib found, the commit or merged PR behind it, whether it was announced, and which declared docs stayed unchanged.
Declare related docs in .yanib.yml. Yanib records stale docs and, when repo write access is enabled separately, opens a reviewable update PR.
02 · Write
Draft release notes from connected commits and PRs using your configured triggers. Release review can flag missing entries, overclaims, and breaking changes for you to check before publishing.
Concise, detailed, user facing, or technical, plus multi audience versions for devs, PMs, and end users.
Localize entries for international readers with one click. Translations are cached per release.
03 · Publish
Publish to the channels you configure. Enable automatic publishing separately when that workflow fits your repository.
AI velocity reports on your cadence, daily, weekly, or monthly, delivered to Slack with per contributor breakdowns.
One click backfill turns your past tags into structured releases, so your story page starts with history, not a blank page.
04 · Be known
Published public releases build a record of what a repository and its contributors shipped. This card is the real product output, generated from published public releases.
live, updates on every release
View the profileSVG profile cards and per repo release badges for any GitHub README. They update automatically on every ship.
A shareable annual recap, plus week based ship streaks rendered right on your card.
Add the script once, pick a component, paste the tag. Works anywhere you can drop HTML.
Preview
Stories
acme/web
Copy
Embed markup for Story feed
<script src="https://yanib.dev/sdk.js"></script> <yanib-stories repo="owner/repo" theme="light" limit="5"> </yanib-stories>
Use repo="owner/name" instead of slug when it fits your setup.
Components
Pick a component to update the preview and the copy and paste snippet.
Live playground: Embed demo
Who we are
Yanib is built by engineers who work in shared codebases every day. It started with a familiar failure. A change merged in one repository broke a team in another part of the company, and nobody had told them, because nobody knew they were affected.
The tools available announced releases. None of them could say who a change would reach before it shipped, or make sure those people heard about it after. Yanib is the tool that was missing that day: one review that names the affected code while the pull request is open, and one release update that reaches everyone who depends on it once it merges.
Yanib is independent and founder-run, and Yanib reviews and publishes every release of Yanib itself.
Built for
Yanib connects review and release communication in one workflow for the team that owns the code. Impact Review runs automatically on eligible GitHub pull-request events once you enable it, and every merge becomes a story your channels receive.
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. Thirty days of Pro for a new team workspace, no credit card.
Start with one repository. No credit card.