Use doc-critique

Review an existing document

Review an existing document — ADR, design doc, runbook, exec summary, tech-comparison matrix, deck outline, decision log — and produce a structured critique against the same quality bars the skilldrop generators enforce. Categorizes findings by severity (blocker / major / minor / nit), points to the exact section/line, and suggests a concrete fix for each.

Reach for it when the user wants a second-pair-of-eyes review before sharing a doc, or has been handed someone else's artifact and wants to know what to push back on.

Install it

npx skilldrop-cli install doc-critique                 # Claude Code, your user folder
npx skilldrop-cli install doc-critique --project       # Claude Code, this repo
npx skilldrop-cli install doc-critique --ide cursor    # or kiro, codex, antigravity, copilot

It is part of the Core pack: --pack core installs it with its neighbours.

Ask for it

Say it the way you would to a colleague. Requests like these route to it:

• "Critique this design doc before I share it"
• "Review this ADR and tell me where it's weak"
• "Is this runbook actually good? Give me a structured critique"
• "Score this exec summary against a quality bar"
• "Review my document and give me severity-tagged findings with fixes"

Requests like these belong to a different skill, so it shouldn't answer them:

• "Review this pull request for bugs"
• "Write a new ADR for this decision"
• "Get five senior personas to deliberate whether we should do this"

If another skill answers instead, ask for this one by name: "use doc-critique".

Check what you get

A good result:

• Severity is calibrated. If your output has more blockers than major issues, you're inflating. Reread and demote.
• Findings are local, not global. "The whole tone is off" is not a finding; "§ TL;DR uses 'innovative' and 'leverage' — replace with concrete verbs" is.
• Fixes are paste-able where possible. If the fix is "add an X section", show what the X section should contain in 2–3 bullets.
• Don't review the topic, review the doc. It's not your job to redebate whether Postgres beats DynamoDB — only whether the doc made its case competently.
• Quote the doc, don't paraphrase. Just like decision-log, the quoted snippet is the audit trail that proves you read the actual words.

See a worked example

• design doc critique

Use something else when

• For evaluating the underlying decision (is Postgres the right choice?). That's a tech debate, not a doc review — argue the decision itself, or put it to council-review.
• For grammar / spelling pass on a doc that's otherwise solid. Use a normal editor.
• For evaluating code. This skill reviews documents; for code review, the user has other tools.
• For generating the doc. If the user wants a draft, that's the matching generator skill.

Where a loop runs it

• Stage sign-off of the comply loop, where gate G8.1 decides
• Stage ratify of the discover loop, where gate G0 decides
• Stage sign-off of the measure loop, where gate G9.1 decides
• Stage critique of the ship-a-draft loop, where gate G5 decides

Next

• SKILL.md, the instructions the agent reads
• Its page on the site
• Related: council-review, decision-log

Edit this page on GitHub · View source