Skip to main content

The broadcasting layer for software teams.

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.

Connect a repo, free

Free forever. No credit card. Or see how it works first.

Backed byNVIDIA Inception Program member
Introducing

Surface detection

One service ships. Every other service that uses what changed hears about it the moment it lands.

yanib/checkout-web
depends on payments-api
yanib/reporting-api
depends on payments-api
Flag it on the PRnext
yanib/payments-api
ships the change
Yanib detects
Slack + Discord
Docs PR
Row in their activity
Issue in their repo
01Two services depend on a third
yanib/checkout-webyanib/reporting-apiboth call api-routes

Yanib records what each service depends on, and can open that configuration as a pull request itself.

  1. 01
  2. 02
  3. 03
  4. 04
  5. 05

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.

Running on our own repo

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.

600
capabilities tracked

schema models, fields and paths

924
changes recorded

across 45 days

6
removals and edits

what a flat log cannot see

92%
confirmed by a human

the rest we dismissed

See it liveA real shipping profileA real public story page
9channels from one publish
105releases published
116repos connected

Every Yanib release is published by Yanib. Read our stories

How it works

Three steps. Two minutes.

  1. Connect

    Sign in with GitHub, GitLab, or Google. Connect a repo, webhook installed automatically. Import your release history in one click.

  2. Detect

    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.

  3. Broadcast

    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

Every system has parts other teams quietly depend on.

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 decides
01Merged
payments-api#482

Swap 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

02Review candidate
Yanibapi-routes
  • ADDEDPOST /api/billing/preview
  • REMOVEDGET /api/billing/estimate
Owner@acme/payments· read from your CODEOWNERS

The third file does not match the declared surface rules. The two matches still need human confirmation.

03Configured delivery
#api-consumersDiscordEmail

When notifications are enabled, a match follows the surface’s configured routes and remains available for review in Yanib.

Docs went stale
docs: document new api-routes capabilities

Opened as a PR on your repo. Yours to merge.

.yanib.ymlcommitted to your repo, reviewed like code
  • api-routes
  • schema
  • env-vars
  • background-jobs
  • ai-tasks
  • feat: add POST /api/billing/previewapi-routes · candidate
  • refactor: move helpers into lib/silent
  • chore: bump prisma to 6.1silent
  • remove GET /api/billing/estimateapi-routes · review
  • style: reformat route handlerssilent

Three of those five did not match the declared structural rules. The two matches remain review candidates, not verified impact. A person confirms the evidence before either change enters the confirmed inventory.

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 ship. Yanib broadcasts.

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

  • Detected from your commits & PRs
  • AI written, evidence checked
  • Approve or run autopilot
Publish everywhere
GitHub ReleasesNative release entryPublic story pageHosted page, your brandSlackTeam channelsDiscordCommunity serversEmail subscribersVerified list, one clickRSS feedEvery feed readerEmbeddable widgetInside your productPublic APIJSON, no auth

Plus one more audience that never reads announcement posts, meet the ninth channel below.

The ninth channel

Agents are an audience too.

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.

Read the MCP docsSee /llms.txtWhy agents are a channel
agent session

$ 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

Everything you need to ship in public

Detect, write, publish, be known, and let agents do it for you. Five layers, one tool.

01 · Detect

Catch new capabilities where they enter the codebase.

  • Structural surface detection

    Check configured paths for added files, schema additions, or custom pattern matches. Each match keeps its diff evidence and enters review as a candidate.

  • A persistent capability ledger

    See what Yanib found, the commit or merged PR behind it, whether it was announced, and which declared docs stayed unchanged.

  • Docs follow-up with consent

    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

Release notes that write and review themselves.

  • AI drafts from your real PRs

    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.

  • Rewrite in your voice

    Concise, detailed, user facing, or technical, plus multi audience versions for devs, PMs, and end users.

  • Translate for every reader

    Localize entries for international readers with one click. Translations are cached per release.

03 · Publish

One publish. Every channel your users live in.

  • Everywhere at once

    One click publishes to every channel at once, or leave it on autopilot for every tag.

    Publish releaseon tag push · autopilot
    • GitHub Releases✓
    • Slack✓
    • Discord✓
    • Email subscribers✓
    • Public story page✓
    • RSS✓
    • Widgets✓
    • API✓

  • Team digests

    AI velocity reports on your cadence, daily, weekly, or monthly, delivered to Slack with per contributor breakdowns.

  • Import your history

    One click backfill turns your past tags into structured releases, so your story page starts with history, not a blank page.

04 · Be known

What you ship becomes who you are.

  • Your public shipping profile

    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 shipping card for binaydhakal, updated on every release

    live, updates on every release

    View the profile

  • README cards & badges

    SVG profile cards and per repo release badges for any GitHub README. They update automatically on every ship.

  • Year in review + streaks

    A shareable annual recap, plus week based ship streaks rendered right on your card.

05 · Agents

Agent callable, end to end.

  • A real MCP server

    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 docs

  • Readable by any agent

    A public MCP endpoint plus llms.txt on every story page. No auth required to read.

  • Scoped & safe

    OAuth 2.1 with PKCE, per scope consent, and human approval publish. Agents never ship without you.

Embeds

One embed, drop it anywhere

Add the script once, pick a component, paste the tag. Works anywhere you can drop HTML.

Preview

Stories

acme/web

v2.4.0Team roles & SSO
v2.3.2API rate limits
v2.3.0Dark mode

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

Two kinds of dev. One product.

Whether you ship in public or ship for customers, Yanib works the moment you connect a repo. Same tool, different surface.

Indie / solo dev

Make what you ship into what you're known for.

Free public profile at /u/username with a shipping heatmap, AI tagline, and pinned releases. Embed on your site or paste into your portfolio.

  • Public profile + shipping heatmap
  • README cards & badges that update automatically
  • A shareable year in review, every year you ship
Software team

Stop writing release notes. Start broadcasting them.

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.

  • Surface detection: evidence-backed candidates for human review
  • Release stories across your repos, unlimited on Pro or BYOK
  • Multi channel publish + team digests
  • Owner / Admin / Member roles

See Yanib live.

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.

  • Release stories across your repos
  • Public story page + shipping profile
  • Slack, Discord, email & embeddable widgets
  • Team commit digests, roles & analytics

Your releases deserve an audience.

Minutes to set up. No card required.

Get started free