Update Docs From Commits

Update Docs from Commits

Scan recent git history for commits that affect user-facing behavior and draft documentation updates for each.

Prerequisites

• You must be in the OpenShell git repository.
• The published docs tree must exist under docs/.
• Read docs/CONTRIBUTING.mdx before writing any content. It contains the current style guide and formatting rules.

When to Use

• After a batch of features or fixes has landed and docs may be stale.
• Before a release, to catch any doc gaps.
• When a contributor asks "what docs need updating?"

Step 1: Identify Relevant Commits

Determine the commit range. The user may provide one explicitly (e.g., "since v0.2.0" or "last 30 commits"). If not, default to commits since the head of the main branch.

# Commits since a tag
git log v0.2.0..HEAD --oneline --no-merges

# Or last 50 commits
git log -50 --oneline --no-merges

Filter to commits that are likely to affect docs. Look for these signals:

1. Commit type: feat, fix, refactor, perf commits often change behavior. docs commits are already doc changes. chore, ci, test commits rarely need doc updates.
2. Files changed: Changes to crates/openshell-cli/, python/, proto/, deploy/, gateway config parsing, driver config structs, or policy-related code are high-signal.
3. Ignore: Changes limited to tests/, e2e/, .github/, tasks/, or internal-only modules.

# Show files changed per commit to assess impact
git log v0.2.0..HEAD --oneline --no-merges --name-only

Step 2: Map Commits to Doc Pages

For each relevant commit, determine which doc page(s) it affects. Use this mapping as a starting point:

If a commit does not map to any existing page but introduces a user-visible concept, flag it as needing a new page.

Step 3: Read the Commit Details

For each commit that needs a doc update, read the full diff to understand the change:

git show <commit-hash> --stat
git show <commit-hash>

Extract:

• What changed (new flag, renamed command, changed default, new feature).
• Why it changed (from the commit message body, linked issue, or PR description).
• Any breaking changes or migration steps.

Step 4: Read the Current Doc Page

Before editing, read the full target doc page to understand its current content and structure:

# Read the file

Identify where the new content should go. Follow the page's existing structure.

Step 5: Draft the Update

Write the smallest update that tells users exactly what changed and what they need to do. Prefer updating one authoritative page and linking to it over repeating explanations across pages. Omit exhaustive internal details unless they directly affect a user decision or workflow. Follow docs/CONTRIBUTING.mdx. Key reminders:

• Active voice, present tense, second person.
• No unnecessary bold. Reserve bold for UI labels and parameter names.
• No em dashes unless used sparingly. Prefer commas or separate sentences.
• Start sections with an introductory sentence that orients the reader.
• No superlatives. Say what the feature does, not how great it is.
• Code examples use shell language for copyable commands, with no $ prompt prefix.
• Use text fences for transcripts, logs, or shell sessions that should not be copied verbatim.
• Include the SPDX header as YAML comments in frontmatter if creating a new page.
• Match existing Fern frontmatter format if creating a new page, including sidebar-title, keywords, and position when they are relevant. Use frontmatter slug only for folder-discovered pages or absolute URL overrides.
• Use sidebar-title for short nav labels. For explicit navigation entries, keep relative slug values in docs/index.yml instead of page frontmatter.
• Keep explicit page: entries in docs/index.yml. Fern still requires them. If the page defines sidebar-title, set page: to that value. Otherwise set page: to the page frontmatter title.
• Use skip-slug: true in docs/index.yml when a child page should live at the parent section path.
• Keep each page URL equal to its file path under docs/. Rename the file when you rename a page, add a fern/docs.yml redirect for the old URL, and set a relative slug: when the nav label does not produce the file name. mise run docs runs docs:nav, which fails otherwise.
• Use keywords as a comma-separated string.
• Do not add a duplicate H1. Fern renders the page title from frontmatter.
• Always write NVIDIA in all caps. Wrong: Nvidia, nvidia.
• Always capitalize OpenShell correctly. Wrong: openshell, Openshell, openShell.
• Do not number section titles. Wrong: "Section 1: Deploy a Gateway" or "Step 3: Verify." Use plain descriptive titles.
• No colons in titles. Wrong: "Gateways: Deploy and Manage." Write "Deploy and Manage Gateways" instead.
• Use colons only to introduce a list. Do not use colons as general-purpose punctuation between clauses.