skills/documentation/SKILL.md
## Task We will now do a comprehensive code quality pass for the core crates of this project. This task has the primary goal of improving public apis: 1. Reduce usage of `pub`: prefer `pub(super)`, `pub(crate)` etc wherever it makes sense, this includes at the module level and for struct fields. 2. Public Docs: ensure all public apis are well documented according to RFC 1574, except where it would be overly verbose. While we are passing through source files we should also consider two seconda
npx skillsauth add mrchantey/beet skills/documentationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
We will now do a comprehensive code quality pass for the core crates of this project.
This task has the primary goal of improving public apis:
pub: prefer pub(super), pub(crate) etc wherever it makes sense, this includes at the module level and for struct fields.While we are passing through source files we should also consider two secondary goals: 3. Comments: ensure all complex logic explains well its behavior 4. Tests: ensure all tests are of high quality 5. Integration tests and examples: these should also be well documented. examples should be in root directory, not individual crates.
MyStruct::new usually does not need an example, just a one-liner doc. General usage should be in the top level MyStruct docsFor each crate do the following:
#![deny(missing_docs)cargo check passes with all features, both native and wasm:
cargo check -p beet_core --all-featurescargo check -p beet_core --all-features --target wasm32-unknown-unknowntimeout 1m cargo test -p beet_core --doc --all-features | tail 30skills/rust/beet-doc.mdWe will start from the basic dependencies and work upwards. Skip those marked completed. Do not ask to continue to the next one, just do it.
Finally we can verify all changes by running: just test-all
testing
Prepare the speficied crates for release, one by one. For each crate follow the below procedure. **Do not actually release the crate.** ## 1. Documentation Gain an understanding of the intended usage of the crate. Do not comb through every single source file, just check the high level types and ensure they are well documented. Ensure the `README.md` is up to date and of high quality. The `lib.rs` should include the readme as crate level docs. ## 2. Testing Run checks and tests for the crate
development
Maintainer-only workflow for handling GitHub Secret Scanning alerts on OpenClaw. Use when Codex needs to triage, redact, clean up, and resolve secret leakage found in issue comments, issue bodies, PR comments, or other GitHub content.
development
Maintainer workflow for OpenClaw releases, prereleases, changelog release notes, and publish validation. Use when Codex needs to prepare or verify stable or beta release steps, align version naming, assemble release notes, check release auth requirements, or validate publish-time commands and artifacts.
development
Run, watch, debug, and extend OpenClaw QA testing with qa-lab and qa-channel. Use when Codex needs to execute the repo-backed QA suite, inspect live QA artifacts, debug failing scenarios, add new QA scenarios, or explain the OpenClaw QA workflow. Prefer the live OpenAI lane with regular openai/gpt-5.4 in fast mode; do not use gpt-5.4-pro or gpt-5.4-mini unless the user explicitly overrides that policy.