contribute-docs

# Contribute Docs Or Examples ## Companion Guidance Use `karpathy-guidelines` alongside this skill for implementation or review work. Keep changes scoped, surface assumptions, and define focused validation before editing. Use this skill for docs-only or example-heavy changes. ## Rules - Prefer the documented public API, not internal shortcuts - Keep package names, repo references, and build commands current - When documenting contribution workflow, require an issue before external contribution PRs and note that NVIDIA contributors may use a GitHub or Linear issue. - Update entry-point docs when examples or reading paths change - Keep release-process and release-notes guidance in repo-maintainer docs such as `RELEASING.md`, not as user-facing docs pages or `CHANGELOG.md` - Keep stable user-facing wrappers at `scripts/` root in docs and examples; only point at namespaced helper paths when documenting internal maintenance work - When detailed dynamic plugin guides exist, keep Rust native plugin examples, Python worker plugin examples, and `grpc-v1` protocol details on separate pages. - Dynamic plugin manifests must exclude Relay versions before 0.8. Recommend `compat.relay = ">=0.8.0,<1.0"`; open-ended or narrower 0.8-or-newer ranges are valid when intentional. - In MDX files, top-of-file comments must use JSX comment delimiters: `{/*` to open and `*/}` to close. Do not use HTML comments for MDX SPDX headers. - Render images, diagrams, tables, and other vi...