Yanib drafts release updates, flags declared code-surface changes for review, and publishes across the channels you configure. Connect a repo, then ship in public.
Free forever. No credit card. Or see how it works first.
One service ships. Every other service that uses what changed hears about it the moment it lands.
Yanib records what each service depends on, and can open that configuration as a pull request itself.
Everything above runs today. The dashed node, flagging the blast radius on the pull request itself, is what we are building next.
Three services in one organisation. yanib/checkout-web and yanib/reporting-api both depend on the api-routes surface of yanib/payments-api. When a pull request removes the GET /api/billing/estimate endpoint and merges to the default branch, Yanib matches the diff against the api-routes surface, records one removed and one added capability, and resolves the owner from CODEOWNERS. It then posts to the #api-consumers channel and opens a documentation pull request, and separately files a row in each affected repository's activity and opens an issue in every affected repository that has enabled them, naming the dependency that changed. Flagging the affected services on the open pull request, before the merge, is not yet built.
Everything above is a diagram. This is the same feature pointed at Yanib itself, counted from the production database when this page loaded, with our own test fixtures left out.
schema models, fields and paths
across 45 days
what a flat log cannot see
the rest we dismissed
Every Yanib release is published by Yanib. Read our stories
How it works
Sign in with GitHub, GitLab, or Google. Connect a repo, webhook installed automatically. Import your release history in one click.
Yanib reads every merge and works out which parts of your product actually changed. It drafts the release note in seconds, on a tag or fully on autopilot, then a second, stronger model checks every claim against the real PRs and commits.
Review if you want, then publish. One push reaches every channel your users already read, while the owners of what changed get told without anyone having to remember.
Surface detection
A surface is anything outside your repo can rely on: an endpoint, a database field, an env var. You list yours once, in a file next to your code. Yanib checks default-branch diffs against those rules and records matching changes as candidates with source evidence.
How detection decidespayments-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, or an eligible repository can use auto-confirm after an independent AI evidence check.
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.
Off until you turn it on
Detection is per repo, and opening docs pull requests is a second switch again. Yanib never writes to your default branch, whichever way both are set.
Accuracy status: the structural rules have automated coverage, but cross-repository real-history accuracy is still being calibrated. Yanib does not present candidates as independently verified truth.
One publish, every channel
You never write a word. Yanib drafts the update from your actual commits and PRs, QA checks every claim against the evidence, then publishes everywhere your users, community, and stakeholders already read. Approve it or run on autopilot. Formatted for each channel, routed per repo.
One update, zero writing
One update, zero writing
Plus one more audience that never reads announcement posts, meet the ninth channel below.
The ninth channel
Coding agents check what a dependency shipped before they upgrade it. Every Yanib story is served in machine readable formats, markdown for LLMs, JSON for tools, MCP for agents, so the answer is one request away.
$ 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
Features
Detect, write, publish, be known, and let agents do it for you. Five layers, one tool.
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
Structured release notes from your commits and PRs on every tag push. Every draft is QA reviewed against the PRs it actually shipped: missing entries, overclaims, undocumented breaking changes, plus a suggested semver bump.
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
One click publishes to every channel at once, or leave it on autopilot for every tag.
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
Every release you publish builds a public record of what you’ve shipped. This card is the real product output, generated from real 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.
05 · Agents
Agents in Claude Code, Claude Desktop, or Cursor query, draft, QA, and, with your approval, publish releases. OAuth on first connect. Nothing to copy and paste. Manage tokens and connections in Settings → Agents.
Agents get tools including yanib_draft_release, yanib_review_release, and yanib_publish_release, publish requires explicit human approval.
Read the MCP docsA public MCP endpoint plus llms.txt on every story page. No auth required to read.
OAuth 2.1 with PKCE, per scope consent, and human approval publish. Agents never ship without you.
Embeds
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
Built for
Whether you ship in public or ship for customers, Yanib works the moment you connect a repo. Same tool, different surface.
Free public profile at /u/username with a shipping heatmap, AI tagline, and pinned releases. Embed on your site or paste into your portfolio.
AI drafts every release; one click sends it everywhere your users already are. Surface detection flags changes on the code paths you declare, keeps the diff as evidence, and applies the notification routes 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.
Minutes to set up. No card required.