doc-criticlisted

Critically review the documentation a doc-suite skill produced — a learning track, architecture doc, runbook, FAQ, usage guide, or onboarding — before it is published, catching what a deterministic verifier cannot judge — cross-module contradictions, analogy and term collisions, code-vs-doc mismatches, undefined terms, simplifications that became false, honesty drift, and broken cross-references. It runs verify.py first, then a blind multi-axis agent critique (whole-document consistency, code-grounded correctness, the beginner floor, an adversarial adjudicator), writes a severity-ranked review register, and gates publishing on unresolved blockers. Use it after generating or editing docs, or to review, critique, QA, or harden the docs before publishing. It is the human-judgement layer on top of verify.py and an authoring skill's same-context critic loop, reviews the docs a skill produces rather than the skills themselves, and does not publish (use publish-mirror).
imrohitagrawal/project-doc-skills · ★ 0 · AI & Automation · score 58

Install: claude install-skill imrohitagrawal/project-doc-skills

# Documentation Critic Version: 0.1.0 · see `CHANGELOG.md`. The independent **critic gate** for the documentation suite. After an authoring skill writes its pages and the deterministic verifier (`scripts/verify.py`) passes, this skill runs a **blind, multi-axis critical review** over what was produced, finds the defects a regex/readability verifier cannot — contradictions across modules, analogies that teach the wrong shape, claims the code does not support — and gates publishing on the serious ones. This skill owns the *review method and the orchestration*. The shared writing standard it judges against lives in `references/house-style.md` — **read it first, every time.** The project's facts, audience targets, and scope live in the project profile (`docs/project-profile.md`; how to find or create it is `references/house-style.md` Section 1). **It is judgement, not a generator.** `verify.py` enforces the checkable rules and stays the hard gate; this skill produces a *review register a human approves*. It never silently edits the docs. --- ## Before you start: what this needs, when to run it, where it fits ### What this skill needs (the inputs) - **The produced documents** to review (e.g. `docs/learning/` for a learning track, plus its `glossary.md`). - **The filled project profile** (`docs/project-profile.md`) — scope, audience, and the `grade_target_*` / `scope_*` keys the verifier reads. - **The project source it teaches from** — the repository, the decision recor