From document-processing
Validate a finished document against rules AND against its source - first grounds every claim via the grounding CLI, then checks tone, style, length, format, focus and custom rules. Produces a validation/ folder with grounding report, compliance checklist, summary, and a best-effort corrected copy. Use when asked to validate a document, validate against rules, check compliance and grounding, or audit a document against a source.
How this skill is triggered — by the user, by Claude, or both
Slash command
/document-processing:validateThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Two layers:
Two layers:
grounding skill: extract-claims → batch-ground → check-consistency. Every load-bearing claim verified against the source(s), plus the document checked against itself. Outputs claims.json, grounding-report.md, consistency-report.md. Not re-implemented here — delegated to the grounding skill verbatim, including its three core verdict rules, OCR fallback chain, and semantic-consent gate.grounding does not do; it's what makes this the validate skill rather than the grounding skill.This skill gathers the criteria (Phase 0), runs the full grounding chain through the grounding skill (Phase 2), adds the compliance layer (Phase 3), produces the verdict (Phase 4), and ships a best-effort corrected copy (Phase 5).
Every file this skill writes (grounding-report.md, consistency-report.md, compliance-checklist.md, validation-summary.md, criteria.md) uses telegram-style: short clauses, drop articles/copulas where meaning stays clear, one fact per line, bullets not paragraphs, concrete numbers over adjectives, no hedging ("may"/"might"), imperative actions. Reviewers skim for verdicts - prose costs attention.
python3 -c "import stellars_claude_code_plugins" 2>/dev/null || python3 -m pip install --user --upgrade stellars-claude-code-plugins
No-op when the package is importable; auto-installs when missing OR when a stale shim is on PATH but the package is uninstalled in the active Python. Never ask - just run the line. The CLI is mandatory for the grounding layer; without it, say so and stop rather than degrade to manual search.
Ask if not provided.
Required:
Optional (offer defaults):
If the user is unsure how to phrase rules, load the real rule-set examples in ${CLAUDE_PLUGIN_ROOT}/examples/ (a full INSTRUCTIONS.md with measurable uniformization rules R0-R4, plus a worked uniformization checklist) and use them to draft concrete, measurable criteria - word ranges with a preferred band, exclusion lists with example quotes, a falsifiable "does this sentence change what the reader knows" test. Adapt the shape, not the content.
Store all criteria.
Create validation/ in project root. All artifacts here — single directory = one place to delete, diff, archive.
validation/
├── criteria.md <- collected criteria summary
├── claims.json <- extracted claims (grounding layer)
├── grounding-report.md <- grounding layer output
├── consistency-report.md <- self-consistency check output
├── compliance-checklist.md <- compliance layer output
├── validation-summary.md <- final verdict
└── <filename>_corrected.<ext> <- best-effort corrected copy
Write criteria.md.
grounding skillRun the full grounding chain (extract-claims → batch-ground → check-consistency) per the grounding skill (${CLAUDE_PLUGIN_ROOT}/skills/grounding/SKILL.md) - it carries the canonical procedure: pre-flight install, semantic-consent gate, source-format + OCR fallback chain, the three core rules (agreement-beats-magnitude / contradiction-is-final / re-recommend-semantic), the per-claim workflow, extract-claims (step 1, review the claims.json it emits), the ground / batch-ground CLI (step 2), verification_needed second-guessing, status mapping, and check-consistency (step 3 - the intra-document check). Do not skip step 3; a validated document must be both grounded against its source AND internally consistent.
Concretely, in single-document mode (this is the grounding skill's Mode B chain):
document-processing extract-claims --document <doc> --output validation/claims.json
# review validation/claims.json, then:
document-processing batch-ground \
--claims validation/claims.json \
--source <source> [--source <other>] [--primary-source <source>] \
--output validation/grounding-report.md \
--threshold 0.85 --bm25-threshold 0.5 \
--semantic on # the default; omit / 'off' only if the user opted out (settings.semantic_enabled == false)
document-processing check-consistency --document <doc> --output validation/consistency-report.md
Outputs: validation/grounding-report.md (claim verdicts: CONFIRMED / CONFIRMED-fuzzy / CONFIRMED-topical / CONFIRMED-semantic-VERIFY / UNCONFIRMED / CONTRADICTED / INFERRED / N-A, with quoted evidence + location) and validation/consistency-report.md (intra-document numeric / entity-set conflicts). For a batch of documents, run the grounding skill's source_map.yaml mode instead.
Apply the grounding skill's verdict rules verbatim - do not invent a parallel ruleset here. Carry the grounding-score and the list of UNCONFIRMED / CONTRADICTED items forward into Phases 3-5.
Check against all criteria. Generate compliance-checklist.md — telegram-style template:
# Compliance Checklist
- document: <path>
- date: <date>
## word_count
- count: XXX
- range: [min, max]
- pass: yes/no
- action: trim N / expand N / ok
## tone
- expected: <tone>
- violations: [quotes] / none
- action: rephrase N passages / ok
## style_rules
(per rule)
- rule: <desc>
- status: pass/fail
- violations: [quotes] / none
- action: fix / ok
## focus_rules
- prohibited found: [quotes] / none
- required present: [list] / yes/no
- action: remove N / add N / ok
## format
- encoding: UTF-8 yes/no
- spacing: correct yes/no
- links: N / none
- action: fix / ok
## section_format
(per rule)
- rule: <desc>
- status: pass/fail
- details: [measurements]
- action: fix / ok
## custom_rules
(per rule)
- rule: <desc>
- status: pass/fail
- evidence: [details]
- action: fix / ok
Python scripts for measurable checks (word count, point length, links) — never eyeball; human counting on long docs is unreliable, off-by-N errors cascade into wrong verdicts.
Generate validation-summary.md — telegram-style template:
# Validation Summary
- document: <path>
- sources: <path(s)>
- date: <date>
## grounding
- claims: X
- score: X/Y (Z%)
- issues: [list] / none
## consistency
- findings: X / none
- issues: [list] / none
## compliance
- rules: X
- passed: X
- failed: X
- issues: [list] / none
## verdict
PASS / PASS WITH WARNINGS / FAIL
## required_actions
1. <fix>
2. <fix>
...
(or "none - document passes all checks")
Always produce corrected copy — separate file so original stays reviewable:
validation/<filename>_corrected.<ext>validation-summary.md with post-correction statusvalidation/ — single cleanup point_corrected suffix; overwrite only on explicit requestgrounding skill - this skill never re-implements them, it calls themProvides a checklist for code reviews covering functionality, security, performance, maintainability, tests, and quality. Use for pull requests, audits, team standards, and developer training.
npx claudepluginhub stellarshenson/claude-code-plugins --plugin document-processing