About update-documentation
A skill for handling the documentation workflow around docs.tenzir.com changes, aimed at Tenzir contributors working across code and docs. It covers preparing the docs repository, branching, checks, and cross-linking code and documentation pull requests.
Key features
- 01Sync or clone tenzir/docs into .docs/
- 02Align documentation and code branch names
- 03Write to docs conventions and run checks
- 04Create docs PRs and cross-link code PRs
- 05Check page placement, links, and code samples
Use cases
- 01Update docs alongside a code change
- 02Prepare a documentation PR on a matching branch
- 03Review doc changes and identify related pages to edit
Install
Copy the command and run it in a terminal.
npx skills add https:/ / github.com/ tenzir/ skills --skill update-documentationAfter installing, type/update-documentationin Claude Code to confirm it loaded.
Details
From the project READMEUpdate Documentation
Handle the operational workflow around docs.tenzir.com changes.
Workflow
- Ensure
.docs/exists and is up to date by cloningtenzir/docsor fetching fromorigin. - Create or check out a topic branch in
.docs/that matches the parent repo branch name. - Author the content update in
.docs/using the docs repository's own documentation guidance and conventions. - Run relevant documentation checks if the docs repository provides them.
- File a
tenzir/docspull 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/docs#261. - Use GitHub shorthand for PR links in both directions, such as
tenzir/tenzir#6048ortenzir/docs#261, instead of full URLs. Use full URLs only for deep links that shorthand cannot express, such as a specific comment. - Prefer that footer over dedicated
Code PRorDocs PRsections. If a footer already exists, add another<br>-separated line instead of creating a second footer.
- In the docs PR, append a final
- 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/docs#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.
- Ensure code samples, paths, and UI labels match the current product behavior.