Documents, Git & History

Running the story cycle produces a steady stream of artifacts — story specs, a PRD, an architecture, git branches, LLM conversations. BMAD Board gives each of these a home so nothing gets lost between sessions. This page covers the four surfaces that hold your project's memory: the Documents view, Git integration, Session History, and Settings.

Documents

The Documents view is where you read and edit the artifacts the BMAD method produces — without leaving the visual cockpit for a separate editor.

Browse your planning and implementation artifacts: the product brief, PRD, architecture, epics, and per-story spec files under _bmad-output/.
Read them with proper Markdown rendering — headings, tables, and code blocks laid out cleanly, not raw text.
Edit them in place when a plan needs a tweak.

Automatic file versioning

Editing a plan should never feel risky, so the board keeps a safety net under every change. Before it overwrites a file, it snapshots the current version.

A snapshot is taken automatically every time you save over an existing file — you don't have to remember to do anything.
The board keeps roughly the last 20 versions of each file.
Restoring is one click: pick an earlier version and roll the file back.

Tip: Versioning means you can edit a PRD or a story spec freely. Changed your mind, or an agent rewrote too much? Open the file's history and restore the version you want. Nothing is lost quietly.

Git

BMAD Board includes a full git client — the everyday git operations you'd otherwise run in a shell, available in the app: staging, committing, branches, diffs, and more. But its most important idea is how it isolates each story's work.

Worktrees: one story, one branch, no collisions

When your hybrid team builds several stories in a sprint, you don't want their changes tangled together in one working directory. BMAD Board's answer is git worktrees, and they are the default substrate for story work.

A worktree is a separate working copy of your repository, checked out to its own branch, sharing the same underlying git history. BMAD Board gives each story its own worktree on its own branch — so:

Story work happens in isolation. Two stories in flight never overwrite each other's files.
The mapping is deterministic: a story resolves to the same branch and worktree path every time.
Your main working directory stays clean while agents work off to the side.

This is why the implementation phase can run stories in parallel without chaos — each one lives on its own branch until it's merged.

Dead worktrees clean themselves up

Worktrees accumulate as stories come and go, so the board tidies up after itself. When a story's worktree is finished with — its work landed or abandoned, the tree clean and safe to remove — the board automatically reclaims it. The cleanup is conservative by design: it only reclaims worktrees that are provably safe to remove, it skips anything with uncommitted or locked changes, and it always keeps the branch. You get the tidiness without the risk, and without a prompt to click.

Note: Automatic reclaim removes the worktree (the extra working copy), not your git branch or its commits. Your history is never touched.

Session History

Every time you launch a coding agent, that's a session — a conversation and a run of work. Session History records those sessions per story, so the work an agent did is never a one-time event you can't get back to.

Recorded per story. Each story keeps its own trail of the sessions run against it.
Resumable. You can pick a past LLM session back up and continue it, rather than starting cold.

This pairs directly with how phases behave in the story cycle. Recall from implementation that clicking Backlog or Ready auto-resumes a story's prior session, while In Progress and Review start a fresh one on purpose. Session History is the ledger behind that behavior — and the place to reopen an older session by hand when you want to.

Note: Session resume depends on the provider. Claude Code supports resuming a session by id; several other CLIs don't, so for those the board starts a new run each time. See terminal & providers for the per-provider details.

Settings

Settings is where you configure the board to your setup:

LLM providers — set your default coding agent and any per-skill overrides, so the right agent runs the right command. (The provider chain is explained in terminal & providers.)
Theme — light or dark, to taste.
Other app preferences.

App-wide preferences are stored in Electron's userData directory (for example, preferences.json), so they follow you across projects.

Where your project data lives

Anything specific to a single project — session history, phase history, intake state — lives inside that project, under:

<project>/.bmad-board/

Keeping this data next to the code means it travels with the repository and stays scoped to the project it belongs to. Your BMAD artifacts, meanwhile, stay where the method puts them, under _bmad-output/, and the tooling itself under _bmad/.