yeet-docs

name	yeet-docs
description	Use when user-facing CLI behavior, flags, workflows, README examples, website manual pages, or changelog entries need to be updated.

Yeet Docs

Use this skill when a change affects what users run or read.

Surfaces

• Root README.md for quickstart and common examples.
• website/docs/ for the user manual.
• website/docs/changelog.mdx only for tagged releases.
• CLI help metadata in pkg/cli/cli.go and cmd/yeet/cli.go.
• Help reference: .codex/skills/yeet-cli/references/yeet-help-agent.md.

Rules

• Keep examples generic and free of private hostnames or service names.
• Treat README and manual pages as evergreen descriptions of the product. State defaults and behavior directly; do not frame normal behavior as new, changed, migrated, or upgraded. Reserve temporal language for changelogs and dedicated upgrade or compatibility instructions.
• Keep changelog bullets user-facing and concise.
• The latest changelog entry must stand alone for someone installing or upgrading. If a screenshot showed only that version, it should still answer "what changed for me?" without requiring prior-release context.
• Never make release plumbing the changelog message: avoid bullets about git hashes, submodule pointers, source revisions, CI retries, tag repair, or website publication mechanics unless the user needs a concrete action.
• For a corrective release that supersedes a bad tag or artifact, carry forward the actual user-facing changes into the new latest version. If needed, mark the prior version as superseded in plain user terms, but do not make the corrective mechanics the only bullet.
• For CLI syntax changes, update parser tests, help text, README, and website docs together.
• Commit website changes inside the submodule before committing the root submodule pointer.

Checks

git -C website diff --check
rg -n "private[-]host|/User[s]/" README.md website/docs .codex/skills