[ docs · changelog ]live

Every PR is a candidate. Most stay quiet. Some become posts.

This is the technical reference for how the changelog mechanic works — what makes an entry, how tiers are scored, what the schema looks like, how you override defaults. For the value-prop view of the same feature, see Blog & Changelog.

[ tier scoring ]

How a PR becomes an entry.

Quill grades every merged PR by impact. Three signals matter most: the conventional-commit prefix, the files touched, and any explicit override labels you've taught Quill to respect. The score determines surface placement.

Tier 1 · Blog post draft

Big launches. Feature flags flipping on, new top-level routes, breaking API additions. Lands as a draft blog post with hero copy, body, and a screenshot — operator polishes the voice.

Tier 2 · Changelog entry

User-visible changes that don't merit a launch post. Bug fixes customers care about, UI polish, small new features. Single paragraph, dated to merge time.

Tier 3 · Silent

Internal refactors, test changes, CI tweaks, documentation updates. Don't ship to public surfaces. Still searchable internally if your team wants a full history.

[ prefix mapping ]

Conventional-commit prefixes Quill recognizes.

Quill maps the prefix on your PR title to a user-facing category. Internal prefixes default to silent. The mapping is configurable per workspace.

prefixcategorydefault tier
featfeaturetier 1 or 2 (by diff size)
fixfixtier 2
polishimprovementtier 2
perfimprovementtier 2
chore · refactor · test · docs · build · ci · stylesilent (tier 3)
[ entry schema ]

What's on a changelog entry.

Each entry stays editable in the portal after Quill drafts it. The shape is intentionally small — readers want titles, summaries, and dates; the operator can always toggle "what changed" to surface the files-touched list. Most changelogs hide that; Quill exposes it because the pipeline already has it.

type ReleaseNote = { id: string; // pr-242, sha-abc1234 published_at: string; // ISO 8601, merge time title: string; // operator-editable summary: string; // short paragraph, editable highlights?: string[]; // curated bullets for tier 1 category: "feature" | "fix" | "improvement" | "security"; files_changed: string[]; // surfaced via "what changed" source: { pr_number?: number; commit_sha: string; author: string; raw_title: string; // original PR title, preserved }; status: "draft" | "published" | "skipped"; };
[ overriding the tier ]

Promote, demote, or silence per-PR.

Three ways to override Quill's tier scoring, in order of precedence:

  1. PR label. Add launch, changelog, or no-changelog to your PR — Quill promotes, demotes, or silences accordingly. Labels win over both the prefix and the diff heuristics.
  2. Body footer. A line in your PR body like Changelog: tier 1 or Changelog: skip. Use this when you don't want to manage labels. Matched case-insensitively.
  3. Operator override. From the portal's review queue, drag an entry up or down between tiers. The override persists; future PRs by the same author against the same surfaces inherit the bias.
[ surfaces ]

Where the entries end up.

Public changelog page

/changelog on your docs site. Reverse-chronological, paginated, filterable by category. Tier 1 entries get prominent treatment with their full body.

RSS + OG cards

Auto-generated RSS at /changelog/rss.xml, OpenGraph image per entry, sitemap inclusion. Subscribers get notified without you toggling a switch.

Webhook events

Each publish fires article.published with surface: "changelog". Fan out into Slack, your in-product changelog widget, anything you want. See webhooks.

Stop saving up for launch posts.

Merge a PR and see what Quill drafts. If it's not what you'd ship, don't ship it. Most of the time, you'll edit a sentence and publish.