update-documentation

>-

tenzir/skills46 installsApache-2.0Synced Aug 26

Works with

Claude CodeCursorCodex CLIGitHub CopilotGemini CLI
---
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.

450.8k

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.

450.0k

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.

449.9k

← All Writing & Documentation skills

Check your AI visibility

One URL in, a 0–100 score and the exact fixes out.

RUN THE CHECK

Browse all the tools

15 tools across six categories
13 of them never send your data anywhere

Free · No signup · No trial clock

SEE THE DIRECTORY