Everything you need to ship release notes

How Yanib works

The release pipeline in 60 seconds

You keep shipping the way you already do, commits, PRs, tags. When you publish a release on GitHub or GitLab, Yanib takes it from there.

1. 1

   You push a tag

   Publish a release on GitHub (or tag push on GitLab). Our webhook picks it up in seconds. No CI step, no GitHub Action, no YAML to maintain.

2. 2

   AI writes a draft

   Yanib pulls every commit and merged PR between the previous tag and this one, feeds them to the AI with context about your repo's stack and history, and produces a structured story, grouped by Breaking / Feature / Fix.

3. 3

   You review and publish

   Edit anything that needs a human touch. Hit Publish. Yanib updates your GitHub Release, your public story page, sends it to Slack/Discord/email subscribers, and refreshes any embedded widgets, all at once.

Quickstart

Pick your track

Two common starting points. Both take about five minutes.

Connect

Connecting a repo

Click Connect Repo on the Repos page. The modal shows every repo you have admin or maintain access to. Pick one and hit Connect. Yanib sets up a webhook and you're done.

GitHub: OAuth vs GitHub App

Yanib connects to GitHub one of two ways:

• OAuth webhook (default), works for any repo you personally have admin rights to.
• Yanib GitHub App, the right choice for organization owned repos, private repos, or when teammates without admin rights need to connect repos the org owns. Install it once per organization from inside the Connect modal.

GitLab

Sign in with GitLab or connect a GitLab account from Settings → Account. Both GitLab.com and self hosted instances are supported. For self hosted, use a Personal Access Token (go to Settings → Integrations → GitLab and paste the token).

After connect: automatic indexing

On first connect, Yanib spends a minute reading your README, manifest file, and the last 50 merged PRs to build a context brief about your project. It's why the generated notes sound like your product, not generic "updated utility functions" noise.

The brief refreshes periodically so it stays current as your codebase evolves.

First release

Your first release

The default trigger is a GitHub Release (or GitLab Release / Tag Push). Create one the way you normally would:

git tag v1.0.0
  git push origin v1.0.0
  # then on GitHub: Releases → Draft a new release → pick the tag → Publish

Within a few seconds, Yanib will:

1. Mark the release as Pending in your dashboard.
2. Fetch all commits and merged PRs between the previous tag and this new one.
3. Call the AI to draft structured entries (Breaking changes, New features, Bug fixes, Other).
4. Notify you via email that the draft is ready to review, and transition the release to Draft.

Open the release in your dashboard, make any edits, and click Publish. Everything downstream happens in one shot.

Triggers

Auto release triggers

Not every team tags. Yanib supports several trigger modes. Pick one per repo from Repos → [repo] → Settings.

Switching modes is safe. Existing releases stay, and the next trigger picks up from where you left off. Merged PRs that haven't been released yet sit in a running draft list you can see any time under Repos → [repo] → Overview.

Review

Reviewing & editing

Once the AI produces a draft, you get a structured editor: each change is a standalone entry you can edit inline, reorder by drag and drop, delete, or rewrite with a single click.

AI rewrite, in any voice

Hit the sparkle icon on any entry to rewrite it as:

• Concise, one tight sentence.
• Detailed, context, motivation, and what changed.
• User facing, plain English for non engineers.
• Technical, for a developer only audience.

Multi audience versions

Click Generate multi audience to produce three parallel versions of the whole release at once: one for developers, one for product managers, one for end users. Switch between them in the release view without generating them again.

Social posts

Click Generate social to draft an X post and a LinkedIn post for the release, ready to copy and paste or share straight to your own accounts.

Translation

On your public story page, readers can switch language from a picker. Yanib translates the entries on first request, caches the result, and serves that cached copy on every later view. Technical terms (API names, function names) are preserved.

Publish

Publishing & distribution

Hitting Publish does five things at once:

1. Updates your GitHub Release body (or GitLab Release) with the final markdown.
2. Publishes your public story page at yanib.dev/stories/<slug>.
3. Posts to every integration linked to the repo (Slack, Discord, generic webhooks).
4. Emails subscribers of the public story page (with double opt in and one click unsubscribe).
5. Refreshes embedded widgets on any site using the Yanib SDK.

If the GitHub Release update fails (rare, usually rate limits or revoked tokens), the integrations, emails, and public page still go out. We never let one failing channel block the others.

Export

Need the raw content elsewhere? Every release has an export button that outputs Markdown, HTML, or JSON. Handy for CHANGELOG.md files, internal wikis, or custom distribution.

Integrations

Slack, Discord, webhooks, email

Integrations are set up once per account or team under Settings → Integrations, then linked per repo under each repo's Integrations tab. A single Slack channel can receive releases from multiple repos; a single repo can post to multiple channels.

Slack

Paste an incoming webhook URL. You get formatted messages with title, summary, highlighted change types, and a link to the full release.

Discord

Paste a Discord webhook URL. You get a rich embed with color coded change types (red for breaking, green for features, amber for fixes) and a link to the release.

Generic webhooks (Zapier / Make / n8n / custom)

Any URL that accepts JSON. Yanib sends a structured payload with the release, entries, and metadata. Pipe it into Zapier, Make, n8n, or your own automation.

Email subscribers

Your public story page has a "Subscribe" form. Readers enter their email, confirm via a verification link, and get an email every time you publish. Built in one click unsubscribe in every email.

Surfaces

Surface detection

A release tells your customers what shipped. Surface detection is the other direction: it flags candidate changes to declared endpoints, database fields, and environment variables, with the source diff attached for review. Confirmed changes can then be routed to the teams you configured. Turn it on per repo under Repos → [repo] → Surfaces. It watches pushes to your default branch, so it runs whether or not you tag releases.

1. Declare what you expose

Yanib never guesses at your architecture. You describe it once in a .yanib.yml committed to the repo, reviewed in a PR like any other config and versioned with the thing it describes.

version: 1

  surfaces:
  - name: api-routes
    paths: ["app/api/**/route.ts"]
    detect: new_file
    owners: ["@acme/payments"]     # who owns it
    notify: ["#api-consumers"]     # which integrations hear about it
    docs: ["README.md"]            # what goes stale when it grows

detect picks the primitive: new_file fires when a file is added under paths, pattern fires when your regex matches an added line (capture group 1 becomes the identifier), and prisma_schema reads added models and fields straight off the diff. A repo with no config still works; you just get the defaults.

2. What counts as a change

Detection reads the diff, not the commit message, and not a model's opinion about what looks important. Each candidate lands as one of ADDED, CHANGED, RENAMED, DEPRECATED or REMOVED. The detector applies explicit path, file status, added-line, and rename rules to narrow what needs review; it does not prove downstream impact on its own.

3. Who gets told

Owners resolve from the surface's owners: list first, and fall back to your CODEOWNERS file when it is absent, so most repos need no extra setup. Delivery goes to the integrations named in notify:, matched against the integration names you already set up in Integrations. When surface notifications are enabled, leaving notify: off uses every integration on the repo; naming channels narrows delivery to those integrations. A routed match is still a review candidate, not proof of impact.

4. Docs to review

A file listed under a surface's docs: becomes a review target when that surface matches and the commit did not update the file. With a separate opt-in, Yanib can open a pull request proposing an update. The PR never writes directly to your default branch and remains yours to edit, merge, or close.

5. You don't start from zero

When you connect a GitHub repo, Yanib reads a bounded slice of recent history (90 days by default) and imports structural matches as historical candidates before you have written a line of config. Those rows keep their original commit dates, are labeled as imported rather than human confirmed, and are never announced.

Public page

Your public story page

Every connected repo gets a public page at yanib.dev/stories/<slug>. No configuration needed. It's live the moment you publish your first release.

Customize it

Under Repos → [repo] → Customize you can set:

• Page title and tagline
• Logo (uploaded or URL)
• Accent color (matches your brand)
• A custom hero subtitle

RSS, SEO, and analytics

Every page comes with /rss.xml automatically, an OG image for social sharing, and proper meta tags so search engines index it. Under Analytics on the repo page you can see pageviews, referrers, and the release each view landed on.

Slug stays stable

Your slug is generated when you first connect the repo and never changes, not even after a GitHub rename or transfer. That means links you've shared continue to work forever.

Embeds

SDK & embeds

Drop one script tag on any page and you can use the web components anywhere:

<script src="https://yanib.dev/sdk.js"></script>

  <!-- Full release feed -->
  <yanib-stories slug="your-repo-slug" theme="light" limit="5"></yanib-stories>

  <!-- Dismissible announcement bar -->
  <yanib-banner slug="your-repo-slug" dismissible="true"></yanib-banner>

  <!-- Floating "what's new" bell -->
  <yanib-notifications slug="your-repo-slug" position="bottom-right"></yanib-notifications>

  <!-- Personal release feed (for profiles, portfolios) -->
  <yanib-feed user="your-username" limit="5"></yanib-feed>

The components are framework agnostic. They work in React, Vue, plain HTML, or any static site generator. Each component fetches live data from Yanib's public API and refreshes on publish.

Public API (for programmatic access)

Prefer to build your own UI? Use the public endpoints:

• GET /api/v1/releases?slug=<slug>, all releases for a repo.
• GET /api/v1/releases/latest?slug=<slug>, latest release only.
• GET /api/feed/<username>, a user's release feed across all their repos.
• GET /api/stories/<slug>/embed, JSON optimized for widgets (CORS enabled).

Teams

Teams

A team is a shared workspace. Its repos, integrations, and digests stay separate from your personal account, with its own billing.

Roles

• Owner, full control. Manage billing, delete the team.
• Admin, manage repos, members, and integrations. Cannot delete the team or change billing.
• Member, view and edit releases, publish drafts. Cannot add repos or invite others.

Switching context

The team switcher in the top nav toggles between your personal workspace and any team you belong to. Everything you do, connecting a repo, adding a Slack integration, drafting a release, applies to the current context. No accidental cross team moves.

Invites

Invite teammates by email from Teams → [team] → Members. Invites expire after 7 days. The invitee accepts via a link emailed to them; if they don't have an account yet, they can sign up and land straight in the team.

Digests

Team Commit Digest

Digests are different from releases. A release documents a specific version. A digest is a recurring AI generated velocity report: "here's what your team shipped this week."

Opt in and schedule

Under Team Settings → Digests, toggle on either or both:

• Team level digest, one report aggregating all team repos.
• Per repo digest, one report per active repo.

Pick a cadence (daily, weekly, biweekly, monthly), the day/hour in UTC, and where it should go (Slack, Discord, email).

What you get

Each digest contains:

• A one paragraph AI summary of the period's work
• Commit counts per repo, per contributor
• Highlighted themes (e.g. "authentication hardening," "performance")
• A per contributor insight line (opt out available)
• A hero quote and a "standout moment" from the period

Privacy

If your team prefers no individual attribution, toggle off Show contributor names. The AI prompt is rewritten to speak about "the team" collectively and the dashboard hides the contributor list.

Quiet periods

If zero commits happened in the window, the digest is skipped. No "you shipped nothing" Slack messages.

Profile

Developer profile

Every Yanib user automatically gets a public developer profile at yanib.dev/u/<username>. It aggregates every release you've published across every repo you've connected.

Profile card (SVG for READMEs)

Drop this in your GitHub README:

![Yanib](https://yanib.dev/card/your-username/svg)

Customize light/dark theme, compact or full layout, and accent color under Settings → Account → Profile Cards. Live preview updates as you type.

Release badge

A shields.io style badge showing the latest release of any of your repos:

![Latest release](https://yanib.dev/badge/owner/repo/svg)

The badge keeps working after a GitHub rename or transfer. Old URLs redirect via the former names list we track automatically.

Stats badge

A live "shipping stats" badge summarizing total releases, active repos, and last ship date:

![Shipping](https://yanib.dev/card/your-username/stats)

Year in Review

A year in review page at yanib.dev/u/<username>/<year>, great for end of year shipping retrospectives on X/LinkedIn. Combines your Yanib releases with your GitHub activity for the year.

BYOK

Bring your own AI key

Prefer to pay Anthropic directly and avoid the platform surcharge? Plug in your own Claude API key.

What you get

• Unlimited repos on the Free tier (you're paying the AI bill yourself).
• Model choice, pick your preferred model from the Settings page.
• Isolated cache, your key's AI responses don't mix with the platform cache.

Setup

1. Get a Claude API key from console.anthropic.com.
2. Go to Settings → AI in Yanib.
3. Paste your key and pick your preferred model. Save.

Your key is encrypted at rest with AES-256-GCM before being stored. It's decrypted only inside the AI task context and never logged.

Plans

Plans

Need more?

Connecting more repos, adding your team, or want a walkthrough? Book a demo and we'll set you up with the right configuration.

Troubleshooting

Common issues

I pushed a tag but nothing happened

Yanib listens for Release events, not plain tag pushes. Publish a release from the GitHub Releases UI (or API) pointing at your tag. On GitLab, either use the Releases feature or trigger via Tag Push.

I see "GitHub App" on my repo but no releases generate

The App installation under your owner may not cover that specific repo. Go to your GitHub App settings and add the repo to the install, or disconnect and reconnect the repo in Yanib. The fresh connect verifies per repo coverage and falls back to an OAuth webhook if the App doesn't apply.

A release status is stuck on Generating

Click Retry on the release. If it keeps failing, check Settings → AI. If you're on BYOK, your key may have hit a rate limit or expired. Releases that fail are logged in the Activity feed.

I'm Pro but I see an upgrade modal when connecting a team repo

Personal Pro doesn't cover team repos. Purchase Pro for the team itself from Team Settings → Billing.

The README badge shows "none" after I renamed my repo

It should auto recover. We track former repo names and fall back to them automatically. If it stays broken, sync the repo manually from Repos → [repo] → Sync from GitHub.

Something else?

Check the Support page for the FAQ, or email support@yanib.dev.