# Share SpecFlow LivingDoc — Feature Files the Business Can Open

Canonical: https://commareports.com/share-specflow-livingdoc
Published: 2026-09-14

> LivingDoc builds one self-contained HTML file of your features with test results folded in. Publish it to Comma so the people who wrote the scenarios can actually read them.

# Share SpecFlow LivingDoc

BDD's premise is that the scenarios are readable by the people who define the
behaviour. In practice the scenarios live in `.feature` files in a repository
those people cannot open, which quietly reduces Gherkin to an unusually verbose
test syntax.

LivingDoc is the part that was supposed to close that loop: one HTML file
containing every feature, every scenario, the example tables, and — if you feed
it the execution results — whether each one currently passes.

```bash
dotnet tool install --global SpecFlow.Plus.LivingDoc.CLI

livingdoc test-assembly bin/Debug/net8.0/MyTests.dll \
  -t bin/Debug/net8.0/TestExecution.json \
  -o LivingDoc.html
```

On **Reqnroll** — the maintained continuation of SpecFlow — the generator is the
same and so is the output: a single self-contained document.

## The file is the easy part

Then it goes into a CI artifact, which needs a login and expires on a retention
schedule, and the product owner who asked "does the trial expiry scenario cover
annual plans?" gets a screenshot of two lines of Gherkin.

Drop `LivingDoc.html` into [Comma](https://commareports.com/) and it is a URL.
Self-contained, so there is nothing to zip and nothing to break in transit.

```bash
curl -fsS -X PATCH "https://commareports.com/api/v1/reports/$REPORT_ID" \
  -H "Authorization: Bearer $COMMA_API_TOKEN" \
  -H "Content-Type: application/json" \
  -d "$(jq -n --rawfile html LivingDoc.html \
        --arg t "Behaviour — $BUILD_BUILDNUMBER" '{title: $t, html: $html}')"
```

Scripts run inside a sandboxed iframe (`allow-scripts`, no `allow-same-origin`),
so LivingDoc's feature tree, tag filters and search keep working at the
published URL. See the [API reference](/docs/api) and
[publishing from CI](/docs/ci).

## Who it is actually for

The audience for this document is not the team that wrote it. It is:

- the product owner checking that the scenarios match what they asked for,
- the support lead looking for the documented behaviour of an edge case,
- the auditor who wants evidence that the stated requirement is tested.

None of them have a CI login, and none of them are going to get one. A link,
with access set to _anyone signed in at your domain_, covers all three — see
[sharing & access control](/docs/sharing).

## Comments are the feedback loop BDD promised

The value of living documentation is not that it is generated; it is that the
non-engineers reading it can push back. Anchored threads put "this Given is
wrong" on the Given. The scenario gets fixed in the `.feature` file, the next
run republishes, and the thread is still there next to the corrected step. See
[commenting on HTML](/comment-on-html).

A revision per run also answers the question release notes never do: which
scenarios changed between these two builds.

## Limits

- **Entry HTML: 5 MB.** LivingDoc inlines everything, so a very large suite can
  approach it — generate per feature folder, or drop the images from
  screenshot-attaching steps.
- Assets: 25 MB per file, **250 MB and 500 files total**.
- **60 requests/minute per token.**

## Try it

Comma is free — unlimited reports, unlimited commenters, unlimited revision
history.

**[Publish living documentation →](https://commareports.com/)**

### Related

- [Share a Cucumber report](/share-cucumber-report) · [Share a Behave report](/share-behave-report)
- [Share a NUnit report](/share-nunit-report) · [Share an xUnit report](/share-xunit-report)
- [Share a .NET coverage report](/share-dotnet-coverage-report) · [Share a Serenity report](/share-serenity-report)