| name | moai-workflow-docs-claim-check |
| description | Read-only check of whether the claims a public-facing document makes (README, release notes, install and usage guides) are supported by user-supplied evidence. Runs Preflight, Claim Triage, and Validation, splits composite claims into atomic ones, and labels each. Runs no commands and writes no fixes.
|
| when_to_use | Use when asked whether documentation claims are backed by evidence, to audit a README or release note before publishing, or to find unsupported or outdated statements in user-facing docs.
|
| license | Apache-2.0 |
| compatibility | Designed for Claude Code |
| allowed-tools | Read, Grep, Glob |
| user-invocable | false |
| metadata | {"version":"1.0.0","category":"workflow","status":"active","updated":"2026-07-24","modularized":"true","tags":"documentation, claim-check, evidence, verification, readme, release-notes, read-only","related-skills":"moai-workflow-project, moai-foundation-quality"} |
| progressive_disclosure | {"enabled":true,"level1_tokens":100,"level2_tokens":5000} |
Documentation Claim Check
Assess whether the statements a public-facing document makes are actually
supported by the evidence supplied alongside it. The assessment reads, judges,
and reports. It changes nothing and runs nothing.
Typical subjects: a README, a release note, an install guide, a quickstart, a
migration note, a feature or compatibility table.
Hard boundaries
Three boundaries are absolute. They hold even when the request asks for more;
in that case perform the assessment and decline the rest in Boundary Notes.
- No command execution. Do not run builds, tests, package managers,
linters, network requests, or any shell command as part of the assessment.
When a claim can only be settled by running something, name the exact
command and the file it should run against and label the claim
needs-human. Naming the command is the deliverable; running it is not.
- No fixes. Do not produce patches, diffs, rewritten passages, or file
edits. Describe what a maintainer would change and where, then stop.
- No code review and no security review. Do not assess code quality,
architecture, performance, or vulnerabilities. If asked, state the boundary
in Boundary Notes and continue with the claim assessment only.
Opening the files the user pointed at, to locate the evidence they supplied, is
in scope — that is reading, not executing.
Phase 1 — Preflight
Complete all three steps before triaging a single claim. If a step cannot be
completed, report that and stop rather than guessing.
- Confirm the document is public-facing. This skill judges documents
written for users of the software: README, release notes, install and usage
guides, published site pages. Internal design notes, task trackers, and
private runbooks are out of scope — say so and stop.
- Inventory the supplied evidence. For every item record what it is, where
it came from, its version identifier, and its timestamp. An item with
neither is still usable, but record it as undated: it cannot later support a
freshness judgment.
- Flag secrets for redaction before proceeding. Scan the supplied evidence
for credentials, tokens, private keys, connection strings, and personal
data. On a hit, flag the location for redaction, never reproduce the secret
in any output, and continue only once a redacted copy is available.
Phase 2 — Claim Triage
Turn the document into an inventory of atomic claims.
Extract. Walk the document and pull out every statement that asserts
something checkable about the software: supported platforms and versions,
install and usage steps, defaults, limits, guarantees, availability, counts.
