update-documentation
>-
Works with
---
name: update-documentation
description: >-
license: Apache-2.0
---
# Update Documentation
Handle the operational workflow around docs.tenzir.com changes.
## Workflow
1. Ensure `.docs/` exists and is up to date by cloning `tenzir/docs` or
fetching from `origin`.
2. Create or check out a topic branch in `.docs/` that matches the parent repo
branch name.
3. Author the content update in `.docs/` using the docs repository's own
documentation guidance and conventions.
4. Run relevant documentation checks if the docs repository provides them.
5. File a `tenzir/docs` pull request from `.docs/`.
6. 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#6048` or `tenzir/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 PR` or `Docs PR`
sections. If a footer already exists, add another `<br>`-separated line
instead of creating a second footer.
7. 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:
```markdown
<sub>
⚙️ Code PR: tenzir/tenzir#1234<br>
🎫 References TNZ-150, TNZ-151
</sub>
```
Code PR example:
```markdown
<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:
1. Confirm the changed pages still fit their Diataxis section.
2. Check nearby pages and "See also" links for follow-on edits.
3. Ensure code samples, paths, and UI labels match the current product
behavior.More Writing & Documentation skills
paper-context-resolver
lllllllama/rigorpilot-skills
Rigor Paper Context helper for README-first deep learning repo reproduction. Use only when the README and repository files leave a narrow reproduction-critical gap and the task is to resolve a specific paper detail such as dataset split, preprocessing, evaluation protocol, checkpoint mapping, or runtime assumption from primary paper sources while recording conflicts. Do not use for general paper summary, repo scanning, environment setup, command execution, title-only paper lookup, or replacing README guidance by default.
repo-intake-and-plan
lllllllama/rigorpilot-skills
Rigor Intake helper for README-first deep learning repo reproduction. Use when the task is specifically to scan a repository, read the README and common project files, extract documented commands, classify inference, evaluation, and training candidates, and return the smallest trustworthy reproduction plan to the main orchestrator. Do not use for environment setup, asset download, command execution, final reporting, paper lookup, or end-to-end orchestration.
minimal-run-and-audit
lllllllama/rigorpilot-skills
Rigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation command and write standardized `repro_outputs/` files, including patch notes when repository files changed. Do not use for training execution, initial repo intake, generic environment setup, paper lookup, target selection, hidden scientific-meaning changes, or end-to-end orchestration by itself.

