How do I install the Documentation Workflow skill?

Run npx skillmds@latest add tomevault-io/documentation-workflow in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Documentation Workflow safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Documentation Workflow?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Documentation Workflow free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Documentation Workflow?

tomevault-io (@tomevault-io) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Documentation Workflow by tomevault-io

Name: Documentation Workflow
Author: tomevault-io

Documentation Workflow

Source comment, rustdoc, rwkv-rs-book, and documentation gate guidance for this Rust workspace. Use when changing public APIs, comments, terminology, error behavior, design explanations, algorithms, scheduling, performance conclusions, or documentation checks. Use when this capability is needed.

tomevault-io 2bbb25b 2 files · 3.1 KB Updated Sep 17, 2026

File contents

Comment and Documentation Workflow

Goals

Continuously complete public API rustdoc and expose documentation debt through compiler warnings.
Keep complex implementation design intent, key constraints, and current background information in source code or rwkv-rs-book for long-term maintenance.
Avoid custom documentation gates that diverge from common Rust community practice.

Source Comments

Prefer standard rustdoc style for public API documentation.
For internal implementation, add comments only when non-obvious constraints, algorithm background, or easy-to-misuse paths exist.
Documentation and comments focus on the current design, current contract, and current implementation reasons.
When error behavior must be described, prefer common rustdoc sections such as # Errors or # Panics instead of custom tag formats.
unwrap / expect / panic! are allowed in this repository. Whether they are appropriate is judged by concrete semantics and code review, with no extra tool ban.

`rwkv-rs-book`

Use rwkv-rs-book to organize user-visible capabilities, design background, and longer implementation explanations.

Update rwkv-rs-book when a change satisfies any of the following:

It adjusts public APIs or user-visible behavior.
It modifies core concept names or design explanations.
It introduces a new algorithm variant, scheduling strategy, or performance conclusion.
It corrects assumptions in current design documentation.

Review and Gates

Workspace crate/example roots uniformly enable #![warn(missing_docs)] and rustdoc-related warn settings to expose missing docs, broken links, and invalid HTML tags.
CI and daily verification mainly rely on:
- cargo check --workspace
- cargo doc --workspace --no-deps
- mdbook build rwkv-rs-book
Comment sufficiency, error-message clarity, and whether design background is needed are mainly guaranteed through code review.

Source: rwkv-rs/rwkv-rs-stable — distributed by TomeVault.

---name: documentation-workflowdescription: Source comment, rustdoc, rwkv-rs-book, and documentation gate guidance for this Rust workspace. Use when changing public APIs, comments, terminology, error behavior, design explanations, algorithms, scheduling, performance conclusions, or documentation checks. Use when this capability is needed.---# Comment and Documentation Workflow## Goals- Continuously complete public API rustdoc and expose documentation debt through compiler warnings.- Keep complex implementation design intent, key constraints, and current background information in source code or `rwkv-rs-book` for long-term maintenance.- Avoid custom documentation gates that diverge from common Rust community practice.## Source Comments- Prefer standard rustdoc style for public API documentation.- For internal implementation, add comments only when non-obvious constraints, algorithm background, or easy-to-misuse paths exist.- Documentation and comments focus on the current design, current contract, and current implementation reasons.- When error behavior must be described, prefer common rustdoc sections such as `# Errors` or `# Panics` instead of custom tag formats.- `unwrap` / `expect` / `panic!` are allowed in this repository. Whether they are appropriate is judged by concrete semantics and code review, with no extra tool ban.## `rwkv-rs-book`Use `rwkv-rs-book` to organize user-visible capabilities, design background, and longer implementation explanations.Update `rwkv-rs-book` when a change satisfies any of the following:- It adjusts public APIs or user-visible behavior.- It modifies core concept names or design explanations.- It introduces a new algorithm variant, scheduling strategy, or performance conclusion.- It corrects assumptions in current design documentation.## Review and Gates- Workspace crate/example roots uniformly enable `#![warn(missing_docs)]` and rustdoc-related `warn` settings to expose missing docs, broken links, and invalid HTML tags.- CI and daily verification mainly rely on: - `cargo check --workspace` - `cargo doc --workspace --no-deps` - `mdbook build rwkv-rs-book`- Comment sufficiency, error-message clarity, and whether design background is needed are mainly guaranteed through code review.---> Source: [rwkv-rs/rwkv-rs-stable](https://github.com/rwkv-rs/rwkv-rs-stable) — distributed by [TomeVault](https://tomevault.io).

Frequently asked questions