|
| 1 | +--- |
| 2 | +name: update-docs-from-commits |
| 3 | +description: Scan recent git commits for changes that affect user-facing behavior, then draft or update the corresponding documentation pages. Use when docs have fallen behind code changes, after a batch of features lands, or when preparing a release. Trigger keywords - update docs, draft docs, docs from commits, sync docs, catch up docs, doc debt, docs behind, docs drift. |
| 4 | +--- |
| 5 | + |
| 6 | +# Update Docs from Commits |
| 7 | + |
| 8 | +Scan recent git history for commits that affect user-facing behavior and draft documentation updates for each. |
| 9 | + |
| 10 | +## Prerequisites |
| 11 | + |
| 12 | +- You must be in the OpenShell git repository. |
| 13 | +- The published docs tree must exist under `docs/`. |
| 14 | +- Read `docs/CONTRIBUTING.mdx` before writing any content. It contains the current style guide and formatting rules. |
| 15 | + |
| 16 | +## When to Use |
| 17 | + |
| 18 | +- After a batch of features or fixes has landed and docs may be stale. |
| 19 | +- Before a release, to catch any doc gaps. |
| 20 | +- When a contributor asks "what docs need updating?" |
| 21 | + |
| 22 | +## Step 1: Identify Relevant Commits |
| 23 | + |
| 24 | +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. |
| 25 | + |
| 26 | +```bash |
| 27 | +# Commits since a tag |
| 28 | +git log v0.2.0..HEAD --oneline --no-merges |
| 29 | + |
| 30 | +# Or last 50 commits |
| 31 | +git log -50 --oneline --no-merges |
| 32 | +``` |
| 33 | + |
| 34 | +Filter to commits that are likely to affect docs. Look for these signals: |
| 35 | + |
| 36 | +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. |
| 37 | +2. **Files changed**: Changes to `crates/openshell-cli/`, `python/`, `proto/`, `deploy/`, or policy-related code are high-signal. |
| 38 | +3. **Ignore**: Changes limited to `tests/`, `e2e/`, `.github/`, `tasks/`, or internal-only modules. |
| 39 | + |
| 40 | +```bash |
| 41 | +# Show files changed per commit to assess impact |
| 42 | +git log v0.2.0..HEAD --oneline --no-merges --name-only |
| 43 | +``` |
| 44 | + |
| 45 | +## Step 2: Map Commits to Doc Pages |
| 46 | + |
| 47 | +For each relevant commit, determine which doc page(s) it affects. Use this mapping as a starting point: |
| 48 | + |
| 49 | +| Code area | Likely doc page(s) | |
| 50 | +|---|---| |
| 51 | +| `crates/openshell-cli/` (gateway commands) | `docs/sandboxes/manage-gateways.mdx` | |
| 52 | +| `crates/openshell-cli/` (sandbox commands) | `docs/sandboxes/manage-sandboxes.mdx` | |
| 53 | +| `crates/openshell-cli/` (provider commands) | `docs/sandboxes/manage-providers.mdx` | |
| 54 | +| `crates/openshell-cli/` (new top-level command) | May need a new page or `docs/reference/` entry | |
| 55 | +| Proxy or policy code | `docs/sandboxes/policies.mdx`, `docs/reference/policy-schema.mdx` | |
| 56 | +| Inference code | `docs/inference/configure.mdx` | |
| 57 | +| `python/` (SDK changes) | `docs/reference/` or `docs/get-started/quickstart.mdx` | |
| 58 | +| `proto/` (API changes) | `docs/reference/` | |
| 59 | +| `deploy/` (Dockerfile, Helm) | `docs/sandboxes/manage-gateways.mdx`, `docs/about/architecture.mdx` | |
| 60 | +| Community sandbox definitions | `docs/sandboxes/community-sandboxes.mdx` | |
| 61 | + |
| 62 | +If a commit does not map to any existing page but introduces a user-visible concept, flag it as needing a new page. |
| 63 | + |
| 64 | +## Step 3: Read the Commit Details |
| 65 | + |
| 66 | +For each commit that needs a doc update, read the full diff to understand the change: |
| 67 | + |
| 68 | +```bash |
| 69 | +git show <commit-hash> --stat |
| 70 | +git show <commit-hash> |
| 71 | +``` |
| 72 | + |
| 73 | +Extract: |
| 74 | + |
| 75 | +- What changed (new flag, renamed command, changed default, new feature). |
| 76 | +- Why it changed (from the commit message body, linked issue, or PR description). |
| 77 | +- Any breaking changes or migration steps. |
| 78 | + |
| 79 | +## Step 4: Read the Current Doc Page |
| 80 | + |
| 81 | +Before editing, read the full target doc page to understand its current content and structure: |
| 82 | + |
| 83 | +```bash |
| 84 | +# Read the file |
| 85 | +``` |
| 86 | + |
| 87 | +Identify where the new content should go. Follow the page's existing structure. |
| 88 | + |
| 89 | +## Step 5: Draft the Update |
| 90 | + |
| 91 | +Write the doc update following the rules in `docs/CONTRIBUTING.mdx`. Key reminders: |
| 92 | + |
| 93 | +- **Active voice, present tense, second person.** |
| 94 | +- **No unnecessary bold.** Reserve bold for UI labels and parameter names. |
| 95 | +- **No em dashes** unless used sparingly. Prefer commas or separate sentences. |
| 96 | +- **Start sections with an introductory sentence** that orients the reader. |
| 97 | +- **No superlatives.** Say what the feature does, not how great it is. |
| 98 | +- **Code examples use `shell` language** for copyable commands, with no `$` prompt prefix. |
| 99 | +- **Use `text` fences** for transcripts, logs, or shell sessions that should not be copied verbatim. |
| 100 | +- **Include the SPDX header as YAML comments in frontmatter** if creating a new page. |
| 101 | +- **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. |
| 102 | +- **Use `sidebar-title` for short nav labels**. For explicit navigation entries, keep relative `slug` values in `docs/index.yml` instead of page frontmatter. |
| 103 | +- **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`. |
| 104 | +- **Use `skip-slug: true` in `docs/index.yml`** when a child page should live at the parent section path. |
| 105 | +- **Use `keywords` as a comma-separated string**. |
| 106 | +- **Do not add a duplicate H1**. Fern renders the page title from frontmatter. |
| 107 | +- **Always write NVIDIA in all caps.** Wrong: Nvidia, nvidia. |
| 108 | +- **Always capitalize OpenShell correctly.** Wrong: openshell, Openshell, openShell. |
| 109 | +- **Do not number section titles.** Wrong: "Section 1: Deploy a Gateway" or "Step 3: Verify." Use plain descriptive titles. |
| 110 | +- **No colons in titles.** Wrong: "Gateways: Deploy and Manage." Write "Deploy and Manage Gateways" instead. |
| 111 | +- **Use colons only to introduce a list.** Do not use colons as general-purpose punctuation between clauses. |
| 112 | + |
| 113 | +When updating an existing page: |
| 114 | + |
| 115 | +- Add content in the logical place within the existing structure. |
| 116 | +- Do not reorganize sections unless the change requires it. |
| 117 | +- Update any cross-references or "Next Steps" links if relevant. |
| 118 | + |
| 119 | +When creating a new page: |
| 120 | + |
| 121 | +- Follow the frontmatter template from `docs/CONTRIBUTING.mdx`. |
| 122 | +- Add the page to the appropriate section in `docs/index.yml`. |
| 123 | + |
| 124 | +## Step 6: Present the Results |
| 125 | + |
| 126 | +After drafting all updates, present a summary to the user: |
| 127 | + |
| 128 | +``` |
| 129 | +## Doc Updates from Commits |
| 130 | +
|
| 131 | +### Updated pages |
| 132 | +- `docs/sandboxes/manage-gateways.mdx`: Added `--gpu` flag documentation (from commit abc1234). |
| 133 | +- `docs/reference/policy-schema.mdx`: Updated network policy schema for new `tls_inspect` field (from commit def5678). |
| 134 | +
|
| 135 | +### New pages needed |
| 136 | +- None (or list any new pages created). |
| 137 | +
|
| 138 | +### Commits with no doc impact |
| 139 | +- `chore(deps): bump tokio` (abc1234) — internal dependency, no user-facing change. |
| 140 | +- `test(e2e): add gateway timeout test` (def5678) — test-only change. |
| 141 | +``` |
| 142 | + |
| 143 | +## Step 7: Build and Verify |
| 144 | + |
| 145 | +After making changes, validate the Fern docs locally: |
| 146 | + |
| 147 | +```bash |
| 148 | +mise run docs |
| 149 | +``` |
| 150 | + |
| 151 | +If a human needs to inspect rendering while iterating, they can also run: |
| 152 | + |
| 153 | +```bash |
| 154 | +mise run docs:serve |
| 155 | +``` |
| 156 | + |
| 157 | +Check for: |
| 158 | + |
| 159 | +- Validation warnings or errors. |
| 160 | +- Broken cross-references. |
| 161 | +- Correct rendering of new content in the PR preview when available. |
| 162 | + |
| 163 | +## Tips |
| 164 | + |
| 165 | +- When in doubt about whether a commit needs a doc update, check if the commit message references a CLI flag, config option, or user-visible behavior. |
| 166 | +- Group related commits that touch the same doc page into a single update rather than making multiple small edits. |
| 167 | +- If a commit is a breaking change, add a note at the top of the relevant section using a Fern `<Warning>` callout. |
| 168 | +- PRs that are purely internal refactors with no behavior change do not need doc updates, even if they touch high-signal directories. |
| 169 | + |
| 170 | +## Example Usage |
| 171 | + |
| 172 | +User says: "Catch up the docs for everything merged since v0.2.0." |
| 173 | + |
| 174 | +1. Run `git log v0.2.0..HEAD --oneline --no-merges --name-only`. |
| 175 | +2. Filter to `feat`, `fix`, `refactor`, `perf` commits touching user-facing code. |
| 176 | +3. Map each to a doc page. |
| 177 | +4. Read the commit diffs and current doc pages. |
| 178 | +5. Draft updates following the style guide. |
| 179 | +6. Present the summary. |
| 180 | +7. Run `mise run docs` to verify. |
0 commit comments