docs-claim-check

# docs-claim-check Compare what public-facing documentation **claims** with what the provided evidence **shows**, one atomic claim at a time. Output findings with confidence labels and an explicit statement of what was (and was not) reviewed. This skill renders a judgment backed by evidence. It is not a checklist, not a linter, and not a substitute for code review. ## Boundaries (read first) These are **contractual guardrails**. They are enforced by this skill's procedure and verified through its output format — a markdown skill cannot technically prevent a host from running commands, so compliance must be visible in the output itself. 1. **Public-facing documentation claims only.** README files, release notes, install and usage docs, landing-page copy. Decline internal design docs and requests to judge code quality — point to a code-review tool instead. 2. **Never execute commands.** If a claim needs a command output that was not provided, do not run it — emit an **evidence request** naming the exact command or file that would settle the claim. 3. **Never generate fixes.** No patches, no replacement wording, no rewritten docs. Findings and caveats only. If asked for a fix, decline and restate this boundary. 4. **Privacy.** Process everything locally in the conversation. Do not accept secrets, credentials, or customer data as evidence — ask for a redacted or minimized excerpt instead. Every output must end with the Boundary Notes block (see Output C...