Tenzir update docs
Coordinate documentation updates alongside code changes. Use when preparing the `.docs/` checkout, creating a matching docs branch, opening a `tenzir/content` documentation pull request, or cross-linking docs and code PRs. Also use when the user mentions "update the docs", "docs PR", ".docs/", or when a code change affects user-facing behavior that should be reflected in the documentation on tenzir.com.From its SKILL.md
npx -y skills add tenzir/skills --skill tenzir-update-docsAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 3 stars3 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.6 KB, as published. Nobody here has run it
Update Documentation
Handle the operational workflow around documentation changes. The docs live in
the tenzir/content repository (which also hosts the tenzir.com website)
under website/src/content/docs/.
Workflow
All docs changes take place in .docs/, which is a clone of tenzir/content.
Clone .docs if it doesn't exist. Otherwise fetch the latest refs from origin.
- Create or check out a topic branch in
.docs/that matches the parent repo branch name. - Author the content update under
website/src/content/docs/using the repository's own documentation guidance and conventions (read itswebsite/README.mdfirst). - Run relevant documentation checks if the repository provides them
(
bun run checkinwebsite/). - File a
tenzir/contentpull request from.docs/. - Cross-link the pull requests using one shared compact footer pattern:
- In the docs PR, append a final
<sub>...</sub>footer block that links the code PR and references the same Linear issue(s), for example⚙️ Code PR: tenzir/tenzir#6048<br>🎫 References TNZ-150, TNZ-151. - In the code PR, append or extend the final
<sub>...</sub>footer with📚 Docs PR: tenzir/content#261. - Use GitHub shorthand for PR links in both directions, such as
tenzir/tenzir#6048ortenzir/content#261, instead of full URLs. Use full URLs only for deep links that shorthand cannot express, such as a specific comment. - If a footer already exists, add another
<br>-separated line instead of creating a second footer.
- In the docs PR, append a final
- Apply the
automergelabel to the docs PR. This marks the companion PR as ready for CI to squash-merge after the linked code PR lands and the docs checks pass. - Summarize what changed and note any follow-up work.
Branching
Keep the .docs/ branch name aligned with the code branch whenever possible.
If the code change spans multiple repositories, use the code branch as the
source of truth for naming and cross-links.
PR cross-link format
Keep docs/code cross-links in a compact footer at the end of each PR
description. In the docs PR footer, reference the same Linear issue(s) with a
non-closing word such as references so the companion docs PR does not move
the issue independently. When multiple issues share the same relationship,
enumerate them after one magic word on one line to keep the footer compact.
Use separate lines only when the relationship differs.
Docs PR example:
<sub>
⚙️ Code PR: tenzir/tenzir#1234<br>
🎫 References TNZ-150, TNZ-151
</sub>
Code PR example:
<sub>
📚 Docs PR: tenzir/content#261<br>
✅ Closes TNZ-150, TNZ-151<br>
📎 Related: tenzir/tenzir#5999
</sub>
Cross-Checks
Before opening the docs PR:
- Confirm the changed pages still fit their Diataxis section.
- Check nearby pages and "See also" links for follow-on edits. Reserve "See also" for related guides, tutorials, integrations, and broader references. Link individual operators inline where they are relevant instead of listing them in "See also".
- Ensure code samples, paths, and UI labels match the current product behavior.