How to auto-generate a changelog from GitHub

A changelog is one of those documents that everyone agrees is valuable and almost nobody maintains. The pattern is familiar: someone creates a page, updates it diligently for a few weeks, then gradually stops. Three months later, the last entry reads "v2.3.1 - minor bug fixes" and the page becomes another relic of good intentions.

The problem is not laziness. Writing a useful changelog requires gathering information from pull requests, commit messages, release tags, and sometimes Slack threads or meeting notes. It means understanding which changes matter to which audience, synthesising technical detail into something readable, and doing all of this on a regular cadence. That is a significant amount of recurring work for something that feels, in the moment, less urgent than shipping the next feature.

Automation changes the economics. When a changelog writes itself from the activity already happening in your repositories, the cost drops to near zero and the document stays current indefinitely. This is what Fabric's self-writing docs were built to do.

Why changelogs matter more than teams expect

A changelog is not just a record for external users. Internally, it serves as a shared understanding of what the engineering team has delivered. Product managers reference it when preparing release notes. Support teams use it to explain recent changes to customers. New engineers read it to understand the pace and direction of development.

When the changelog goes stale, these groups lose a reliable source of truth. Product managers start pinging engineers in Slack to ask what shipped last week. Support tickets go unanswered because nobody knows whether a fix has been deployed. Onboarding slows down because there is no narrative thread connecting recent work.

The compounding effect is subtle but real. A well-maintained changelog creates a kind of institutional memory, a running account of decisions made, features shipped, and problems solved. Without it, that knowledge scatters across pull request descriptions, commit messages, and the memories of individual engineers.

The manual approach and where it breaks down

Most teams that attempt a changelog follow a similar pattern. Someone, usually an engineering manager or a senior developer, takes responsibility for updating a document at the end of each week or sprint. They review merged pull requests, summarise the important ones, and add an entry to the changelog.

This works for a while. The person doing it develops a feel for what to include and how to frame it. But the process depends entirely on their continued attention. When they go on holiday, the changelog pauses. When they change roles, it often stops entirely. The knowledge of how to write a good entry, what to include, what to leave out, lives in their head rather than in any system.

Some teams try to distribute the work by asking each developer to update the changelog when they merge a pull request. This spreads the burden but introduces inconsistency. Different people have different ideas about what constitutes a meaningful change. The resulting document reads like it was written by a committee, because it was.

Tooling helps at the margins. Conventional commit formats and automated release note generators can produce a list of changes from commit messages. But the output tends to be a raw, unsorted list of technical descriptions that requires significant editing before it is useful to anyone outside the engineering team. The gap between "list of commits" and "useful changelog" is where most automation falls short.

How Fabric generates a changelog from GitHub

Fabric takes a different approach. Rather than parsing commit messages into a list, it connects to your GitHub repositories through a secure integration and builds a contextual understanding of what is changing and why.

The company changelog is one of several output types available through Fabric's self-writing docs. It produces a weekly record of what changed across the company, synthesised from pull requests, branch activity, and the broader context stored in Fabric's memory layer. The result reads like something a thoughtful person wrote, because the underlying model, Exabase M-1, was designed specifically for long-context understanding and recall. It ranks first on LongMemEval with a score of 96.4%, which means it can hold and reason over the full history of your project rather than treating each week in isolation.

Setup follows a guided wizard that connects your GitHub organisation and configures which repositories to track. Most teams are running within 24 hours. Once connected, Fabric watches for merged pull requests, new releases, and significant branch activity. It maps relationships between changes using its memory engine, understanding, for example, that a series of small pull requests across three repositories all relate to the same migration effort.

This cross-source synthesis is where Fabric differs most from simple commit-log parsers. If your team also connects Slack and meeting recordings, Fabric can draw on those sources to add context. A pull request that fixes a bug reported in a customer call gets richer annotation than one generated from the commit message alone. The connections layer supports this broader view without requiring any additional effort from your team.

What the output looks like

A Fabric-generated changelog entry typically includes a summary of the week's significant changes, grouped by theme or project rather than by repository. Related changes are linked together, so a reader can see that the new API endpoint, the updated documentation, and the client library bump are all part of the same feature release.

The tone is neutral and informative, closer to a well-written internal memo than to marketing copy. Technical details are preserved but presented in a way that product managers and designers can follow. If a change is purely mechanical (dependency updates, linting fixes), it is either omitted or summarised briefly rather than given equal weight alongside feature work.

Manual edits are preserved across regeneration cycles. If someone adds a note or corrects a detail, that edit persists even as new entries are generated. This matters because automated documents that overwrite human contributions quickly lose the trust of the team. Fabric treats your edits as authoritative, incorporating them into its understanding of the project for future entries.

Beyond the changelog: engineering documentation

The same mechanism that produces a changelog can generate other engineering documentation. Architecture decision records, API documentation, and migration notes all benefit from the same pattern of watching repository activity and synthesising it into readable documents. Teams that start with a changelog often expand into these other document types once they see the approach working.

This is worth noting because a changelog rarely exists in isolation. It is part of a broader documentation ecosystem, and the connections between documents matter. A changelog entry about a new authentication system should link to the architecture decision record that explains why the team chose that approach. Fabric's memory engine maintains these relationships automatically, creating a web of documentation that stays internally consistent as it grows.

Accessing your changelog where you work

A changelog is only useful if people read it. Fabric makes the generated content available through several channels beyond the web interface. Through MCP integration, your changelog and other documentation are accessible from Claude Code, Cursor, VS Code, and ChatGPT. An engineer working in their editor can query the changelog without switching context.

Agent access provides scoped, time-limited connections for tools like Instinct, Muse, and Claude. This means your CI pipeline or deployment tooling can reference the changelog programmatically, pulling in recent changes for release notes or deployment summaries. The access is controlled and auditable, so your documentation layer does not become an unmonitored open door.

For teams that live in Slack, Fabric Tag lets anyone ask questions about recent changes directly in a channel. A product manager can type a question like "what authentication changes shipped this week?" and get an answer drawn from the changelog and its source material. This turns the changelog from a document people have to go and read into a knowledge base they can query conversationally.

Security and pricing

Documentation that draws from your source code repositories needs to be handled carefully. Fabric uses AES-256 encryption and holds CASA Tier 2 certification. The GitHub connection operates through a secure gateway, and your data is not used to train models.

Pricing does not follow a per-seat model, which removes the friction that often prevents documentation tools from reaching the people who need them most. When access is not gated by individual licences, the support engineer, the product manager, and the new starter all have the same ability to read and query the changelog. Fabric also provides an infinite cloud drive, so storage constraints do not force you to archive or delete older entries.

Getting started

The path from "no changelog" to "self-maintaining changelog" is shorter than most teams expect. Connect your GitHub organisation through Fabric's guided setup wizard, select the repositories you want to track, and choose the company changelog as your output type. The first entry typically appears within a day, covering the most recent week of activity.

From there, the changelog maintains itself. Review the first few entries to confirm the tone and scope match your expectations, make any edits you want preserved, and let the system run. If you want to expand into broader engineering documentation or keep other team docs up to date automatically, the same connections and memory layer support those use cases without additional setup.

The best changelog is the one that exists six months from now, still current, still useful, still being read. Automation is what makes that possible.

Frequently asked questions

What sources does Fabric use to generate a changelog?

Fabric connects to your GitHub repositories and draws on pull requests, commit activity, release tags, and branch changes. If you also connect Slack and meeting recordings, it synthesises context from those sources too, producing richer entries than commit messages alone can support.

How long does setup take?

Most teams complete the guided setup wizard and have their first changelog entry within 24 hours. The process involves connecting your GitHub organisation, selecting repositories, and choosing the company changelog output type.

Will Fabric overwrite my manual edits?

No. Manual edits are preserved across regeneration cycles. If you correct a detail, add context, or adjust the framing of an entry, those changes persist in future versions. Fabric treats your edits as authoritative.

How does Fabric decide what to include in the changelog?

The memory engine maps relationships between changes and assigns significance based on scope, impact, and cross-repository patterns. Mechanical changes like dependency bumps are summarised briefly or omitted, while feature work, bug fixes, and architectural changes receive more detailed coverage.

Can I access the changelog from my code editor?

Yes. Through MCP integration, your changelog is available from Claude Code, Cursor, VS Code, and ChatGPT. You can query recent changes without leaving your development environment.

Is my source code data secure?

Fabric uses AES-256 encryption and holds CASA Tier 2 certification. The GitHub connection operates through a secure gateway, and your repository data is not used to train models.

Does Fabric charge per seat?

No. Fabric does not use per-seat pricing, which means everyone on your team can access the changelog and other generated documentation without individual licence constraints.

Can I generate other types of documentation from the same GitHub connection?

Yes. The same connection that powers the changelog can produce architecture decision records, API documentation, migration notes, and other engineering documentation. The memory engine maintains relationships between these documents automatically.

How does the company changelog differ from GitHub's release notes?

GitHub release notes are tied to individual repositories and typically list changes in a technical format. Fabric's company changelog synthesises activity across all connected repositories into a weekly narrative, grouped by theme or project, and written for a broader audience including product managers and support teams.

Can other tools and agents access the changelog programmatically?

Yes. Agent access provides scoped, time-limited connections for tools like Instinct, Muse, and Claude. This allows CI pipelines, deployment tooling, or other automated workflows to reference changelog data in a controlled and auditable way.

Related pages

• Self-writing docs

• GitHub integration

• Company changelog

• Engineering documentation

• Memory engine

• MCP integration

• Agent access

• The rise of self-writing documentation

• How to write documentation for a codebase automatically

• How to keep team documentation up to date automatically