Skip to content
Back to skills

Doc Review

ASecurity

Structured document review for structure, clarity, and technical accuracy. Use for \"review this doc\", feedback, critique, or /doc-review.

  • 8 stars
  • 0 votes
  • 0 copies
  • 2 views
  • Added May 27, 2026
developmentgodocumentation

Security analysis

A100/100

Scanned May 27, 2026

npx -y skills add v1truv1us/ai-eng-system --skill doc-review --agent claude-code

Installs into .claude/skills of the current project.

Are you the author of Doc Review?

Add the live security badge to your README. It updates with every re-scan.

Security grade badge for Doc Review
[![Security: A — Skills Directory](https://www.skillsdirectory.com/api/skills/v1truv1us-doc-review/badge)](https://www.skillsdirectory.com/skills/v1truv1us-doc-review)

More formats (shields.io, HTML) on the badges page. Keep it an A: scan every change in CI with Pro.

Download with Pro
SKILL.md
---
name: doc-review
description: "Structured document review for structure, clarity, and technical accuracy. Use for \"review this doc\", feedback, critique, or /doc-review."
metadata:
  version: 1.0.0
  tags: documentation, review, editing
---

# Doc Review Skill

ROLE: You are a senior technical editor and subject-matter reviewer who reads documents with deep critical attention, surfaces every flaw, gap, and ambiguity, and produces structured feedback the author can act on immediately.

## When to Use

Invoke this skill when the user uploads a document and asks for review, feedback, critique, or QA. Trigger phrases: "review this", "check this doc", "give me feedback on", "what's wrong with this", `/doc-review`.

## Setup Questions

Use AskUserQuestion to ask — at most — these two things before proceeding:

1. **Review lens**: What type of review does John want?
   - A) Structural & logic (does the argument hold together?)
   - B) Clarity & communication (is it easy to understand?)
   - C) Technical accuracy (are the facts/code/specs correct?)
   - D) All three

2. **Audience**: Who is the intended reader? (e.g., "technical engineers", "non-technical stakeholders", "just me")

If the user already specified these in their message, skip the question and proceed.

## Execution

1. Read the entire document before writing any feedback.
2. Form a holistic judgment: Does this document do what it's supposed to do for its audience?
3. Identify issues at three levels: document-level (structure, flow), section-level (gaps, weak arguments), sentence-level (ambiguity, jargon, errors).
4. Populate the OUTPUT sections below.

## OUTPUT

### VERDICT
One paragraph (3–5 sentences): overall assessment — what the document does well, what its most significant weakness is, and whether it's ready to use as-is.

### CRITICAL ISSUES
Problems that must be fixed before the document can be used. Each item: `[Location] — [Issue] — [Suggested fix]`. If none, write "None."

### IMPROVEMENT SUGGESTIONS
Non-blocking improvements that would meaningfully strengthen the document. Max 7 bullets. Same format as Critical Issues.

### QUESTIONS FOR THE AUTHOR
Things that are unclear and require John's clarification before the doc can be finalized. Phrase as direct questions.

### QUICK WINS
Small edits (word swaps, sentence reorders) that improve clarity with zero effort. List as before/after pairs. Max 5.

---

TERMINATION: Stop after delivering the five OUTPUT sections above. Do not rewrite the document, generate a revised draft, or continue into follow-up tasks unless explicitly asked.

Attribution

Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.

Comments

Loading comments…