Documentation from work you are already doing.

Every merge produces docs.
Fabric watches your repositories and reads every merged pull request. It understands what changed, why it changed, and how it affects the broader system. Then it creates or updates the relevant documentation. Your engineers do not change how they work. They merge PRs the way they always have, and docs appear.

Architecture decisions captured.
When a PR introduces a significant architectural change, Fabric documents it as a decision record. The reasoning behind the change, the alternatives considered (if discussed in the PR or linked Slack threads), and the final approach are all recorded. Six months later, when someone asks why the system works this way, the answer exists.

API changes tracked.
New endpoints, changed parameters, deprecated methods, and breaking changes are documented as they ship. Your API documentation stays in sync with your codebase because it updates from the same PRs that change the code.

More than a PR summary.

Context from multiple sources.
Fabric does not just read the PR in isolation. It connects the code change to related Slack discussions, meeting decisions, and existing documentation in your workspace. A PR that implements a decision made in a Slack thread last Tuesday gets documented with that full context, not just the diff.

Cumulative understanding.
Fabric builds a picture of your system over time. Early PRs establish the baseline documentation. Subsequent PRs update and refine it. After a few weeks, you have documentation that reflects the current state of your codebase, assembled incrementally from the work your team has done. It is not a one-time snapshot. It is a living document that evolves with every deploy.

Migration and dependency notes.
Framework upgrades, dependency bumps, database migrations, and infrastructure changes are documented automatically. The kind of context that is critical during incidents or when onboarding new engineers, but that nobody ever writes down because the PR was merged and everyone moved on.

The knowledge buried in your PRs.

Pull requests are where engineering decisions are made and recorded. The PR description explains why a change was made. The code review discussion captures trade-offs, concerns, and agreements. The diff itself shows exactly what changed. Together, a PR contains more technical context than most documentation pages. The problem is that PRs are ephemeral. They are reviewed, approved, merged, and then they scroll off the page. Within a week, the knowledge in that PR is effectively lost unless someone goes looking for it specifically.

Fabric treats PRs as a primary source of engineering knowledge rather than a transient workflow artifact. Every merge is analyzed for documentation-worthy content. Architecture decisions, API changes, system behavior modifications, and infrastructure updates are extracted and filed as structured documentation in your Fabric workspace. The result is an engineering knowledge base that assembles itself from the work your team is already doing, without asking anyone to write a single doc.

Documentation that keeps up with your codebase.

The fundamental problem with engineering documentation is that it goes stale the moment someone makes a change and does not update the docs. This happens constantly because updating docs is a separate task from shipping code, and shipping code always takes priority. By connecting documentation directly to the source of changes, Fabric eliminates the gap. When the code changes, the docs change. There is no separate step, no Jira ticket for documentation, and no guilt about the wiki page that nobody updated.

This is particularly valuable for teams practicing continuous delivery where code ships frequently. The faster you deploy, the faster traditional documentation falls behind. With Fabric, the documentation velocity matches your deployment velocity because they come from the same source. A team shipping multiple times a day produces documentation that updates multiple times a day.

Onboarding that reflects reality.

One of the highest-value outputs of PR-sourced documentation is what it does for onboarding. New engineers typically spend their first weeks reading outdated docs, asking questions that have been answered dozens of times, and piecing together how the system works from scattered sources. When your documentation is assembled from actual PRs, new hires read docs that reflect the current state of the codebase because they were updated by the last merge, not the last documentation sprint six months ago.

Combined with decision logs from Slack and meetings, new engineers get both the what (from PRs) and the why (from discussions). They can understand not just how the system works today but how it got here, which decisions were made along the way, and what constraints shaped the current architecture.

What gets documented from your PRs.

Architecture decisions
Significant structural changes documented as decision records with context, reasoning, and outcomes. Searchable by your AI assistant when someone needs to understand why a system was built a certain way.

API documentation
New endpoints, parameter changes, deprecations, and breaking changes documented as they ship. Stays in sync with your codebase without a separate API docs workflow.

Migration notes
Framework upgrades, dependency changes, database migrations, and infrastructure modifications documented with context about what changed and why.

System overviews
Cumulative documentation that builds a picture of your system's architecture, components, and behavior. Updated incrementally with every relevant PR rather than written from scratch periodically.

Company changelog
Technical changes feed into a broader company changelog that records what changed across the organization each week.

Use cases

Engineering documentation
Build and maintain a comprehensive engineering knowledge base from your development workflow. Architecture docs, API references, and system overviews that stay current with every merge.

New engineer onboarding
Give new hires documentation that reflects the actual current state of your systems. Combined with context from Slack and meetings, new engineers get a complete picture of what was built and why. See how Fabric supports onboarding.

Incident response
When something breaks, your team can search documentation assembled from the PRs that changed the relevant system. Find what changed, when, and why without digging through git history manually.

Technical due diligence
Investors, acquirers, or partners reviewing your technology get documentation that is accurate and comprehensive because it was assembled from your actual development activity, not a rushed write-up.

Perfect for

Startups
Ship fast without sacrificing documentation. Your engineering docs keep up with your pace of development because they are assembled from the PRs you are already merging. Learn more about Fabric for startups.

Engineering teams practicing CI/CD
The faster you deploy, the more value PR-sourced documentation provides. Multiple deploys a day means documentation that updates multiple times a day.

Growing teams
Every new engineer added to the team benefits from documentation assembled from every PR that came before them. The knowledge base compounds as the team grows. Learn more about Fabric for teams.

Open source maintainers
Documentation that stays current with contributions. Merged PRs from external contributors are documented the same way as internal ones, building a knowledge base that helps future contributors understand the project.

Works seamlessly with other features.

Slack and Discord context
PR documentation is enriched with context from related Slack and Discord discussions. Decisions made in chat that led to a PR are connected to the documentation that PR produces.

Meeting decisions
Technical decisions from meetings are linked to the PRs that implement them. The documentation captures both the decision and its implementation.

Smart search
All PR-sourced documentation is searchable alongside your other content. Find architecture decisions, API changes, and migration notes through natural language queries.

AI assistant
Ask your AI assistant about any documented change. It can reference PR-sourced documentation, cite when changes were made, and explain the reasoning behind architectural decisions.

FAQ

How does Fabric connect to GitHub?
Connect your GitHub organization or repositories through Fabric's setup wizard. Fabric uses standard OAuth authentication and only accesses the repositories you authorize. See the connections marketplace for setup details.

Does Fabric read every PR?
Fabric reads every merged PR in your connected repositories. It analyzes the content to identify documentation-worthy changes and creates or updates docs accordingly. Draft PRs and open PRs are not processed until they are merged.

What about PR review comments and discussions?
Yes. Fabric reads the PR description, review comments, and discussion threads. Context from code review is included in the documentation, capturing trade-offs and decisions made during the review process.

Does it work with monorepos?
Yes. Fabric can process PRs from monorepos and understand which parts of the codebase were affected. Documentation is organized by system or component rather than by repository structure.

Can I exclude certain repositories or types of PRs?
Yes. During setup you choose which repositories to watch, and you can configure filters to exclude certain types of changes that do not need documentation, like dependency bot PRs or formatting changes.

How quickly do docs update after a merge?
Documentation typically updates within hours of a PR being merged. For teams merging frequently, updates may batch to avoid excessive churn in the documentation.

What if the PR description is sparse?
Fabric reads the code diff, file changes, and any linked discussions in addition to the PR description. Even PRs with minimal descriptions produce useful documentation because Fabric understands what the code change does.

Can my team edit the docs Fabric produces from PRs?
Yes. All produced docs are full Fabric documents that your team can edit, annotate, and collaborate on. Manual edits are preserved when Fabric updates the docs with new PR activity.

How is this different from auto-generated code docs like JSDoc?
Code documentation tools document the API surface of your code: function signatures, parameters, return types. Fabric documents the knowledge behind your code: why decisions were made, how systems fit together, what changed and when. They are complementary. JSDoc tells you what a function does. Fabric tells you why it exists.

Which plans include GitHub integration for self-writing docs?
Self-writing docs with GitHub is available on Team plans. See team pricing for details.